-----------------------------------
Scan of the month #21
Curtis Sloan
[CSloan@MASTERS.ab.ca]
-----------------------------------
The Challenge:
On the evening of Feb 15th, three
different members of the Honeynet Research Alliance
received a flurry of strange UDP packets, that at first look seemed to have no
apparent purpose. This month's Scan of the Month challenge is to understand the
purpose of these packets. Using the Snort binary capture of one of the Honeynets, answer the following questions. The Honeynet that is scanned is on the 172.16.1.0/24 network.
Also, keep in mind these packets were recorded on a system in the GMT timezone. When reviewing this binary capture on your
system, it may convert the times of the packet captures to the local timezone of your system.
Questions:
Bonus Question:
Methodology:
Procedures and Methodology behind the analysis
1) The attacker is attempting to determine if there are any hosts on the network which have been infected with the Remote Shell Trojan RST.b virus/Trojan.
In order for the scan to be successful, any infected hosts must also meet the criteria of not being protected by a dynamic, packet-filtering firewall which is prohibiting uninitiated inbound UDP traffic on any given port (or ports). The reason behind this criteria lies in the way the Trojan functions. See http://www.qualys.com/alert/QSA-2002-01-01.pdf for details.
In the event that the attacker does discover an infected host, the attacker will also have discovered that the firewall that is protecting the infected host is not effectively filtering uninitiated inbound UDP traffic to the infected host on the port (or ports) used to initiate the scan.
2) The attacker may be trying to take advantage of the Trojan backdoor process that may be running on an infected host in order to execute arbitrary commands (using /bin/sh -c) in the security context of the user who executed the virus/Trojan.
This activity is contingent not only on discovering an infected host, but also on being able to receive UDP packets on port 4369 in reply (i.e. no egress packet filtering on UDP port 4369).
3) In addition, the hacker may also be attempting to fingerprint the OS of the victim systems. See Question 6 for more details on how the attacker can accomplish this.
The backdoor process is programmed to look for uninitiated incoming UDP on any port (the Trojan accomplishes this functionality by putting any available adapters (i.e. eth0, ppp0) into promiscuous mode).
Also, the backdoor is specifically coded to activate upon receipt of a specially crafted "DOM" UDP packet.
The Trojan looks for any inbound UDP, so using random source ports, destination ports, and IP addresses increases the chance of evading any intrusion detection systems.
I believe that this approach would safely
avoid any current Snort rulesets (
The packets are originating from the same machine.
The attacker used a few "random" IP addresses, but they all came from the same small block of network addresses (213.68.213.130 - 213.68.213.144). The use of IP addresses in this way, when viewed in light of the sequential order and rapid succession of the UDP packets, suggests that the IP addresses were being spoofed from a single machine. If typical hacking "best practices" were used in the UDP scan, the machine creating the spoofed packets was probably a compromised host on an entirely different network.
The packets arrived in relatively rapid succession compared to the majority of rest scanning activity in the log (mean time of 0.010614875 seconds or 1/100 of a second apart). The feasibility of using multiple machines to create the UDP scan while being routed over a packet-switching network (i.e. the Internet) and having the packets still come out in succession within the given timeframe would be virtually impossible.
By looking for a response UDP packet containing the three-byte ASCII string "DOM" sent to port 0x1111 (4369) of the attacker’s sending IP address.
Yes.
1) Since the Remote Shell Trojan RST.b virus infects ELF binaries, there is a high-percentage likelihood that the successful discovery of an infected host by the attacker would indicate that the infected host is running Linux.
2) When UDP packets reach a closed port, the destination host will respond with an ICMP Host Unreachable message. The attacker can monitor the attacking (source) host for incoming ICMP Host Unreachable ICMP packets.
a) Sun Solaris boxes will respond with a 64 byte ICMP Host Unreachable message.
b) Linux will respond with an ICMP Host Unreachable message of up to 576 bytes.
c) Other Unix flavours will respond with an 8 byte ICMP Host Unreachable message.
d) Foundry Network devices will respond with an ICMP Host Unreachable message of 8 + 12 bytes.
See http://www.intranode.com/pdf/techno/article_2001_06_1.pdf for a presentation on OS fingerprinting, from which these facts were garnered.
In addition:
3) There are hosts running an FTP service (.102, .105, and .108) which respond with SunOS 5.8.
4) On the IRC server there is a Solaris room (.102).
Summary: It appears as though at least some of the victim systems are running SunOS 5.8 (Solaris 8).
Foreword:
Scan 21 provided the perfect opportunity for me to send my first submission to the Scan of the Month Challenge at Project.Honeynet.org since my knowledge of security has only very recently grown to the point where I felt I could tackle this Challenge. I decided to analyze the Scan mostly for the fun of it, but with an expectation of learning more about security and blackhat activities.
Procedure:
My procedure was necessarily somewhat architectural, since I had to build some of the knowledge framework in which to analyze the scan. I began first by taking my existing knowledge of packet capture analysis and methodically building a hypothetical concept of the activities represented in the log. All analysis was done under Windows 2000 using cross-platform utilities (i.e. Ethereal, nmapNT).
1) I downloaded the file 0215@000-snort.log.tar.gz and used md5sum to verify the integrity of the archive.
2) I opened the Snort log in Ethereal v0.9.4 (installed under Windows 2000 using Winpcap v2.3).
3) I scrolled randomly throughout the log to begin familiarizing myself with the contents of the log. Unfortunately, I did not notice the 9 UDP packets at the bottom of the log during this time. So, after a mild perusal of everything, I used Ethereal => Tools => Summary to try to garner an overview of the activity.
a) The log activity took place during a 24-hour period.
b) There were only 3389 packets captured during this time. The frequency equates to a mean rate of ~140 packets / hour or ~2 packets / minute. The level of activity is, at most, moderate during its peaks, and mostly nominal.
4) I performed a trend analysis of the activity in the log by examining the packets in sequential order.
a) I changed the display to "Time of Day" so as to bear in mind the time of day that the activity took place, both in relation to the honeynet's time zone, and also in relation to any compromised hosts being used.
b) After analyzing about half of the log, it became apparent that there was a baseline of activity being punctuated by quick bursts of scan-like activity (e.g. HTTP, FTP, NetBIOS, and RPC scanning activity). These bursts of scanning became very predictable. I postulate that the scanning must be scripted or automated in some fashion.
Note: Much to my chagrin, it wasn't until I reached the very end of the log via sequential examination and trend analysis that I actually found the 9 UDP packets in question. I quit for the night because I was overwhelmed by the grief of having "wasted" so much time. Frankly, I just needed a break. However, I was grateful to have inspected the rest of the activities represented in the log. It was an excellent learning experience.
5) I began examining the UDP packets closer. The following details were apparent to me:
a) The UDP packets were not directed at any specific service or port (such as the earlier NBNS or SunRPC UDP packets were).
b) The packet data was only 5 bytes and the bulk of the payload consisted of the letters DOM. DOM struck me as being suspect, or at least unusual, since it is often used in networking as a short form of DOMAIN. Whether or not this is the intended meaning of the data, it at least drew my attention, and proved to be an integral part of the analysis.
6) I began looking for outside information.
a) I used Google.com to search for "UDP DOM". The first link I got back was to Qualys.com, where I was prompted to register to download a repair tool. Nothing else matched the query context I was looking for.
b) I went back to Google.com and refined my search a little by providing the terms "UDP packet data DOM". This brought back two more Qualys.com links, one of which went to the previous registration page. However, the second, a deeper link, led to a descriptive PDF document which was the breakthrough in my analysis. http://www.qualys.com/alert/QSA-2002-01-01.pdf
7) I began formulating the basic answers to the questions posed using the new information at hand, courtesy of Qualys.com.
Note: Research into various other activity in the log (e.g. IRC activity; HTTP, FTP, NetBIOS, and RPC scanning activity; etc.) was moderately useful but revealed little toward understanding the UDP packets themselves directly. However, it did provide context, as well as being a stepping-stone toward new learning regarding security and blackhat activities.
8) I correlated the information from Qualys.com using supplementary information and resources, in order to confirm the validity of the Qualys.com report and to explore the possibility of more than one single topical answer to the questions.
I explored 5 different sources: SecurityFocus.com, current CVE listings, search engine results for RST.b, popular antivirus sites, and Snort.org.
a) A search for RST.b at SecurityFocus.com turned up the initial analysis of RST.b done prior to Qualys.com's report. According to Qualys.com's report, however, the earlier posting on SecurityFocus.com had inaccuracies in the analysis as well as lack of detection and cleaning capabilities. The link at SecurityFocus.com below is dated December 28, 2001.
Here is a quote from the analysis which aptly sums up my experience during step 7): "... but then it dawned on me that this might be here so they can scan the net for infected hosts. Not only do we have a virus spreading it is opening up the infected boxes to attackers." Hence, the answer to Question 1. <http://online.securityfocus.com/archive/100/247640>
b) The CVE information proved less than informative. Reference CAN-1999-0660: http://cve.mitre.org/cve/candidates/downloads/full-can.html
c) Google.com did not provide any other relevant links to technical information regarding RST.b or RST. Most links were news articles, and most of those pointed to Qualys.com. I tried Metacrawler.com, AllTheWeb.com, and HotBot.com for variety, and all returned results that were even fewer and farther between, and of the same variety as those returned from Google.com.
d) SARC.com (Symantec Security Response) had no technical information or description of RST.b, TrendMicro.com only had a reference for RST, and McAfee.com had no information on RST.b or RST.
e) I checked the current Snort rulesets to see whether or not a signature for RST.b exists. I searched in the categories "backdoor", "virus", and "scan". As of 20-Jun-2002, I found nothing that looked obviously like an RST-type scan signature. However, my knowledge of Snort is rather limited at this point, so I am not ruling out the possibility that I may have missed something with regard to Snort detection of RST.b Trojan backdoor activity.
In short, I could not immediately find any evidence that Qualys.com's conclusions are confirmed by a single authoritative source, let alone multiple sources. However, the information appears to be accurate in that it lines up perfectly with this scan situation, and nothing else really did.
9) Write up analysis and submit.
P.S. Did anyone else get suckered into registering at Qualys.com in order to download the RST.b removal tool (in hopes of analyzing it), only to be redirected to a File not Found page? And then, to add insult to injury, get telephone sales spammed the very next day? :-P
Credits:
Ryan Russell (Ryan@SecurityFocus.com) for original post of Remote Shell Trojan RST.b analysis
lockdown for the original analysis of Remote Shell Trojan RST.b
Franck Veysset (Franck.Veysset@intranode.com) for OS fingerprinting presentation
Ryan@eEye.com for nmapNT
www.ethereal.com for Ethereal
www.qualys.com for a technical description of the Remote Shell Trojan RST.b
www.google.com for putting the world's information at my fingertips
www.insecure.org for nmap
Kimberley Sloan for proof reading and analysis sounding board
Jacelyn Campbell for proof reading analysis sounding board