Published: 2009-11-30

Distributed Wordpress admin account cracking

One of our readers, catlu, found a very interesting script in one virtual private server (VPS), ran by a user who was clearly violating the TOS. The acquired script is written in PHP and performs brute force cracking attempts to Wordpress admin accounts, as can be seen in the snippet below.


The wp_brute_attempt() function takes 3 parameters, $ch which is cURL's structure (cURL is a command line tools that can be used to perform HTTP requests). The other two parameters define the site and the password that will be tried. If the script logged in successfully, the page that gets returned by the server will contain the phrase "Log Out", and the function will return a true value.

Now, the interesting thing about the script is that it allows distributed cracking. Information is saved in a MySQL database and the script actually connects directly to the main database. This allows the attacker to run many simultaneous scripts – each of them will take 200 new URLs and mark them with the brute forcer's ID ($colo). This part is shown below:

Wordpress brute force script

The script then takes every password from a password script and tries it on each site. The script can even be stopped and when executed next time will continue where it stopped.

While this particular version is relatively simple, the power behind the script and the MySQL database allows the attacker to distribute the attacks not only by sites, but also by passwords tried as well.

Finally, if you are using Wordpress (or any other blog tool), be sure that access to the admin interface is as limited as possible. This means choosing strong passwords, changing the admin username if possible and limiting access by IP addresses.

Wordpress brute force attacks have been around for quite some time already (similarly to SSH brute force attacks, for which we at SANS ISC are getting reports daily), so we can expect that the bad guys will start using such advanced techniques for attacking other services as well.



Published: 2009-11-29

A Cloudy Weekend

There are times, like over a long US Holiday weekend leading up to your Handler duty shift, you get the "opportunity" to catch up with information security issues of the day and run into some great work that warrants mention for any number of reasons. And over this weekend I had the "opportunity" to look a bit deeper into Cloud Computing information security. Some exceptional work I ran into while perusing the cloudscape included the two following efforts, and both provide extensive citations and links.

  • The "Security Guidance for Critical Areas of Focus in Cloud Computing", prepared by the Cloud Security Alliance (CSA), a group certainly fulfilling their mission statement. In their guidance executive summary they mention that every "attempt has been made to focus on areas of concern that are either unique to cloud computing, or are greatly exacerbated by the model". They certainly achieved the focus they wanted. An example of that focus, in the executive summary section on compliance and audit, is when they reference the "scope" of various attestations of security, when they note that "It is critical to examine the scope of SAS 70 Type II audits and ISO 27001 certifications" and later in the guidance state "Provider site certifications such as SAS 70, WebTrust® and SysTrust®, Service Capability & Performance (SCP) or ISO27001 can be directed as desired by the provider and are a point in time certification if there is any such certification". The CSA guidance is also quite focused elsewhere .

You can read about participating (or collaborating) here - Cloud Security Alliance Membership

  • The European Network and Information Security Agency (ENISA), an EU agency, "risks assessment on cloud computing business model and technologies". This is an "in-depth and independent analysis that outlines some of the information security benefits and key security risks of cloud computing". The report also provides "a set of practical recommendations". In-Depth indeed, see  - "Cloud Computing Benefits, risks and recommendations for information security".

Between now and my next Handler shift/Diary at the end of December, I'm sure there will be other weekend "opportunities" to pursue related work. I hope to present some information from Josh Corman of the451group on a developing cloud computing information security "reference" architecture extension that has utility for working through cloud information security issues in your environment.


Published: 2009-11-26

Microsoft Security Advisory (977981)

Further information has been released regarding Microsoft Security Advisory (977981), previously reported here by Marc and Rick to include mitigation factors.  We strongly encourage all IE users to review the new information posted by MS, especially in light of workable exploits that are starting to surface on the web.


tony d0t carothers at isc d0t sans d0t org


Published: 2009-11-26

What Are You Thankful For?

On this day of Thanksgiving in America, I'd like to take the opportunity, and give you the readers the chance as well, to express thanx for the tools that exist that make our lives easier.  I am talking about the software tools that we all know and love that enable us to do our jobs, such as packet sniffers, syslog servers, intrusion detection systems, etc., etc. 

My personal thanx goes out to all those who have created, and kept updated, traffic sniffers.  Whether I have been working as a network admin, system admin, or security admin I have found the sniffer to be the first tool I go to in my toolbox when I have a question about something cooking on my network.

Now it's your turn; what are you thankful for?  Maybe the security information manager that helps consolidates all the events in your world for easier analysis?

tony d0t carothers at isc d0t sans d0t org


Published: 2009-11-25

Updates to my GREM Gold scripts and a new script

And finally, before those of us in the US trip out on tryptophan tomorrow, I've updated a few of the scripts that I wrote about in my GREM Gold paper and my SANSFIRE talk.  The biggest change is that I have finally integrated Michael Hale Ligh's malfind2 volatility plugin into the report and I have switched to using httpry for reporting on the HTTP traffic.  I've also put together another script to report on/decode DNS traffic out of a pcap.  The script can be found on my handler's page.  I recently used that and another script I wrote for the latest network forensics contest.  I'll post the other script and my solution (because I had a lot of fun working on it) after they release the results.  I highly recommend these contests and the other packet challenges we've told you about before for those who want more practice at playing with packets and network traces.

Jim Clausing, jclausing --at-- isc [dot] sans (dot) org


Published: 2009-11-25

Microsoft Updates requiring reboot

We've been informed by several readers that they've received updates from Microsoft in the last 24 hours (via Automatic Update or similar) that required a reboot.  Microsoft has apparently updated several of their bulletins.  Two of them are related to previous updates MSXML (v3.0 or v6.0), one with MSXML Core Services 4.0 SP2, one is additional daylight saving time updates, and the 4th is also daylight saving time-related and has to do with an error in the Date and Time control panel on Vista and Windows Server 2008.  While it isn't unusual for Microsoft to make some minor updates to bulletins and patches (especially detection fixes) at times other than "Patch Tuesday" some of our readers (and some of us, handlers) were surprised by updates that required reboot.

Microsoft KB 973685
Microsoft KB 973687
Microsoft KB 973688
Microsoft KB 976098
Microsoft KB 976470  

Jim Clausing, jclausing --at-- isc [dot] sans (dot) org


Published: 2009-11-25

Tool updates

Rather than do 4 one-liners in a row, I'll just do this one regular story.  A number of our favorite tools have been updated recently.

Wireshark v1.2.4 was released a week ago, "this release fixes a problem with some interface drivers on Windows and a problem saving RTP streams."  The latest dev version v1.3.2 was released yesterday.

Truecrypt v6.3 was released a month ago and 6.3a Monday.  The 6.3a fixes some bugs, the 6.3 release provides support for Windows 7 and OS X 10.6.

Xplico v0.5.3 was released last week.  They have added support for Solaris snoop packet captures.  They've added DNS, NNTP, PPPOE dissectors among other things.

NetworkMiner v0.91 just came out, too.  I haven't found any release notes on what changed yet with this release.

Jim Clausing, jclausing --at-- isc [dot] sans (dot) org


Published: 2009-11-24

BIND Security Advisory (DNSSEC only)

The other ISC (Internet Systems Consortium) has released a security advisory on BIND and security patches for nameservers running with DNSSEC validation enabled. Essentially it is possible for inappropriate caching of records from the additional records section of a query response. Typically, however, resolvers don't query in such a way as to make this a wide-impacting problem for the bulk of users.

You can read the advisory here.

Upgrade to 9.4.3-P4, 9.5.2-P1 or 9.6.1-P2.

John Bambenek
bambenek at gmail /dot/ com


Published: 2009-11-24

Microsoft Security Advisory 977981 - IE 6 and IE 7

Related to Marc's Diary from 11/23, Microsoft has released Security Advisory 977981.  It details vulnerabilites in Internet Explorer 6 and 7 on various operating systems.  The advisory does not provide any patches or new versions at this point, but does provide several recommendations for mitigation.


-- Rick Wanner - rwanner at isc dot sans dot org


Published: 2009-11-23

New Nmap Beta Released

Earlier today, Fyodor announced the release of a new beta of Nmap.  Nmap 5.10BETA1 has a number of improvements including UDP scanning, NSE  scripts, host fingerprinting, and hundreds of other changes.  More information is located at seclists.org/nmap-dev/2009/q4/476 .  Time for all of us to upgrade our software prior to any vulnerability assessments you may have planned for your organizations. 


Scott Fendley ISC Handler


Published: 2009-11-23

Government Approaches to Cybersecurity - What are your tips?

On the heels of a recent Govenment Accounting Office (GAO) finding that many US federal agencies still are failing to adaquetly protect their systems, the National Institute for Standards and Technology (NIST) has issued new draft guidelines to revamp how the US government protects its own networks and to make up for the perceived failings of FISMA. (You can find the new guidelines here). While still in draft form, it appears the philosophy was to front-load security considerations and monitor throughout the life of the resource.

Ultimately, it's part of the ages old problem in security. Most organizations exist for reasons unconnected to cyber-security so how do you get them to invest in something that isn't their core business or necessarily increases sales (or decreases costs). For private organizations, regulation comes into play where organizations are forced into a security posture under threats of fines. This is so prevalent, I've heard more than once when presenting risks that "if there's not a law or regulation, then I don't care". It's a special problem for governments because regulations are not as "binding" on the same entities that enforce governmental regulations to begin with. The problem the US has (and other governments for that matter) aren't difficult ones to solve, they are known vulnerabilities or gaps with known solutions. The problem is making it part of the culture and getting the investment.

