Dissecting Worms

---

Throughout the past few years we have seen not only an increase in worm activity, but also an increase in the severity of worm attacks on systems and networks. Internet worms are becoming faster, smarter, and stealthier. Most worms attack vulnerabilities in software for which patches have been readily available for quite some time before the exploit appeared. Complex worms are beginning to emerge that have the ability to exploit several vulnerabilities and propagate in a number of different ways. This makes reverse engineering and defending against the worm more difficult. This section will explore three well-known worms: SQL Slammer, Code Red, and Ramen.

SQL Slammer Worm

The SQL Slammer worm began propagating on the Internet on January 25, 2003. It exploits a vulnerability in the Resolution Service of Microsoft SQL Server 2000 and Microsoft Desktop Engine (MSDE) 2000. It is also known as the W32.Slammer worm, Sapphire worm, and W32.SQLExp.Worm. It is known as the fastest spreading worm, and infected most vulnerable systems within 10 minutes. As the worm propagated and compromised more systems, the Internet showed significant signs of degradation.

The SQL Slammer worm exploits a stack buffer overflow vulnerability that allows for the execution of arbitrary code. Once a system is compromised, the worm will attempt to propagate itself by sending 376-byte packets to randomly chosen IP addresses on UDP port 1434. All vulnerable systems that are discovered will become infected and also begin to scan for more vulnerable systems. With this type of exponential growth, no wonder it spread so fast! This type of propagation leads to a lot of other problems including performance issues, crashed systems, and denial of service. Details on the SQL Slammer worm including the patch, instructions on applying ingress and egress filtering, and recovery from a compromised system can be found in the CERT Advisory at www.cert.org/advisories/CA-2003-04.html.

The Scan3.log file, provided by the Honeynet Research Alliance as part of the Honeynet Project Scan of the Month challenge, shows evidence of the SQL Slammer worm attempting propagation. Scan3.log is located on the accompanying CD-ROM in the /captures directory. After you open the packet capture in Ethereal, apply the UDP filter with destination port 1434, and you will see the Slammer scan traffic, as shown in Figure 8.12. You will notice that there are 55 packets from random source addresses that are sending a UDP packet to port 1434. The UDP packet also has a length of 384 bytes, which is the 376 bytes of data plus the 8-byte header. All of the packets are incoming to the target 172.16.134.191, and none are going out, which lets us know the system is not compromised; it is just the target of the randomly generated IP addresses on other compromised systems. You will also notice that each of the packets contains data, and although it is a bit scrambled you can make out the various parts of the exploit code such as: ws2_32.dll, kerne32.dll, GetTickCount, socket, and send to.

Figure 8.12: SQL Slammer Propagation Attempt

Code Red Worm

The Code Red worm was originally discovered on July 16, 2001, and since then there have been many variants including Code Red II and III. The worm infects Microsoft Windows NT, 2000, and beta versions of XP that are running IIS 4.0 and 5.0 Web servers. Code Red exploits a known buffer overflow vulnerability in the IIS Indexing services IDQ.DLL file. Details on the Code Red worm including the patches, workarounds, and recovery from a compromised system can be found in the CERT Advisory at www.cert.org/advisories/_CA-2001-19.html.

Notes from the Underground…
Why did Slammer spread so fast?

SQL Slammer has been the fastest spreading worm to date. A detailed analysis of the spread of the SQL Slammer worm can be found at www.caida.org/analysis/security/sapphire. There are several key attributes of the worm that allowed it to spread at such an alarming rate. These are outlined as follows:

• Random scanning The random scanning of the worm allowed for initial exponential growth.

• Simple and fast scanner The worm could scan as fast as the compromised computer could transmit packets or the network could deliver them.

• Small size The SQL Slammer worm was only 376 bytes.

• UDP The use of a single UDP packet allowed for efficient propagation because the connection does not have to wait for a response.

  The propagation of the Slammer worm caused worldwide disruption in approximately 10 minutes. Fast-spreading Internet worms are a significant milestone in computer security, and a reality that should be met with all available countermeasures.

The Code Red worm operates in 3 stages, which are time sensitive: propagation, denial of service, and sleep. Although there are many variations, the general pattern of behavior is as follows:

• Propagation mode This stage takes place from the 1st to the 19th of the month. An infected system will randomly generate IP addresses and attempt to connect to them on HyperText Transfer Protocol (HTTP) port 80. If a system is discovered and is vulnerable, the exploit code will be sent via an HTTP GET request and the web page of the server will be defaced. The original worm defaced web pages by displaying “Welcome to www.worm.com! Hacked By Chinese!” However, some new variations will not deface the web page. The worm places a file, C:\notworm, on the system to signal that it has been infected. This way, if the system gets infected again, the worm will go into an infinite sleep state. If the c:\notworm file does not exist, then this is the first time this system has been infected, and it will create new threads to continue the propagation scanning. This propagation activity will continue until the 20th of the month.

• Denial of Service mode This stage begins on the 20th and lasts until the 27th. In this stage, the worm will attempt to packet-flood a specific IP address that is designated in the code by sending large amounts of data to HTTP port 80 of the target. The first target was originally the Whitehouse website at 198.137.240.91. By directing the flood to the IP address instead of the DNS host name, it was easy for Whitehouse.gov system administrators to change the IP, thus making the flood ineffective.

• Sleep This stage causes the worm to enter a sleep state from the 28th until the end of the month. It will remain in memory, but will not be active, until the cycle repeats on the 1st

The CodeRed_Stage1 capture, Figure 8.13, shows the Code Red exploit and propagation in action. The CodeRed_Stage1 file is located on the accompanying CD-ROM in the /captures directory. The Code Red capture files were provided by L. Christopher Paul and can also be downloaded from www.bofh.sh/_CodeRed. This capture was lab-generated to show the various Code Red stages, so timestamps may not reflect the proper dates for the various stages. The worm spreads from the system 192.168.1.1 and infects the vulnerable target 192.168.1.105. The newly compromised system then begins scanning random IP addresses for open HTTP port 80. A definite giveaway in this capture is packet number 4, “GET /default.ida?NNNNNNNNN…”, which is the exploit for Code Red. The random HTTP port 80 scanning that begins at packet number 12 should also alert you to something strange. This isn’t typical web surfing because none of the targets are responding.

Figure 8.13: Code Red Stage 1 – Infection and Propagation

Figure 8.14 shows the “Follow TCP Stream” output of the initial exploit. Notice the exploit in the HTTP GET request at the beginning, and the checking of the of C:\notworm file, and web page defacement at the end.

Figure 8.14: Code Red Exploit Output

The CodeRed_Stage2 capture, Figure 8.15, shows the denial of service mode of the worm. The CodeRed_Stage2 capture file is located on the accompanying CD-ROM in the /captures directory. The infected server, 192.168.1.105 is attempting to flood the Whitehouse web server at 198.137.240.91. Since this was performed in a lab environment, the actual denial of service was not accomplished.

Figure 8.15: Code Red Stage 2 – Denial of Service

Ramen Worm

The Ramen worm is a collection of tools that can exploit several known vulnerabilities and can self-propagate. The original CERT Incident Note, posted on January 18, 2001, can be found at www.cert.org/incident_notes/IN-2001-01.html. Ramen targets Red Hat Linux 6.2 and Red Hat Linux 7.0 servers with vulnerable versions of the following:

• wu-ftpd This program runs on TCP port 21 and vulnerable versions contain a format string input validation error in the site_exec() function.

• rpc.statd This program runs on UDP port 111 and vulnerable versions contain format string input validation errors in the syslog() function.

• Lprng This program runs on TCP port 515 and vulnerable versions contain format string input validation errors in the syslog() function.

Once a host is compromised, the Ramen tools are copied into a directory called /usr/src/.poop. They are started and controlled by a series of shell scripts. Some of the important characteristics of the Ramen worm include the following:

• The webpage is defaced by replacing the index.html file. The new web page consists of the phrase “Hackers looooooooooooooooove noodles” and a picture of a package of Ramen noodles.

• E-mail is sent to [e-mail] and [e-mail] with the text “Eat Your Ramen!”.

• The tcpwrappers access control list (ACL) is disabled by removing the /etc/hosts.deny file.

• The file /usr/src/.poop/myip contains the IP address of the local system.

• The file /etc/rc.d/rc.sysinit is modified to include a startup script that initiates scanning and exploitation.

