- You've Been Hacked!
- Netbus Scan
- How Slow Can you Go?
- RingZero Worm
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
RingZero Worm
Let's wrap up our foray into real-world analysis by examining the RingZero Worm. This worm would probably be considered ancient in Internet time because it was discovered in the latter part of 1999. Plenty has transpired concerning malicious code since that time, yet some of the concepts that can be learned from examination of the worm activity are timeless. This presents a good transition into the next and final chapter of this section that delves more deeply into forensics.
The first indication that the monitored site had some new and unusual activity was that Shadow reported many different attempts to connect to TCP port 3128, the squid web proxy server. These attempted connections occurred many times an hour and were from source hosts from all over the world. Although it has become rather commonplace today with malicious code such as Code Red and nimda to see many different source IPs scanning many different destination IPs, in late 1999, it was a rarity. Here is an excerpt of the kind of activity seen for one hour at the monitored site:
12:29:48.230000 4.3.2.1.1049 > 172.16.54.171.3128: S 9779697:9779697(0) win 8192
<mss 1460> (DF) 12:29:58.070000 4.3.2.1.1049 > 172.16.54.171.3128: S 9779697:9779697(0) win 8192
<mss 1460> (DF) 12:30:10.960000 4.3.2.1.1049 > 172.16.54.171.3128: S 9779697:9779697(0) win 8192
<mss 1460> (DF) 12:44:54.960000 1.2.3.4.3243 > 172.16.187.212.3128: S 356330349:356330349(0) win 8192
<mss 1460> (DF) 12:44:57.930000 1.2.3.4.3243 > 172.16.187.212.3128: S 356330349:356330349(0) win 8192
<mss 1460> (DF) 12:45:03.930000 1.2.3.4.3243 > 172.16.187.212.3128: S 356330349:356330349(0) win 8192
<mss 1460> (DF) 12:45:15.930000 1.2.3.4.3243 > 172.16.187.212.3128: S 356330349:356330349(0) win 8192
<mss 1460> (DF) 12:46:13.070000 1.1.1.1.2262 > 172.16.99.110.3128: S 20315949:20315949(0) win 8192
<mss 1460,nop,nop,sackOK> (DF) 12:46:16.080000 1.1.1.1.2262 > 172.16.99.110.3128: S 20315949:20315949(0) win 8192
<mss 1460,nop,nop,sackOK> (DF) 12:46:22.070000 1.1.1.1.2262 > 172.16.99.110.3128: S 20315949:20315949(0) win 8192
<mss 1460,nop,nop,sackOK> (DF)
Three different source IPs—4.3.2.1, 1.2.3.4, and 1.1.1.1—are attempting connections to three different internal destination IP addresses. Because many of the scanned destination IPs in our network were not active, there appeared to be no prior reconnaissance that would target live hosts only. Each source host retries (source ports and TCP sequence numbers do not change) the connection several times because the destination hosts do not respond, and no ICMP error message is returned to indicate that the destination hosts are unreachable. Looking at the timestamps, you can see that these connection attempts occurred at different times during the 12:00 hour.
Our site was not the only one that witnessed this activity; the Naval Surface Warfare Center was also seeing these scans as well as ones to destination port 80 and 8080. Other sites witnessed this activity, and soon, it became apparent that this activity was very widespread.
The initial assessment of the activity was someone attempting to find open web proxy servers. Open proxy servers sometimes offer a "tunnel" through which a hacker can gain access and assume the source IP of the proxy to hide his tracks. At this point, because the traffic was coming from all over the world, one theory was that the source IPs had been spoofed and it was just a handful of hosts involved. Again, this attack pre-dates the notion of distributed denial of service (DDoS) attacks, so we were unaccustomed to dealing with many source hosts to many destination host attacks.
The verbose option (-vv) of TCPdump might provide some assistance in determining whether or not the source IPs were spoofed. The same TCPdump records are examined again, but this time using the verbose option:
12:29:48.230000 4.3.2.1.1049 > 172.16.54.171.3128: S 9779697:9779697(0) win 8192
<mss 1460> (DF) (ttl 19, id 9072) 12:29:58.070000 4.3.2.1.1049 > 172.16.54.171.3128: S 9779697:9779697(0) win 8192
<mss 1460> (DF) (ttl 19, id 29552) 12:30:10.960000 4.3.2.1.1049 > 172.16.54.171.3128: S 9779697:9779697(0) win 8192
<mss 1460> (DF) (ttl 19, id 39792) 12:44:54.960000 1.2.3.4.3243 > 172.16.187.212.3128: S 356330349:356330349(0) win 8192
<mss 1460> (DF) (ttl 19, id 962) 12:44:57.930000 1.2.3.4.3243 > 172.16.187.212.3128: S 356330349:356330349(0) win 8192
<mss 1460> (DF) (ttl 19, id 11714) 12:45:03.930000 1.2.3.4.3243 > 172.16.187.212.3128: S 356330349:356330349(0) win 8192
<mss 1460> (DF) (ttl 19, id 22466) 12:45:15.930000 1.2.3.4.3243 > 172.16.187.212.3128: S 356330349:356330349(0) win 8192
<mss 1460> (DF) (ttl 19, id 33218) 12:46:13.070000 1.1.1.1.2262 > 172.16.99.110.3128: S 20315949:20315949(0) win 8192
<mss 1460,nop,nop,sackOK> (DF) (ttl 116, id 35676) 12:46:16.080000 1.1.1.1.2262 > 172.16.99.110.3128: S 20315949:20315949(0) win 8192
<mss 1460,nop,nop,sackOK> (DF) (ttl 116, id 46428) 12:46:22.070000 1.1.1.1.2262 > 172.16.99.110.3128: S 20315949:20315949(0) win 8192
<mss 1460,nop,nop,sackOK> (DF) (ttl 116, id 57180) 12:46:34.080000 1.1.1.1.2262 > 172.16.99.110.3128: S 20315949:20315949(0) win 8192
<mss 1460,nop,nop,sackOK> (DF) (ttl 116, id 2397)
Let's scrutinize these records, but this time in terms of source IP spoofing. The salient advice to remember when looking for spoofed source IPs is to look for similarities in the fields or characteristics of packets. More likely than not, an attacker will not take time to "craft" in differences in the packets, and there will be some traces of unlikely similarities. Conversely, when distinct source IPs truly represent different source hosts, differences in packet characteristics should be apparent. Given this knowledge, what differences can you find among the three different source IPs of the previously shown traffic?
For starters, you pretty much have to do fourth-down-and-punt with the IP identification numbers. The time gaps between when each set of initial connections received is too great to see real trends in IP identification numbers. Ten minutes pass between the first and second set of connections, which is enough time for the IP identification numbers of a busy host to go through all 65,535 numbers and wrap. You would ordinarily look for a chronology of very close IP identification numbers, which would indicate source IP spoofing. But, this can only be done if the time changes are insignificant.
What about the arriving TTL values? They look promising for spoofing because both the first two sets of connections involving source IPs of 1.2.3.4 and 4.3.2.1 have an arriving TTL value of 19. However, the third set from 1.1.1.1 has an arriving TTL value of 116.
Are there any other differences? Look at the TCP options for the connections. The first two source IPs share the same TCP options, a maximum segment size (mss) of 1460. Yet, the third source IP also has a selective acknowledgement (sackOK) that must be padded with two noop's to fall on a 4-byte boundary.
Finally, look at the number of retries per attempted connection and the backoff time between initial tries and retries and between subsequent retries. The first source IP 4.3.2.1 has an initial try and two retries. The backoff time between retries is approximately 10 seconds. Next, IP 1.2.3.4 has one initial try and three retries with the retry attempts doubling in the amount of time before subsequent ones. Finally, the source IP 1.1.1.1 behaves much like 1.2.3.4 as far as retries in that it has three retries with a doubling of the backoff time. From all the forensics from the preceding dump, we can pretty much conclude that these are actual separate source IPs.
When the traffic was observed, we took the TTL values, estimated the initial TTL values, and subtracted the arriving from the initial values. This gave us the number of hop counts that the datagram took to arrive on the sensor network. Then, we executed a traceroute back to the source IP to see if the expected hop count was close to the actual hop count.
About a dozen traceroutes were attempted; most had a hop count credibly close to the actual hop count. Also, all the targeted IPs were alive, which might not be the case had random IPs been chosen for spoofing. It would be rare if someone were doing mass amounts of spoofing using hand picked live IP numbers only. Usually, it is a far more random selection of spoofed source IP numbers.
This kind of widespread scan was difficult to explain examining one site. Before the days of http://www.incidents.org, Stephen Northcutt asked SANS members to look at traffic at their individual sites and see if they could provide any explanations about the activity. Hundreds of sites reported similar activity.
A couple of sites were able to see the HTTP request that was executed, and it appeared to implicate a host http://www.rusftpsearch.net. The site was available for a few days and it appeared to be collecting IPs of any open proxy servers found.
Ron Marcum of Vanderbilt University discovered a PC on his network that was scanning hosts on other networks looking for ports 80, 8080, and 3128. He discovered a Trojan called RingZero that appeared to be the culprit. At a SANS conference in 1999, conference members and instructors installed the program that was discovered on the Vanderbilt host and examined what it did. They were able to recreate that this Trojan would scan other hosts on web ports.
The suspected infection means is via email or mp3 sharing. But, this seminal malicious code is one of the first that infected hosts and gathered some valuable information from the hosts, and then used the infected hosts to scan other hosts. This is the same model used for scans and attacks today, albeit quite a bit more sophisticated.