Businesses, also, have to deal with lost business or lawsuits in certain types of data breaches while, generally, the government faces no such risk. This paper has tips for selling security to management, but not all of it applies in governmental shops. Ultimately, it comes down to awareness, good risk analysis with costs and benefits and solid policies.

What are your tips for making the sale for security in government shops? (Will post the best answers in a follow on diary Wednesday)

Related news:

Australian Government Overhauls Cybersecurity Under New CERT-Australia


John Bambenek
bambenek at gmail /dot/ com


Published: 2009-11-22

IE6 and IE7 0-Day Reported

According to VUPEN security:

A vulnerability has been identified in Microsoft Internet Explorer, which could be exploited by attackers to compromise a vulnerable system. This issue is caused by a dangling pointer in the Microsoft HTML Viewer (mshtml.dll) when retrieving certain CSS/STYLE objects via the "getElementsByTagName()" method, which could allow attackers to crash an affected browser or execute arbitrary code by tricking a user into visiting a malicious web page.

We have not verified this claim, but would like to know if any of our readers have.  Please use our contact form to reply, or add your comments below.

Marcus H. Sachs
Director, SANS Internet Storm Center


Published: 2009-11-21

What is making you vulnerable?

The VMware patch mentioned in the oneliner raises an interesting question.  What is making you vulnerable?  The notification in this case is  very careful to explicitly state that the security vulnerabilities are in the thirdparty products used within the solution provided by the vendor.  If you have a look at the issues being addressed you will notice that quite a number of the issues are 2008 CVE numbers and yes also some 2007 numbers.  So doesn't that make the product itself vulnerable?  Well I guess the true answer is "it depends", there may be measures in place to mitigate the risk, but you'll find that for many products the answer will be a resounding "YES".  

Now this is just a convenient example.  You will find that many products in your environment have open source or other thirdparty products lurking under the covers.  Most products including SSL will be based on OpenSSL,  SSH, web services, mail, etc are often based on their opensource equivalents.  It is likely your firewall is based on Linux, uses OpenSSL or one of the other opensource products. Many mail gateways are based on sendmail or postfix.  So it is not unreasonable to assume that if one of these products has a  security issue, the integrity of the commercial solution provided to you has been compromised.  

The best defence is to know and understand your environment.  On Monday get junior to do an inventory of the "thirdparty" products in the security solutions and other products in your environment.  you will find thta many of them are running old versions with known issues.   Include routers, switches, printers and solutions such as VMware, Xen, your firewall, mailgateway, etc, etc.   This will allow you to identify which products may be a risk if one or more of their components has security issues.   Once you know the products that may have an issue you will be able to determine the risk to your organisation and you can develop some treatments to address the issue.   Make sure If you do find old vulnerable versions of software to ask your vendor when they might be addressing it.  

Mark H - Shearwater


Published: 2009-11-19

Fedora to allow the installation of packages, without root privileges?

A "bug" created back in November against the latest Fedora release (12) indicates that, through the GUI, desktop users of the Fedora system are able to install signed packages without root privileges or root authentication.  Yes, you just read that correctly.  (I'll give you a second re-read that sentence so I don't have to retype it.)  Yes, "it's a feature, not a bug".

In all my travels I've only ran across one company, ever, that has Fedora rolled out as an enterprise operating system on every desktop.  But what kind of security implications does this have?  I obviously don't have to explain why this is (may be) a bad idea to the readers of the ISC, as we are all security minded people.  

Now, the restrictions.  This change does not affect yum on the command line.  This only affects installing things through the GUI.  (Not that helps any, as most users will be running the GUI anyway.)  You can also disable it.

create a file in:

/var/lib/polkit-1/localauthority/20-org.d  (you can name if file anything you want)

and include the following:


(the above came from the release notes for Fedora 12, found here.  

Also, I found this as a solution:

pklalockdown --lockdown org.freedesktop.packagekit.package-install

Currently in the bug, there is some debate about if they should revert this feature.  So, this may be just temporary.  

-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler


Published: 2009-11-18

Using a Cisco Router as a “Remote Collector” for tcpdump or Wireshark

Have you ever thought about your routers.  I mean - *really* thought about them?  They think all day long, processing all of the packets in and out of your company’s WAN or internet connection, and hardly ever complain.  But can you get any useful information out of those packets?

PC's with almost any operating system can be configured with tcpdump or windump (with wireshark or whatever gui you'd care to hang in front of it) to do packet capture an analysis.  But if the traffic you are trying to capture is halfway across the world (or maybe closer but still too far to drive), can you use your router to capture packets in a standard libpcap format?

As you've probably guessed, the answer is YES, or else there’d be no reason to write this article.  Let's go through the steps, from start to finish.

First, ensure that you have syslog set up – your packets are going to show up in the router’s log.  You can execute this packet capture process without syslog by using “show log” to view the local log buffer, but you'll be very limited as to how many packets you can capture per session.

Next, decide what traffic you'd like to capture.  Keep in mind that your captured packets are going to be sent back over the network to your syslog server.  So if you are troubleshooting a congested network, you might be better served using ip accounting or netflow.  To define your traffic, use an access list.  Remember that you're going to end up having to look at these packets, so the more specific you can make this list, the better.  Something like:

ip access-list 111 permit tcp host any eq 80
ip access-list 111 permit tcp any eq 80 host

will capture all web traffic originating from, as well as the return traffic.  However, something like

ip access-list 111 permit tcp any any eq 80

is generally a VERY BAD idea as it will capture all web traffic requests but none of the responses - not only will this only capture half of the conversation, it will likely max out the cpu and network of your router (depending on the router cpu and network of course).  Also be very sure that your list does not encompass your syslog traffic – often adding the line:

ip access-list 111 deny udp any any eq 514

might be a smart thing to add to your list , just to be safe.  It prevents an infinite recursive loop – your first packet will go to syslog, be recaptured as an sent to syslog, and so on ...  This process isn't supposed to capture packets sourced from the router, but if you are troubleshooting problems it's generally because things aren't working the way they should ...

Next, we need to start capturing traffic.  from the exec prompt (privilege level 15), do

debug ip packet 111 dump

This debug command initiates the packet capture of the “interesting traffic” defined in access list 111- it's now time to have your workstation do whatever it is you want to "catch on film" (sorry, I guess I'm dating myself with this reference).  The debug ip packet dump command is included in standard IOS starting in version 12.0.  So if you don’t have this as a command on your router, it’s probably time to consider an update! 

When you've got enough traffic “in the hopper”, disable the debug and remove the access list.

no debug ip packet 111 dump

or :

no debug all

as well as:

config t
no access-list 111

When we go to the log, you'll now see all the packets in hexadecimal and ASCII representation, similar to:

015515: Jun 29 08:35:52.777 EST: IP: tableid=0, s= (Vlan1), d= (FastEthernet0), routed via FIB
015516: Jun 29 08:35:52.781 EST: IP: s= (Vlan1), d= (FastEthernet0), g=, len 48, forward
05199CC0:                       0017 0E0CB761            ....7a
05199CD0: 0018DE5A 6FAA0800 45000030 91694000  ..^Zo*..E..0.i@.
05199CE0: 7F0649B7 63F2A0A7 41ADDA60 73E40050  ..I7cr 'A-Z`sd.P
05199CF0: 81254296 00000000 7002FC00 2F4F0000  .%B.....p.|./O..
05199D00: 020404EC 01010402                    ...l....
015517: Jun 29 08:35:53.133 EST: IP: tableid=0, s= (Vlan1), d= (FastEthernet0), routed via FIB
015518: Jun 29 08:35:53.133 EST: IP: s= (Vlan1), d= (FastEthernet0), g=, len 48, forward
05199E00:                       0017 0E0CB761            ....7a
05199E10: 0018DE5A 6FAA0800 45000030 917E4000  ..^Zo*..E..0.~@.
05199E20: 7F06EDCD 63F2A0A7 4A7D2D65 73E50050  ..mMcr 'J}-ese.P
05199E30: CE7AE47A 00000000 7002FC00 E43F0000  Nzdz....p.|.d?..
05199E40: 020404EC 01010402                    ...l....
015519: Jun 29 08:35:53.201 EST: IP: tableid=0, s= (Vlan1), d= (FastEthernet0), routed via FIB
015520: Jun 29 08:35:53.201 EST: IP: s= (Vlan1), d= (FastEthernet0), g=, len 48, forward
0531AC20:                       0017 0E0CB761            ....7a
0531AC30: 0018DE5A 6FAA0800 45000030 91924000  ..^Zo*..E..0..@.
0531AC40: 7F06498E 63F2A0A7 41ADDA60 73E60050  ..I.cr 'A-Z`sf.P
0531AC50: CF69CD4F 00000000 7002FC00 564F0000  OiMO....p.|.VO..
0531AC60: 020404EC 01010402                    ...l....
015521: Jun 29 08:35:55.205 EST: IP: tableid=0, s= (Vlan1), d= (FastEthernet0), routed via FIB
015522: Jun 29 08:35:55.205 EST: IP: s= (Vlan1), d= (FastEthernet0), g=, len 48, forward
0531AAE0:                       0017 0E0CB761            ....7a
0531AAF0: 0018DE5A 6FAA0800 45000030 92104000  ..^Zo*..E..0..@.
0531AB00: 7F06F531 63F2A0A7 42232DC9 73E70050  ..u1cr 'B#-Isg.P
0531AB10: 88101C35 00000000 7002FC00 FAE30000  ...5....p.|.zc..
0531AB20: 020404EC 01010402                    ...l....
015512: Jun 29 08:37:22.206 EST: %SEC-6-IPACCESSLOGP: list 101 denied tcp ->, 1 packet
015513: Jun 29 08:37:39.279 EST: %SEC-6-IPACCESSLOGP: list 101 denied tcp ->, 2 packets