• A new program called asp is added, which creates a listener on TCP port 27374. This port is used to send the ramen.tgz toolkit file to other compromised systems. That is also the port that SubSeven uses. Coincidence? It is unclear why the author would want to use an already well-known port, since most IDSs should have been configured to alert activity on that port.

• The user names ftp and anonymous are added to /etc/ftpusers to disable anonymous FTP (File Transfer Protocol). By disabling anonymous FTP, this part of the worm code is actually fixing the vulnerability that it used to exploit the system!

• The rpd.statd and rpc.rstatd services are terminated and the /sbin/rpc.statd and /usr/sbin/rpc.statd files are deleted. However, there is no service called rpc.rstatd.

• The lpd service is terminated and the /usr/sbin/lpd system file is deleted.

Once the system has been modified, the Ramen worm begins scanning and exploiting the vulnerable systems that it finds. The worm generates random class B IP addresses to scan. It will then send packets with the SYN and FIN flags set and with a source and destination port of 21. Once a vulnerable system is compromised the following actions occur:

• The /usr/src/.poop directory is created on the victim.

• The ramen.tgz toolkit is copied to the new directory and to the /tmp directory. The /tmp directory is where the toolkit is stored so that it can be copied out to new vulnerable systems.

• The ramen.tgz toolkit is unarchived in the /usr/src/.poop directory and the initial shell script is started. The system is now fully compromised and will begin scanning for new vulnerable systems.

The ramenattack.gz packet capture was downloaded from www.whitehats.com/library/worms/ramen. Here you will find a very detailed analysis of the Ramen worm by Max Vision, called “Ramen Internet Worm Analysis” as well as the ramen.tgz source code. The ramen attack.gz capture file is also located on the accompanying CD-ROM in the /captures directory. Ethereal will automatically uncompress the file when you open it.

We will step through the various parts of the packet capture to show how the Ramen worm works.

1. In Figure 8.16, the infected system 192.168.0.23 is performing a SYN/FIN scan on the 10.0.0.0/24 Class B network. It receives a SYN/ACK from the target system at 10.0.0.23.

   
   Figure 8.16: Ramen Work Propagation Scanning

2. Next, in packet 26, the worm connects to the system to grab the FTP banner and determine if the system is a Red Hat 6.2 or 7.0 server. The banner that the Red Hat 6.2 server returns is as follows:

   220 test2.whitehats.com FTP server (Version wu-2.6.0(1) Mon Feb 28 10:30:36 EST 2000) ready. 221 You could at least say goodbye.

3. Next, the wu-ftp and rpc.statd exploits are launched against the potential target. The wu-ftp attempt begins at packet 137 and is unsuccessful, but the rpc.statd exploit succeeds. Figure 8.17 shows the payload of the rpc.statd exploit. Notice the padding of “90 90 90 90…” and the trailing “/bin/sh” that will execute a command shell. You will also notice in packet 289 that once the SYN/FIN scan is finished scanning the target 10.0.0.0/24 range it sends a SYN/FIN packet to 10.9.9.9 from port 31337. This represents the packet that is sent to www.microsoft.de when the scan is complete. Since the worm was activated and analyzed in a lab environment 10.9.9.9 was chosen to represent www.microsoft.de.

   
   Figure 8.17: Ramen Worm rpc.statd Exploit

4. You will also notice in packet 290 that a connection is made with the port 39168 on the target system. The rpc.statd exploit created a backdoor on the victim on this port and it is now used to initiate the transfer of the worm and execute it. It also sends an e-mail to accounts at Hotmail and Yahoo. The output from this transfer is shown in Figure 8.18.

   
   Figure 8.18: Ramen Worm Execution

5. The last connection you will see, beginning in packet 297 in Figure 8.17, is the actual transfer of the Ramen toolkit that was initiated in previous script. The new compromised system connects back to the attacker at port 27374 to download a copy of the worm.

6. The worm is now executing on the victim and will begin scanning for new vulnerable hosts.

Overall, the Ramen worm is easy to detect, especially since it uses a well-known Trojan port for the worm transfer. It contains unexplained and inefficient code and makes no attempt to be stealthy. There are also several places where its functionality could be optimized. However, this is a worm that exploits several different vulnerabilities and self-propagates. The security community should definitely watch out for more worms with these capabilities.

Note 

A day-zero, or alternately a zero-day attack, is an exploit on a vulnerability that is not yet known about and for which there is no patch.

---