In many cases, you can work with the packets in hex, and this output will be sufficient – I guess this all depends on your “geek factor”.  However, if you need to interpret these packets with a decoder or in a GUI, you'll need to get them into PCAP format.  This is a two stage process.  First, we'll need to get them to PCAP's ascii representation, which looks like this:

# Packet  1
00000000 00 17 0E 0C B7 61 00 18 DE 5A 6F AA 08 00 45 00 #
00000010 00 30 91 69 40 00 7F 06 49 B7 63 F2 A0 A7 41 AD #
00000020 DA 60 73 E4 00 50 81 25 42 96 00 00 00 00 70 02 #
00000030 FC 00 2F 4F 00 00 02 04 04 EC 01 01 04 02 #
# Packet  2
00000000 00 17 0E 0C B7 61 00 18 DE 5A 6F AA 08 00 45 00 #
00000010 00 30 91 7E 40 00 7F 06 ED CD 63 F2 A0 A7 4A 7D #
00000020 2D 65 73 E5 00 50 CE 7A E4 7A 00 00 00 00 70 02 #
00000030 FC 00 E4 3F 00 00 02 04 04 EC 01 01 04 02 #
# Packet  3
00000000 00 17 0E 0C B7 61 00 18 DE 5A 6F AA 08 00 45 00 #
00000010 00 30 91 92 40 00 7F 06 49 8E 63 F2 A0 A7 41 AD #
00000020 DA 60 73 E6 00 50 CF 69 CD 4F 00 00 00 00 70 02 #
00000030 FC 00 56 4F 00 00 02 04 04 EC 01 01 04 02 #
# Packet  4
00000000 00 17 0E 0C B7 61 00 18 DE 5A 6F AA 08 00 45 00 #
00000010 00 30 92 10 40 00 7F 06 F5 31 63 F2 A0 A7 42 23 #
00000020 2D C9 73 E7 00 50 88 10 1C 35 00 00 00 00 70 02 #
00000030 FC 00 FA E3 00 00 02 04 04 EC 01 01 04 02 #

A simple way to do this is take your log file and run it through a AWK script "i2p.awk" that I've written to "fix" the file format, then run THAT file through text2pcap.exe (which comes as part of the wireshark distro).  There are lots of perl scripts out there to do this exact thing, but I thought that AWK might be a lighter-weight, portable way of getting this same job done with less fuss.  Plus I wanted to write something neat in AWK.

if (match($0 , /[0-9A-F](8):/ ) == 0)  {

Select lines that hold packet info (line starts 8 hex digits followed by a colon)

hex = hex substr ( $0 , 10, 36) Select lines that hold packet info (line starts 8 hex digits followed by a colon)
} else {  
if (length(hex) > 0) { If it’s not a packet, and we have hex data in the buffer, it’s time to “fix the data”
 ++packet Increment the packet number
printf "%s %in%08x ", "# Packet " ,packet, 0 Print “Packet #” info, plus a Carriage Return, plus the first hex offset (0)
gsub(/[ t]/,"" ,hex) Remove all spaces from the hex info
while ( i < length(hex) ) { Loop through the hex info, byte by byte (awk starts with a byte offset of 1)
  printf "%s%s" , substr (hex , i , 2 ), " " Print each byte, with a trailing space
  mod = (i+1)%32 Are we at the end of a line?
  if (mod == 0 ) { printf "#n%08X ", (i+1)/2 } If so, print the “#” at the end of the  line, then the byte offset of the next line (note we’re correcting for the 1 byte offset that awk uses)
i += 2 Increment the character count by 2
printf "#" Print the last trailing “#”
hex = "" Clear the packet hex string


So, if your syslog file is syslog.out, you might run this as:

C:>type syslog.out | awk -f i2p.awk > test1.out

C:> text2pcap test1.out  ioscap.pcap
Input from: Standard input
Output to: ioscap.pcap
Wrote packet of 16 bytes at 0
Wrote packet of 32 bytes at 16
Read 2 potential packets, wrote 2 packets

Now we have a file we can open in wireshark (or anything else that can read a PCAP file).

So as you can see, we’re able to use a standard router as a remote collector for any standard packet sniffer program that can read a PCAP file.  Just keep in mind that you are both changing the config of that router (with the access list), and enabling a debug, which can impact both CPU and Network utilization.  So be sure to get permission – in many IT shops, this will take the form of a Change Control Request.

After we’ve gone through this process, some of you are probably asking – “Rob, why would I want to go through this just to capture a few packets?”  My answer to this might be “Perhaps there are no PC’s at the remote location”, or “Maybe you’re not allowed to install a packet capture program on any of the remote PC’s”, or “the switch at the remote location might not support a SPAN port”.    But the best answer is “Why *wouldn’t* you want to do this at least once just for fun – isn’t this the neatest thing ever?”

This process might seem to be a bit complex, but once you have the awk code up and running, the mechanics of actually collecting and processing the packets is pretty streamlined and goes very quickly.   If you find any cases where the code might need improvement, please shoot me a note and I'll try to address it.  If you use this code to solve an interesting problem, please share your experience - there's a "Comment" button at the bottom of this entry.  Have fun, with this, I hope you find it useful! 


Note: If you are running linux, AWK is generally included as part of even the most basic distro installations.  If you are a Windows user, you can get AWK from the Windows 2003 Subsystem for Unix Applications (SUA), or you can download GNUutils (http://www.gnu.org/software/coreutils/ ), which will give you a number of *nix utilities as native EXE files, or install cygwin to get native linux support.


Published: 2009-11-17

Metasploit Framework 3.3 Released

The Metasploit Project released Metasploit Framework 3.3 today. This version contains 446 exploits, 216 auxiliary modules and hundreds of payloads. The Windows payloads now support NX, DEP, IPv6, and the Windows 7 platform. This release fixes 180 bugs since version 3.2 was released.

The new version of The Metasploit Framwork is available download here.


Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot org


Published: 2009-11-17

OpenVPN Fixed OpenSSL Session Renegotiation Issue

OpenVPN released an update to respond to the OpenSSL vulnerability described in CVE-2009-3555. OpenVPN has identified a vulnerability caused by an error in OpenSSL which could be exploited by attackers to manipulate certain data and information.

OpenVPN recommend upgrading to version 2.1_rc21 which is available here.

Additional information regarding OpenVPN session renegotiation is available here.


Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot org


Published: 2009-11-16

Reports of a successful exploit of the SSL Renegotiation Vulnerability?

Its a brand new week...  and what a way to start off a brand new week with a report of someone sucessfully exploiting the SSL Renegotiation Vulnerability against a rather "popular" Internet property.

Read all about it here.

G.N. White

ISC Handler on Duty



Published: 2009-11-14

Microsoft advisory for Windows 7 / Windows Server 2008 R2 Remote SMB DoS Exploit released

Microsoft has released an advisory for the Windows 7 / Windows Server 2008 R2 Remote SMB DoS Exploit the ISC discussed here: http://isc.sans.org/diary.html?storyid=7573. CVE-2009-3676 has been assigned to the vulnerability. The advisory is here: http://www.microsoft.com/technet/security/advisory/977544.mspx

This vulnerability is not related to MS09-050, it affects both SMBv1 and SMBv2, and is brand spanking new. Disabling SMBv2 is not an effective mitigation. The impact is strictly a Denial of Service attack, no remote code execution.

Assuming that you block TCP ports 139 and 445 the only impact would be an internal attacker could disable affected systems until restarted. In the grand scheme of things this would not be a critical issue unless all of a sudden your servers had to be rebooted on a regular basis, in that case you may have bigger problems because the fox would already be in the henhouse.

The list of affected systems is: Windows 7 for 32-bit Systems, Windows 7 for x64-based Systems, Windows Server 2008 R2 for x64-based Systems (includig Server Core), and Windows Server 2008 R2 for Itanium-based Systems.

Presumably Microsoft will release a patch in the near future, either out of band or in the next batch of 'patch Tuesday just before pray and reboot Wednesday'.

Adrien de Beaupré


Published: 2009-11-13

Conficker patch via email?

Microsoft does not send patches, updates, anti-virus, or anti-spyware via email (hopefully ever). The following ended up in my inbox this aft. The subject was: Conflicker.B Infection Alert

"Dear Microsoft Customer,

Starting 12/11/2009 the ‘Conficker’ worm began infecting Microsoft customers unusually rapidly. Microsoft has been advised by your Internet provider that your network is infected.

To counteract further spread we advise removing the infection using an antispyware program. We are supplying all effected Windows Users with a free system scan in order to clean any files infected by the virus.

Please install attached file to start the scan. The process takes under a minute and will prevent your files from being compromised. We appreciate your prompt cooperation.

Microsoft Windows Agent #2 (Hollis)
Microsoft Windows Computer Safety Division"

Attachment is 3YMH6JJY.zip application/zip 45.82 KB and detection at Virustotal is soso: https://www.virustotal.com/analisis/5d8caa7c9baaed6242e3842e0dafea5056f41d9c99732f0fd2961bedff647ae5-1258134283

Adrien de Beaupré




Published: 2009-11-13

Flash Origin Policy Attack

An apparently critical vulnerability in Adobe Flash has been identified that could allow sites with user generated content to attack clients. Adobe has been advised but has not issued an advisory as of yet, and no patch or easy mitigation information is available. It is possible of course to disable Flash entirely, or even selectively using addons and plugins for your browser of choice.The original disclosure is here: http://www.foregroundsecurity.com/flash-origin-policy-issues.html

I would wonder what methods of detecting this exploit exist?

Adrien de Beaupré



Published: 2009-11-13

TLS & SSLv3 renegotiation vulnerability explained

Thierry Zoller has written a nice summary of the TLS & SSLv3 renegotiation vulnerability. He covers examples, impacts, solutions, and a conclusion. It can be found here: http://www.g-sec.lu/practicaltls.pdf. The ISC previously discussed the vulnerability here: http://isc.sans.org/diary.html?storyid=7534 and the OpenSSL update here: http://isc.sans.org/diary.html?storyid=7543.

Adrien de Beaupré
Intru-shun.ca Inc.


Published: 2009-11-13

It's Never Too Early To Start Teaching Them

Last week it was my pleasure to visit a group of middle school students that are interested in anything Science.  These young people were eager to learn and had prepared many really good questions about viruses, worms and other malicious programs as well as other dangers found on the Internet.  As they asked their questions and received the answers they became more and more excited about the task ahead of them.  You see this group is involved in a special after school education program. They spend several weeks working together on a project and then compete against other groups of young people.  The group I talked to are tasked with creating a virtual world on the Internet.  They are tasked with coming up with a plan to protect this virtual world against the dangers that it faces.  

In the discussion I mentioned that many of us in the Security Field think that people should have to pass a test and get a license before operating in the Internet.  So one of the things the kids are working on is a "Driver's Test" for the "Internet Super Highway".  They are also working on a "plan" for protecting their virtual world.  I am really looking forward to seeing what they come up with.  

I enjoy going out and "meeting" young people and talking to them about the dangers in Cyberspace and how to protect themselves, their families and their identity.  Perhaps someday this group of students will come up with some new and creative ideas about how to create a safe virtual world.

I encourage all of you to go out in your communities and talk to the young people, help them understand the Internet Superhighway and the dangers that are just around the corner.  With all of us working together we could really make a difference. To my new young friends I want to say that you are the hope of the future, never stop learning, never stop trying to improve the world we live in or the virtual world we "play in".  You truly are our hope for the future.

Deb Hale Long Lines, LLC


Published: 2009-11-13

Pushdo/Cutwail Spambot - A Little Known BIG Problem

Today was another one of those days that all ISP's dread.  I am the Abuse Coordinator for a small Midwestern ISP.  Several days ago we started receiving Spam Abuse reports on the IP address to our Corporate firewall.  Unfortunately,  the IP I discovered is blocklisted on several blocklists.  I began to investigate what could be causing these reports of abuse.  I reviewed the logs in the firewall and discovered that we had a couple of workstations doing some bad things.  Our It techs began to look at the computers (both of which had AV installed) and discovered that we had some pretty significant infections on these computers. Both machines were pulled offline, the data backed up and the machines were formatted and reloaded.  We were pretty confident that we had solved the problem and breathed, an unfortunately premature, sigh of relief. 

Yesterday we again started getting abuse reports so it was back to the drawing board for me.  I started trying to get information on exactly what was being detected and what was causing these abuse reports.  This investigation led me to MultiRBL.org.  We were indeed listed on several blocklists again.   As I began to look at the various blocklists looking for the answers it became apparent that we will dealing with a Trojan/Botnet called Cutwail Spambot aka Pushdo aka Pandex.  The interesting thing is, I hadn't never heard of it. So last night I began to research just what this Cutwail Spambot was.  What I find out just blew me away.

I came across an article from Trend Micro Researchers Alice Decker, David Sanchog, Loucif Kharouni, Max Goncharov, and Robert McArdle.  The article is titled A Study of the Pushdo /Cutwail Botnet, An Indepth Analysis. The article indicates that this particular botnet has been around since January 2007 and is the second largest spam botnet on the planet. This particular spambot is believed to be responsible for approximately 7.7 billion spam emails per day making it responsible for 1 out of every 25 spam emails sent world wide. According to the findings of the research team the development team for Pushdo/Cutwail work very hard and used several techniques to keep their program "under the radar".  In the article they outline these techniques which include things like using multiple variants that react a bit differently, remain memory resident, with very little actually written to disk, and frequent updates and changes to the code to prevent discovery.

This article contains an indepth look at the botnet and gives good insight into how to detect and control the botnet.  This article is well worth reading. Other research that I have done indicates the best program to find the Pushdo/Cutwail Spambot is Microsoft's Windows Malicious Software Removal Tool.

MALWARE DEVELOPMENT AND DIRECTION" gives additional information about the botnet and gives detailed information and instructions for ridding your network of the botnet.

Our tech's have their work cut out for them.  They are going to have to "touch" all 250 employee computers (249 - mine is clean) plus all of our Windows Servers so that we make sure that we get rid of all of the infected computers.  We are also investigating a change in Anti-virus software.  Unfortunately the one we have been using has fallen into the category of less that reliable so now we are trying to decide what we need to switch too.  Now is as good a time as any, after all we are going to have to "touch" every computer.

I am just amazed that this botnet is the 2nd largest in the world, been around for almost 3 years and I am just now dealing with it.  We still haven't figured out how this botnet got started, we aren't sure where it started at, but we do know we can't wait to rid our network of this mess.

Everyone who manages networks no matter what the size needs to read these articles and know what to look for and how to recognize the presence of the botnet.  I for one vote for irradication of this botnet and a reduction of 7.7 Billion spam emails a day.  Sure would make my spam filter easier to manage.  Wouldn't it be great to somehow eliminate these bad guys.

Check out the articles at:

Matt McCormack Article - download.microsoft.com/download/3/8/d/.../McCormack-VB2008.pdf

Trend Micro Article - us.trendmicro.com/imperia/md/content/us/pdf/.../study_of_pushdo.pdf

I would be interested in hearing about other people's experiences with this Botnet and in finding out if you have any good tips for detecting and "killing" the bot.  So let's hear from all of you botherders out there.


Deb Hale Long Lines, LLC


Published: 2009-11-12

Windows 7 / Windows Server 2008 Remote SMB Exploit

Mikael wrote us yesterday, telling us about a site claiming to have a zero day for SMB on both Windows 7 and Windows Server 2008.  Thanks for the pointer Mikael,  Laurent Gaffié is the original author of this bit of code.

However, after a first try, we found that the code didn't run as posted.  Nothing major, one required line of code was missing, and some formatting issues.  Given what this code does, these omissions might have been intentional, to give Microsoft a chance to get a fix in before this disseminates.  The code does in fact work.  The sequence to see the exploit is:

1/ On a linux machine, ensure that port 445 is open or that your firewall is down - ensure that the target windows host and the linux host have connectivity (a quick ping does the trick here)

2/ On that linux box, run the resulting code - "sudo python w7spolit.py" .  Note that you need sudo to open a tcp service, and we're using a linux box for this because of course port 445 is taken on most windows hosts.

3/ On the target Windows box, do a "net use x.x.x.x", where x.x.x.x is the ip address of the linux box.

You'll see that the Windows host is frozen - no mouse, no keyboard, and completely unresponsive on the network as well.  This works on both Windows 7 and Windows Server 2008, with the very latest patches applied.  As the author states, disabling SMBv2 does not give even temporary protection.  Here's hoping Microsoft scrambles the troops to get this patched before it's out in the wild.




Published: 2009-11-11

Apple Safari 4.0.4 Released

Safari 4.0.4 was released today for download, affecting boith OS X and Windows versions.

Multiple security issues are addressed in this version, including remote code execution, process termination and disclosure of information issues.  Also one fix for a specific coss-site request forgery (CSRF)

Full details can be found here ==> http://support.apple.com/kb/HT3949



Published: 2009-11-11

Layer 2 Network Protections against Man in the Middle Attacks

Last month (Day 9 of Cyber Security Awareness Month) we discussed a Man in the Middle (MITM) attack against RDP (Microsoft’s Remote Desktop Protocol), along with Man in the Middle protections for RDP services.  The article and video illustrate the just how easy it is to mount a man in the middle attack using ARP cache poisoning.  We've also recently covered recent research in SSL Man in the Middle vulnerabilities and this month's issues concerning MITM attacks against TLS renegotiation .   Today's entry discusses network protections that provide mitigation for all services against such attacks (not just a specific protocol or vulnerability).  We’ll be discussing mitigations that can be applied in most corporate settings (Private VLANs aren’t covered).

Just a quick recap - Layer 2 MITM attacks are often based on ARP poisoning, and the mitigation against this is what we’ll be discussing today.  ARP poisoning consists of an attacker sending a gratuitous ARP packet (an unsolicited ARP reply) to the target hosts, so that the target client and server both think that the attacker is the host at the other end of the conversation.  After this is accomplished, the attacker will now intercept all traffic between the hosts, which can be simply recorded and forwarded on, or modified before forwarding.  A more complete explanation of the mechanics can be found in last month’s entry (check the video for the details)

The configuration commands shown in this article are for Cisco IOS, but equivalent commands are available on Brocade, HP and most other managed switches on the market today.  We’ll be covering DHCP Snooping, Dynamic ARP inspection, IP Source Guard, and Rate Limiting of ARP packets. 

DHCP Snooping

DHCP Snooping intercepts all DHCP traffic, and maintains a table of MAC addresses to IP Addresses called a DHCP Snooping binding database.  This sounds a lot like an ARP table, but is used instead to validate ARP traffic to protect against Man in the Middle Attacks which might poison the ARP table. 

DHCP Snooping by default blocks all DHCP offer packets inbound to the switch port, which means that if a DHCP server is on that port, the DHCP requests will  reach the server, but the addresses will never reach the DHCP client.  So after enabling DHCP snooping, configure any ports that have DHCP servers attached, or uplink to switches with DHCP servers as “trusted”.

It makes good sense to periodically store your DHCP Snooping database to flash memory or a tftp or (preferably) an scp server.  Without this, if a switch is rebooted, clients on untrusted ports will not have connectivity until they renegotiate a DHCP lease.

Anyone who has ever had a home router (with its DHCP server) appear on their corporate network knows how disruptive this can be, and can attest to just how valuable these DHCP snooping functions can be just to mitigate that one situation.


Switch(config)# ip dhcp snooping
Enables DHCP snooping globally.
Switch(config)# ip dhcp snooping vlan 1,2,6 Enables DHCP snooping on VLANs 1, 2 and 6 (this of course will be unique for each site)
Switch(config)# int g0/7
Switch(config-if)# ip dhcp snooping trust
On the port with the DHCP server (gig 0/7 in this example), enable dhcp snooping trust
Switch(config)# ip dhcp snooping database tftp:// On bootup, read the dhcp snooping database from a tftp server

Dynamic ARP inspection (DAI)

This feature uses the table created by the DHCP Snooping feature to validate all ARP responses that arrive inbound to switch ports.  Gratuitious ARPs are integral to all Man in the Middle attacks that use ARP Cache poisoning.  What DAI does is simply drop all ARP replies that do not have corresponding entries in the DHCP Snooping binding database.  ARP reply packets where the MAC address in the body of the packet do not match the MAC address in the Ethernet header are also dropped.

In non DHCP environments, DAI can operate against a statically defined ARP ACL. 
Ports that have multiple MAC addresses, such as uplink to physical or virtual switches, should be configured as “trusted”, this bypasses all DAI functions.


Switch(config)# ip arp inspection vlan 1 Turn on arp inspection for vlan 1
Switch(config)# int g0/8
Switch(config-if)#  ip arp inspection trust

trust int g0/8 to have multiple arp entries - for instance, uplinks to
physical or virtual switches, clusters, load balancers in some cases.


IP Source Guard

This feature uses the DHCP Snooping database as well, but takes things one step further.  When a client host powers on, IP Source Guard will filter all traffic to and from that port except for the DHCP request and reply traffic.  Once the address is assigned and the DHCP Snooping entry is populated for the port, any traffic received from that port from a different ip address is filtered.



Switch(config)#  Int g0/8
Switch(config-if)#  ip verify source
Enable ip source guard on one interface


Switch(config)#  int g0/8
Switch(config-if)#  ip verify source vlan dhcp-snooping
Enable ip source guard for all vlans defined on this interface


Rate Limiting Incoming ARP Packets

Many tools that perform Man in the Middle attacks  based on ARP poisoning will generate large volumes of ARP reply packets (Gratuitous ARPs).  Switches can generally be configured to Rate Limit these packets, and in many cases can be configured to either alert if a threshold is exceeded, or to place any ports that exceed a configured threshold in an error state, either for a configured period of time or until manually reset.

By default, when dynamic ARP inspection is configured, ARP packets are rate limited to some default value (15 per second on cisco platforms, but this may vary on other switches)


Switch(config-if)# ip arp inspection limit rate 20

configure arp inspection for 20 packets
per second.  By default, if this is
exceeded, the port is placed into an
"errdisable" state.

Switch(config-if)# errdisable recovery cause arp-inspection interval 240 re-enable the errdisable'd port after
240 seconds.


Caveats and Comments on Layer 2 Network Protections

Many network components require on changing MAC addresses, so care should be taken when defining protections against ARP poisoning.  These features should be disabled on interfaces that have components that have:

  • Standby features such as vrrp, vrrp-e, hsrp and similar router or firewall clustering applications
  • load balancers, or hosts configured with load balancing solutions such as Microsoft NLB
  • Any clustering application such as microsoft, linux, solaris or other clustering solutions
  • Ports that connect to Vmware ESX vswitch uplink ports, as a vmotion involves a virtual server mac migrating from one physical switch port to another with a corresponding RARP packet after completion.
  • Switch ports that connect to ESX uplink ports that support load balanced or failover configurations for the ESX Service Console or vmkernel ports.

Features such as rate limiting of ARP packets, Storm control and port security (these 2 aren't covered in this post) can simply disable ports if their function is triggered.  Unless configured for recovery, disabled ports remain in an Error Disabled state until manually re-enabled. Needless to say, this can cause major service disruptions unless implemented carefully.

While there are certainly some things to watch out for in implementing these features, the benefits of configuring the protections we've discussed almost always outweigh the risks (by a country mile).  Most enterprises should really consider implementing at the very least DHCP Snooping and Dynamic ARP Inspection.


Published: 2009-11-10

Microsoft November Black Tuesday Overview

 Overview of the November 2009 Microsoft patches and their status.

# Affected Contra Indications Known Exploits Microsoft rating ISC rating(*)
clients servers
MS09-063 Random code execution due to a memory corruption vulnerability in a service for working with PDAs. Only affects Vista and Server 2008. This service listens on ports TCP port 5357 and 5358 and outbound UDP port 3702 and is enabled when a user browses for devices on their network.

KB 973565 No known exploits. Severity:Critical
Critical Critical
MS09-064 Random code execution due to an input validation failure. Only affects Windows 2000. This license server is enabled by default, it uses RPC over TCP ports 139 and 445.
License logging Server

KB 974783 No known exploits. Severity:Critical
N/A Critical
MS09-065 Multiple vulnerabilities allow random code execution or privilege escalation.
Replaces MS09-025.
Kernel-mode drivers

KB 969947 No known exploits, part of the vulnerability in CVE-2009-2514 was made public. Severity:Critical
Critical Critical
MS09-066 Denial of Service vulnerability in the LSASS service. This uses TCP ports 389, 636, 3268, 3269
Replaces MS09-021 and MS09-035.
Active Directory

KB 973309 No known exploits. Severity:Important
N/A Important

Multiple vulnerabilities allow random code execution.
Replaces MS09-021.

Office: Excel

KB 972652 No known exploits. Severity:Important
Critical Important

An input validation vulnerability allows random code execution.
Replaces MS09-027.

Office: Word

KB 976307 No known exploits Severity:Important
Critical Important
We will update issues on this page for about a week or so as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
(*): ISC rating
  • We use 4 levels:
    • PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
    • Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
    • Important: Things where more testing and other measures can help.
    • Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
  • The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
  • The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
  • Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
  • All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them

Swa Frantzen -- Section 66


Published: 2009-11-09

Apple Security Update 2009-006 for Mac OS X v10.6.2

Apple has released updates ranging from general operating systems security updates as well has fixes to enhance the stability and compatibility for Mac OS X version 10.6.2. The entire list of updates is available here. These updates may be obtained from Apple's Software Download web site here.


Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot org


Published: 2009-11-09

80's Flashback on Jailbroken iPhones

Those of us who spent our formative years in the 80's would know, but for those a bit younger, if you have a jailbroken iPhone and are wondering who just appeared as your wallpaper, it's Rick Astley, a singer who was (at least somewhat) popular in the 80's.  His video was the first example of "rickrolling"

Chris (nice name btw) pointed us to a forum where the owner of a jailbroken iPhone reported the change in wallpaper which also included the words "ikee is never going to give you up", a reference to one of Rick's songs.

Computerweekly.com has a nice article on the worm, which is being called ikee.

Sophos also has a nice article.

And yes, despite the massive temptation, all the links in this article point to where they should.  :)

Christopher Carboni - Handler On Duty


Published: 2009-11-08

FireEye takes on Ozdok and Recovery Ideas

The folks over at FireEye report (http://blog.fireeye.com/research/2009/11/smashing-the-ozdok.html) on one of their takedown efforts of the Ozdok (aka Mega-D) botnet.  Victims of this infection have pop-up advertisements pushed their system and they are used to send spam—a significant amount of spam according to M86 Security (http://www.m86security.com/TRACE/traceitem.asp?article=510).  More information is available from Joe Stewart: http://www.secureworks.com/research/threats/ozdok/.

This is good news.  A major spam source has been disrupted.  Unfortunately we’re still left with thousands of machines that have been infected.  In many cases of adware/spyware infection the malware with disable or impede Anti-virus programs, leaving these machines unprotected to follow-on infections.  Taking down Command and Control servers and registering the future/fallback domains is time-consuming and expensive.  Yet compared to the effort required to clean up all of the infected systems it’s only the tip of the iceberg.

A centralized plan or organization to drive such an effort is doomed to fail.  The response needs to be community-driven, decentralized, and personalized.  Organizations may be able to support an incident response team, but individuals cannot.  Law Enforcement treats this as an individual’s problem, the individuals’ think law enforcement should act, and ISPs are stuck in the middle.  There are opportunities there, but it’s risky. I’m fond of the idea of walled-garden services—I’m more fond of optional walled-gardens (which brings more expense to the ISP.) 

Although the information about what is a bad URL and what isn’t can be centralized, its delivery has to be decentralized.  Services like OpenDNS are attractive and I have hopes that it will be successful.  Web filtering  services can have a big impact on not only malware, but also phishing attacks.  There’s one feature that I haven’t found in the web filtering services yet (I hope they’re reading this.)  I would like to have the option to block access to all domains that are younger than X days.  For some folks, 1 or 2 days is fine, other organizations might like 7 or more.  This shouldn’t be too hard to implement with some whois-lookups, right?  Or better yet, allow the new domain in, if it’s been categorized by the filtering service, but block it if nobody has evaluated it yet.  Perhaps someone could write a FireFox plugin to implement this block for folks who can’t afford a web-filtering service?


Published: 2009-11-08

Even More Thoughts on Legacy Systems

Legacy systems have been a popular topic here recently (see http://isc.sans.org/diary.html?storyid=7528 and http://isc.sans.org/diary.html?storyid=7546).  Any environment of sufficient size, complexity or age will have its share of legacy systems.  While we can work with policy and management to phase them out, in the meantime one has to deal with the fact that they’re on the network and vulnerable, which makes your network vulnerable.  Does it have to be that way?

Consider this simplified example: your company makes widgets, the widget-making machine is computer controlled, and the company that wrote the software is now out of business, so there is no chance of upgrades or patches in your future.  A bad-case example scenario: a consultant from Acme Industries comes into your facility with a laptop infected with an old worm (say Downandup,) and when they connect to your network it infects your widget-making machine.  Hilarity ensues.

A possible solution is to reconsider why that legacy machine needs to be on the network.  Do you know why?  It’s probably serving a web application, or someone is VNCing into the system to manage, or it has to send out status emails, etc.  That’s the first step: understand what services are required.  Then, use another device (because if you could lock down the legacy system it would already be locked down, right?) to isolate that system.  Old techniques like Access-Control-Lists, and Virtual LANs won’t block a dedicated human attacker, but against automated malware it can be quite effective.  If you have to expose a vulnerable service, limit that exposure to known and trusted systems on your network, not to everyone on you network.  Also, make sure that the isolation works both ways, if something manages to get into the system, you can at least limit it from spamming out to the rest of your network.

This approach also works when you have to plug a vendor’s “Appliance” into your network.


Published: 2009-11-08

iPhone worm in the wild

Couple of days ago there were a lot of discussions about an attack on iPhone users in the Netherlands where the attacker installed a backdoor that asked the iPhone owner to pay 5 EUR to get rid of the Trojan.

The attack was aimed exclusively against jailbroken (hacked) iPhones – these phones allow the user to run unofficial code and bypass Apple's official App Store. In other words – it allows users to run (often) pirated programs.

One of the problems with most jailbroken iPhones is that they run various services, including SSH among the others. The installation of SSH service is terribly insecure and, besides allowing remote root login, also leaves a default password on most jailbroken iPhones. This "vulnerability" was used by the hacked in the Netherlands and the same thing is exploited by the worm named iKee that was published today.

The worm is written in C and contains a lot of comments – one can see that the author was not the most experienced C coder but nevertheless he managed to get the worm to work.

iKee worm

The worm is actually very, very simple. After execution it will scan certain IP addresses (you can see the list on the screenshot above). All IP addresses belong to 3G customers in Australia and are hardcoded in the worm. If an IP address is reachable, the worm uses a Cydia application to try to login to the IP address as root – it presumes that it is an iPhone since only 3G networks are scanned.

If the login was successful, the worm will copy several files (including itself) to the vulnerable iPhone, will kill SSH (so the phone can't be infected again or by a different attacker) and will change the background as well.

While this is maybe the first iPhone worm that was actually detected in the wild, and while it is very simple, it definitely highlights the risks of running unauthenticated code, something that a lot of people using hacked/jailbroken iPhones are not aware of. Similarly as not running a pirated version of an operating system on your machine, one should not try to evade security mechanisms implemented in phones, especially since they can contain a lot of sensitive personal information.




Published: 2009-11-07

More Thoughts on Legacy Systems

Adding to Swa's diary he wrote on November 5th, one of our readers passed along a couple of additional thoughts on legacy systems to us today:

1. It's not only "legacy" systems that require IE6.

A local post-secondary educational institution spent > $40 million to replace their legacy administrative systems with one of those out-of-the-box integrated systems (the only contenders in this category are BANNER and PEOPLESOFT), only to find that the system requires IE6 on each user's workstation. 

So, they have a large project (scheduled to complete next Spring) to take all their customizations forward into the latest version of the vendor's software.

The staff is not happy that management is blocking all vacation-requests, in order to meet the project's deadline -- in an academic environment, there are very few "windows" where a major software-upgrade can occur, because students work online 24/7, need their marks, and need to register for the next semester.

Until then, their local WSUS-server is not deploying IE7 to all the "managed" workstations.

So, until then, "IE6 rules".

2. If you know that your Windows XP system will not "pass" the Windows Genuine Advantage validation -- you know who you are, and you know from where you obtained your copy of Windows XP -- you cannot install IE7. So, you continue to use IE6, or you use Firefox.

Thanks, anonymous reader!

Marcus H. Sachs
Director, SANS Internet Storm Center


Published: 2009-11-06

New version of OpenSSL released - OpenSSL 0.9.8l

Due to the recent publishing of information regarding a TLS/SSL protocol vulnerability (previous ISC diary entry can be found here http://isc.sans.org/diary.html?storyid=7534)  OpenSSL has released a new version (OpenSSL 0.9.8l). It should be noted that this update does not "fix" the vulnerability in the protocol. It appears that they have made the choice to simply remove TLS/SSL renegotiation from their package by default.  I would urge  anyone who is running a SSL enabled site that uses OpenSSL to thoroughly test their application as well as any software clients that are in used with their application.  There has been some discussion on the effects of simply removing renegotiation from these packages or disabling them by default (as OpenSSL has done). There will no doubt be instances where clients/servers will cease to function properly when renegotiation is disabled or removed.  The nice thing about what OpenSSL has done is if you do run into issues, it appears to be an easy fix (set a flag and -hup!).  So as always make sure to test vigorously before you deploy!

You can get this new version of OpenSSL at the link below.


Release note from OpenSSL package:

    Disable renegotiation completely - this fixes a severe security
    problem (CVE-2009-3555) at the cost of breaking all
    renegotiation. Renegotiation can be re-enabled by setting
    run-time. This is really not recommended unless you know what
    you're doing.
    [Ben Laurie]

This event will no doubt develop over the next coming weeks and months, it should be interesting to see how far research goes into other protocols that ride on top of TLS/SSL channels. Let us not forget that not all traffic that is TLS/SSL encrypted is HTTP. Just off the top of my head I can think of LDAP, MSSQL, Email, and let us not forget SSL VPNS!  Since this is a bug in a low lying protocol that higher level applications/protocols rely on there will no doubt be allot of interest issues raised. No doubt plenty of people including myself will have a busy weekend rereading the TLS specification.  For those who are bored, feel free to read that specification at the URL below. 

 TLS 1.0:  http://www.ietf.org/rfc/rfc2246.txt

SSL 3.0: http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00


Andre Ludwig


Published: 2009-11-05

RIM fixes random code execution vulnerability

Affected: BlackBerry Desktop Software version 5.0 and earlier (on all platforms) - IBM Lotus Notes Intellisync

Fixed in version 5.01

CVSS score: 9.3


More info: KB19701

The KB contains a workaround for those not eeding the Lotus Notes Intellisync functionality.

Thanks to Greg for sending this in.

Swa Frantzen -- Section 66


Published: 2009-11-05

TLS Man-in-the-middle on renegotiation vulnerability made public

TLS 1.0+ and SSL 3.0+  (known from among others "https") is vulnerable to a protocol weakness where a man in the middle could work during the renegotiation phase in modern versions the protocol.

While the details had been offered in a meeting with the IETF, vendors and the open source implementers of SSL privately, it appears an IETF mailing list came to finding it again.  That seems to have prompted the original finders (Marsh Ray and Steve Dispensa) to offer up their finding publicly.

The news media outlets are obviously all over this.

Some links aside of the usual media outlets:

There does not seem to be much you can do till the protocol is fixed. The main problem seems to be with clients using certificate authentication.

Exploiting this requires the attacker to be able to intercept the traffic.

Thanks to Martin, Edward, Ken and Chris for sending this in.

Swa Frantzen -- Section 66


Published: 2009-11-05

Insider threat: The snapnames case

Insider jobs are not often made public. So, when one does come around it's very interesting to try to learn from those we can talk about. Even inside a company often there is not much said about it to other employees, making learning from it extra difficult unless you were involved somehow.

Snapnames is the company fessing up. Snapnames is in the "domain name after market": they grab domains that are expired and sell it in auctions to people they have in their customer base. There are more such companies.

Like any auction driving up the price is supposed to be the interest in the domain. And unlike a regular auction, the seller is the auction house itself - they grabbed it expired, it costs them the absolute minimum to get it, if they sell it for thousands: that's thousands of profit for them.

A shill is "a person who poses as a customer in order to decoy others into participating, as at a gambling house, auction, confidence game, etc." according to the dictionary. It's used in this context as a person who drives up the price artificially.

So what happened ?

  • A snapnames employee participated in 5% of auctions since March 2005.
  • Snapnames has a fessed up in email to some affected customers about it and is offering financial restitution to those affected by it. They do have a FAQ entry on that available at http://www.snapnames.com/faq.html
  • There are rumors that seem to get confirmations that the employee was a VP of engineering using the username of "halvares", and it seems to have been confirmed by the company.
    [I'm not going to republish his real name, there's plenty of places to find it for those interested]
  • Forum threads dating back to 2006 have customers of snapnames find the user "halvares" suspicious: http://www.dnforum.com/f205/important-message-snapnames-thread-197282.html
  • People who knew said person describe him as "the kind of guy that you wanted working on the other end of the phone; fast, courteous and intelligent.  To find out now that he was lying and betraying not only me, but everyone that he worked with leaves me speechless.  It left a fellow employee I spoke with at SnapNames speechless as well.  With such a small organization, I can only imagine the feeling of betrayal." [From http://www.domainnamenews.com/editorial/snapnames-insider-bidding-aftermath-editorial/6491]
  • Namejet -a competitor of snapnames- sent out the following to their customers:

Dear Valued NameJet Customer,

As you may have already heard, another company in our same line of business, SnapNames, was the victim of an internal security breach. We wanted to address any concerns you may have and assure you that at NameJet we have the necessary security protocols in place to prevent this kind of incident.

What Happened at SnapNames:

According to SnapNames, an employee set up an account on SnapNames under a false name. Under this account, the employee bid in SnapNames auctions. In many instances the bidding by this employee caused the ultimate auction winner to pay more for a name than had the employee not participated in the auction. In addition, on certain occasions, when the employee won an auction, the employee secretly arranged for a refund from SnapNames. This was in violation of SnapNames internal policy, and once discovered the company immediately closed the account in question and the employee was dismissed.

We commend SnapNames for taking quick and decisive action once it discovered its security breach.

NameJet has Strict Security to Prevent Anything Similar:

You should have full confidence nothing similar has occurred on NameJet. We have security procedures and policies in place that monitor all activities to ensure that “shill” bidding does not occur. Further, employees are strictly barred from bidding on auctions and NameJet has both internal and external monitoring to ensure all security procedures are enforced. These procedures were developed and are maintained by two of the world’s largest and most trusted registrars.

Thank you for your business and for your ongoing trust in NameJet.

If you have any questions regarding this issue, please contact us at customers@namejet.com.


Steve Brown
General Manager

  •  Snapnames is said to have fired the employee and is working with an external party to settle it financially with those they think are affected.

What can we learn ?

  • That insider threats can be extremey damaging to your reputation, as evidenced by your competitors jumping all over it.
  • That the insider -in order to fly under the radar ?- is perceived as an excellent team member :"[the one] that you wanted working on the other end of the phone; fast, courteous and intelligent.
  • Those directly involved will feel betrayed because they trusted too much.
  • Polices alone might not be enough, we need to enforce them. And we need to actively detect breaches of our policies.
  • Detecting it is difficult. This went on for 4.5 years.
  • Suspicions had been raised by their customers after half a year, yet it seems to not have triggered whatever was needed for snapnames to catch him.

What can one implement in the form of controls to detect fraud ?

  • A policy prohibiting unwanted behavior. Make sure it passes the "speed limit test":  If -out on the road- it says 50 max and there is no consequence to going faster, who'll bother with it ? Even if there is a fine or other consequence, as long as there is no police officer wielding a radar, who'll care about the fine ?
  • Limit access to information using a role based model.
  • Use a need to have model for granting access rights.
  • Prevent accumulation of rights in any single employee.
  • Monitor what people who have broad access permissions to dangerous data do in real life (within limits of the law and regulations regarding privacy etc.), even if you trust them.
  • Rotate roles: don't let anybody get a position where they are the only ones doing the same thing every time it needs to be done. Hiding it becomes too easy if nobody else does that task for a long enough period.
  • Monitor for indicators changing when you rotate peoples responsibility. Seek the explanation for those changes.
  • Monitor for fraud: 5% of your transaction having the same account involved might be enough to dig a bit deeper
  • Automatically seek for fraudulent patterns in your transactions. This is the needle int he haystack, but computer are good at searching, as long as we can define the needle good enough.So you need to figure out how fraud could happen and what is unwanted behavior etc. and then find that. E.g. a sales person in your company might have read/write access to the directory where you keep the offers your company creates. But if you find a sales person copying (even slowly) every single offer, you might have a big problem.
  • As you learn more ways to commit fraud make sure you monitor for them.
  • Monitor for customers expressing suspicions on your users/employees/company outside of your involvement on e.g. forums where the professionals among your customers hang out and feel free to talk. They might not always need to be the type wearing tin foil beanies, sometimes they might have a point that could take years to grow if you don't follow it up..

 Got more lessons to learn or controls to implement, we love to hear about them!

Swa Frantzen -- Section 66


Published: 2009-11-05

Legacy systems

IT in general is riddled with legacy system. They are inheritances of a past we 'd like to forget or we might even cherish them. But they have a tendency of harboring nasty surprises.

In an economic climate where investments are a bit less likely than they used to be, there is fear we'll end up with more legacy systems than ever before. Moreover people aren't buying the "shiny new" all that easy anymore regardless of the economic climate.

But there is more. Even free software that is as easy to upgrade to as a single click isn't being upgraded. In controlled corporate environments there might be reasons of compatibility, but even home users don't upgrade to in some striking cases. E.g. IE6 -a decade old browser, hated by anybody doing anything beyond basic CSS- has had 2 new versions people are automatically upgraded to, and yet it still has a population of users that is significant, even among the Storm Center's visitors -last month- more than 17% of our IE using visitors still were on that legacy version (data from Google Analytics). Not work-related websites also report numbers of 12 to 15% of IE users not having upgraded to IE7 (itself a legacy version) or IE8.

There is of course a general IT impact of supporting legacy systems, which can be a pain. Add in the lack of planning for problems with such systems and it all becomes a nightmare scenario. Look e.g. at what hit the news regarding the failing synchronization of traffic lights in the DC area (Thanks for sending this in Angela!). The failure as such is a problem one might argue, but statements like "Parts are not really available" are worrying to a great extend. BCP/DRP issues abound.

But there is also a huge security impact. Threats change. If you run things a decade old -even if the top security bugs do get fixed- you still have an architectural model for your defenses that's a decade old or more. A decade is a lot in IT and in security. A lot changes in that time.  Now you might argue using old technology puts you out of the hot-spot where the attackers focus on. While that is true to a point, attackers, security researchers and bug fixers all focus on the latest greatest version. If we all start to slack in upgrading, the attackers might not shift their focus to where the researchers and fixers of bugs are focusing anymore, changing cat and mouse game to one where the mice aren't being watched by the cats anymore. Moreover we know from dshield data that scans for old vulnerabilities never really stops anyway.

So what can each of us do in our corner do to make the world a better place - and have our customers/employers not end up in the news with 30 year old hardware running a mission critical system and failing impacting many thousands ?

An inventory comes to mind as a first control measure. If you don't even know you have a legacy system, there will be nothing that's going to be done until it fails and hits you.

If you can, figure out for all used hardware and software

  • if there is still a way to support it somehow, and how difficult that is
  • when the support will be stopped
  • how critical it is, and if it's taken into consideration properly in BCP/DRP plans

Make a plan, at least for every legacy system out there. [this is really part of your BCP plan, but I'll assume many lack such detailed plans]

  • How will you phase it out
  • When is the deadline on having it gone
  • How will you support it till then
  • How will you ensure security for as long as you still have it

Add to it:

  • How will you know when this status changes (vendor might go out of business, release new versions and silent forget the one you still have, stop supporting a version/variant, extend support, ...) ? With the risk of depending on external parties, these updates need to also be done by actively polling for this, passively waiting to be informed isn't going to be enough to prevent you from getting in trouble.

As evident, the BCP and security requirements should be enough to cause some pressure on companies and organizations that manage their IT properly, but that's not going to affect most home users or small businesses who have a motto of "don't fix if it isn't broken" and apply it liberally.

This doesn't mean I'm advocating to be always on the latest greatest version a vendor promotes. Far from it: I'm hesitant to recommend a feeding frenzy over new OSes -of any vendor or make-, but that doesn't mean we ought not to follow the vendors of our choice into upgrading before the vendor forgets all about their previous version.

So how can we convince those that their (unsupported) legacy systems are a bad deal for the rest of us, just as for themselves ?

Swa Frantzen -- Section 66


Published: 2009-11-03

Opachki, from (and to) Russia with love

Opachki is a pretty interesting link hijacking trojan that has been spreading quite a bit in last couple of weeks. I started analyzing it couple of days ago and noticed that in the mean time Joe Stewart of SecureWorks posted his analysis as well (available here).

There are some very interesting things about Opachki so let me start at the beginning. The Trojan is distributed with a dropper which, when infecting the system, drops a DLL file. Both the dropper and the DLL file are packed with a packer called "Mystic Compressor". Besides this, the trojan never actually decrypts all strings in memory but calls a function to decrypt only what it needs and immediately deletes the data after it is not needed. Finally, the packer destroys PE header data from memory to make dumping more difficult.

Besides dropping the DLL, the dropper also does one vary nasty action: it completely deletes the SafeBoot registry key by calling reg.exe, as shown below:

Opachki registry delete

This prevents the system from booting in Safe Mode – the attackers did this to make it more difficult to remove the trojan. This goes well with what I've been always saying – do not try to clean an infected machine, always reimage it.

As Opachki's main goal is to hijack links, it hooks the send and recv API calls in the following programs: FIREFOX.EXE, IEXPLORE.EXE, OPERA.EXE and QIP.EXE. While the first three are well known, I had to investigate the last one. It turned out that QIP.EXE is an ICQ client that is very popular in Russia, so the trojan has a component that directly attacks Russian users.

The trojan will monitor web traffic (requests and responses) that above mentioned applications make and will inject a malicious script tag into every response. The injected script tag can be actually seen in the browser (by selecting the view source option) and can be seen in the image below:

Opachki script insertion

This will cause the browser to go to the shown site (google-analystisks.us), which is still live at the time of writing this diary. The site serves back a JavaScript file which modifies all links in the currently shown web page so they are redirected to a third site (http://thefeedwater.com/?do=rphp&sub=241&b= when I posted the diary). The PHP script at the google-analystisk.us web site is interesting as well – if you try to retrieve it directly you'll get an error back so you have to supply a referrer field. It also checks if you came from a search engine (i.e. Google) and returns back a different JavaScript file so it steals search queries as well.

Finally, Opachki performs another interesting action: it tries to see if the system is already infected with ZEUS and will remove ZEUS' files (rename them to C:ntldrs). It will check for all four ZEUS versions by verifying presence of the following files: C:WINDOWSsystem32ntos.exe, C:WINDOWSsystem32oembios.exe, C:WINDOWSsystem32twext.exe and C:WINDOWSsystem32sdra64.exe. I don't know why they do this, it could be that they are hijacking ZEUS or simply competing for same machines or using same attack vectors as the ZEUS crew.

The whole story about Opachki shows how that the bad guys are prepared to invest a lot of effort into building malware. Removing such a trojan is not simple and I would recommend reimaging the machine as the trojan puts a lot of effort into making removing difficult. As the Trojan is specifically attacking Russian users (among the others), it is probably safe to assume that it originates from Russia as well.

Finally, this shows that the bad guys are (probably) making good money by just hijacking links/clicking.





Published: 2009-11-03

SURBL now posting abuse statistics for TLD's

Well it looks like the busy guys over at surbl have created an interesting new feature.  They are now publishing spam domain totals based on most abused TLD's. This of course is rather interesting given the current state of the Registry world, and some of ICANN's ideas on new TLD's.  There is really very little surprise on the results of which domains are in the top 10, hopefully this sort of data will continue to spur the registry industry to look at implementing procedures to deal with abuse in their TLD's.  It should be noted that these figures are not tracking the volume of spam, but merely the number of domains that are seen in spam messages.

 Link to page:   http://www.surbl.org/tld-subtotals.head 

A quick quote from their website about this new feature. 

11/2/2009: SURBL has added a report of Most Abused TLDs. This is a daily count of the TLDs most commonly appearing in SURBL data and is an indication of relative abuse levels. The TLD .cn is disproportionately represented, most likely due to persistent and widespread abuse by the "Canadian Pharmacy" botnet-using spam gang.

Snapshot results as of Tuesday Nov 3rd 1:13 GMT:

237926	com
72591	cn
34818	net
18994	info
6986	us
3342	org
3329	ru
2966	at
1534	eu
1501	es
1265	biz
995	uk
941	in
687	sg
545	pl
432	de
237	im
216	hk
192	cd
175	cc



Published: 2009-11-02

Microsoft releases v1.02 of Enhanced Mitigation Evaluation Toolkit (EMET)

EMET has a bunch of neat features to help harden bad code (usually old bad code).  These include:

Structured Exception Handler Overwrite Protection
An SEH overwrite attack generally succeeds by overwriting a function pointer, as opposed to a buffer overflow attack which attempts to overwite a return pointer.

Heap Protection
This offers some protection from "heap spraying" attacks.  It's a good start, but the EMET docs admit that it's not a complete solution

Null Page allocation protection

So far this is a theoretical vulnerability in Windows, but a function pointer to virtual address 0 will execute in user space, and could possibly be made to execute with kernel priviledges.  This issue has been seen in Linux and FreeBSD, but nothing (yet) in the wild to exploit this approach for Windows.  If anyone has seen this attack succeed on Windows, we'd be happy to hear about it !

Dynamic DEP (Data Execution Protection)
DEP is a feature that's caused some consternation in the developer community over the last while.  Some less savvy developers see that it causes a problem with their code, and simply deactivate it for their entire application at compile-time.  DDEP allows DEP to be enabled at an individual process level

This is not a substitute for having good code in the first place, but if you're stuck with a 10 year old business app from a vendor that's killed the product or gone under, it's better than nothing.

As a final note, given what these tools do, Microsoft of course warns that any of these features can cause problems for applications that you apply them to.  Thorough testing is certainly in order before using this toolkit.

Full details, and the download, are here ==> http://blogs.technet.com/srd/archive/2009/10/27/announcing-the-release-of-the-enhanced-mitigation-evaluation-toolkit.aspx

If anyone has any good / bad experiences with this toolkit, please drop us a comment !

The developers would like to stress that this tool set may break applications. ALWAYS TEST BEFORE DEPLOYING! - Andre L


Published: 2009-11-02

Password rules: Change them every 25 years

While there certainly are parts of the password rules - like length, complex syntax, special characters, etc - that indeed may contribute to improving password security, the often stated requirement to change passwords every 90 days has far less obvious benefits.

There are four basic ways for a bad guy to get your password:
(a) Ask for it. So-called "Phishing" and "Social Engineering" attacks still work, and always will
(b) Try dictionary words at the login prompt in the hope to get lucky ("Brute Force")
(c) Obtain the encryped/hashed password somehow, and crack it
(d) Leech the password off your computer with keylogger malware

None of these four scenarios becomes less likely if you change your password every 90 days. If the bad guy can't break the password hash (c) within a couple days, he'll likely just look for an easier target. Attack (b) is also out for quick wins - either it works within the first couple dozen passwords tried, or the bad guy moves on to easier prey. If (b) or (c) are successful, or the attacker already has the password through (a) or (d), 45 days on average is more than enough to empty out your bank account or use your email address for a big spam run.

The concept of password expiry remained the same for the last 25 years or so. Infosec professionals, auditors, PCI, ISO27002, COBIT, etc all keep requiring it, unchanged, even though the threats have changed quite a bit. Forcing a user who had a weak password to change it will just make him pick another weak one. Forcing a user who had a very strong password to change it will eventually annoy the user into using simpler passwords.

So what gives? There is one practical benefit. If someone has your password, and all they want is to read your email and remain undetected, they can do so forever, unless you eventually change your sign-in secret. Thus, regularly changing the password doesn't help much against someone breaking in and making it off with your goods, but it DOES give you a chance to shake off any stalkers or snoopers you might have accessing your account. Yes, this is good. But whether this benefit alone is worth the hassle and mentioned disadvantages of forcing users to change their password every 90 days, I have my doubts.

Infosec risk management is about identifying threats and vulnerabilities, and then picking a countermeasure. But if the chosen countermeasure doesn't in fact make the identified threats less likely, all we do is play security theater, and the countermeasure is one that we don't need.

Unless, of course, "best practice standards" and audits force us to have it.



Published: 2009-11-02


Two days ago, the ICANN authorized the introduction of country code top level domains (ccTLDs) using character sets other than the latin a-z alphabet. This is no earth shattering change - we had Internationalized Domain Names (IDNs) using greek, cyrillic, chinese, etc character sets for several years. The only change is that now also the top level domain (the rightmost portion of a domain name) can be written in characters other than A-Z.

From a security point of view, things might still get "interesting". Back when the IDNs were originally introduced, look-alike domain names and even SSL connections could be credibly faked. Some web servers, firewalls and IDS products also had huge gaping holes as a result of applying their security checks only in ASCII-Land, and ignoring Unicode completely. The past ten years of experience with IDNs have brought the problem reasonably under control, and expanding the IDNs to include top level domains shouldn't be a big deal. But since we all know how software gets "fixed", chances are still that history will repeat itself, and we will soon read of a web server that readily divulges application source code when hit with a TLD in cyrillic...


Published: 2009-11-01

Cyber Security Awareness Month 2009 - Summary and Links

As requested by many readers, below are links to all 31 of the diaries that we wrote for Cyber Security Awareness Month 2009.  In 2007 we covered a large range of subjects based on what our readers submitted as ideas.  In 2008 we took a closer look at the six steps of incident handling.  This year we examined 31 different ports/services/protocols/applications and discussed some of the major security issues.  Many readers submitted comments, tips, and tricks for securing them.  If you have additional comments on any of these diaries feel free to add them directly to the bottom of the diary (you have to log in first) or if you want to remain anonymous you can send them to us via our contact form.

1 - Port 445 - SMB over tcp
2 - Port 0
3 - Port 5900 - VNC
4 - Port 20/21 - FTP-data/FTP
5 - Port 31337 - trojan horses
6 - Ports 67&68 udp - bootp and dhcp
7 - Port 6667/8/9/7000 - IRC
8 - Port 25 - SMTP
9 - Port 3389 -RDP
10 - The Questionable Ports
11 - Port 111 - RPCBind aka Portmapper
12 - Ports 161/162 - Simple Network Management Protocol (SNMP)
13 - Ports 3128, 8080 & .... - Proxies
14 - Port 514 - syslog
15 - Ports 995, 465, and 993 - Secure Email
16 - Port 1521 - Oracle TNS Listener
17 - Port 22 - SSH
18 - Port 23 - Telnet
19 - ICMP
20 - Ports 5060 & 5061 - SIP (VoIP)
21 - Port 135 - MS DCE locator
22 - Port 502 - Modbus
23 - Port 179 - Border Gateway Protocol
24 - Ports 1-20 and 37 - The Small Services
25 - Port 80 and 443 - Web services
26 - Ports 1433/1434 - MS SQL
27 - Ports 135, 137, 138, 139, ... - MS Active Directory Ports
28 - Port 123 - ntp
29 - Port 53 - dns
30 - Ports 47, 50, 500, 1723, 4500, ... - The "Common" IPSEC VPN Protocols
31 - Port 113 - ident

Marcus H. Sachs
Director, SANS Internet Storm Center