Project Honeynet SoTM 21: June 2002 Dave Turner dcturner2000@yahoo.co.uk -------------------------------------------------------------------------------- Analysis 1. Download the Snort log, check its checksum and decompress it. $ wget http://project.honeynet.org/scans/scan21/0215@000-snort.log.tar.gz --20:26:35-- http://project.honeynet.org/scans/scan21/0215@000-snort.log.tar.gz => `0215%40000-snort.log.tar.gz' Resolving project.honeynet.org... done. Connecting to project.honeynet.org[63.107.222.112]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 81,060 [application/x-tar] 100%[====================================>] 81,060 109.79K/s ETA 00:00 20:26:36 (109.79 KB/s) - `0215%40000-snort.log.tar.gz' saved [81060/81060] $ md5sum 0215%40000-snort.log.tar.gz 58abd0cb0cbe4c31930225dd229352a5 0215%40000-snort.log.tar.gz $ tar zxf 0215%40000-snort.log.tar.gz $ 2. Load the log into ethereal and filter for UDP packets : "ip.proto eq 0x11" A series of 9 UDP packets at 23:50:15 UTC on 15/02/2002 arrive destined for 172.16.1.101-109. These are frames 3360-3368 at about 85743s after the start of the log. They appear to originate from certain hosts in the range 213.68.213.130-144. For the sake of brevity I will call the victim hosts v101-v109 and the attacking hosts h130-144. a133 appears twice, host a135 appears 3 times and each of a130, a134, a140 and a144 only send one packet each. The source and destination ports show no immediate pattern, although the packets arrive destined for each host in the honeynet in ascending order, as would be expected from a systematic scan. The entire sweep takes 0.085s and the packets for hosts v103-v109 takes 0.0047s. The TTL values for each packet vary widely. The shortest is 151, then two values of 155 (apparently from a144 to v104, followed by a135 for v106) then 158, 190, 192, 203, 226. IP header checksums are all present and correct, however the UDP checksums are not present. Each packet is carrying 5 bytes of data, the ascii characters 'DOM', then 0x02 0x00. 3. Investigate these observations. Initially there does not appear to be a lot of information to go on. Random port numbers rules out identifying any signature that way. A whois check reveals that the 213.68.212.0/23 is owned by a computer publishing company in Germany, but as they may well not be active participants this is of little value. $ whois 213.68.213.140 % This is the RIPE Whois server. % The objects are in RPSL format. % Please visit http://www.ripe.net/rpsl for more information. % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 213.68.212.0 - 213.68.213.255 netname: WUCHERT-LAN descr: REPRO Wuchert computer publishing GmbH descr: Hofsteder Str. 128 descr: D-44809 Bochum descr: Germany country: DE [Remainder snipped] The only unusual attribute shared by these packets is the 'DOM' 0x02 0x00 payload and a quick web search on Google throws up the following link: http://www.qualys.com/alert/remoteshellb.html This page describes the RST.b trojan which puts the victim host's network interfaces into promiscuous mode and listens for UDP packets on any port containing the string 'DOM' and an action code. This is completely consistent with the captured packets. The RST.b trojan infects Linux ELF executables by inserting code into the executable which forks a child and then runs the original program. The child performs certain tasks including listening for relevant UDP packets. This virus infects local executables but does not spread itself over the network, and relies on an infected executable being used on other hosts as its host-to-host vector. 4. Interpretation The captured traffic is consistent with a brute-force scan for hosts which have been infected by the RST.b trojan. This trojan will respond to UDP packets to any port containing the string 'DOM', and can execute any shell commands therein. The packets appear to be hand-crafted (lazily since the UDP checksum is missing) rather than generated using the networking built into the OS. Consequently, we can only trust information contained in the capture if we can find some other reason to do so. The RST.b trojan will respond if it is there so for this scan to be useful the attacker must be listening for responses at the source addresses. As the traffic appears to have originated from the same subnet but with widely varying TTL values, I hazard that this information has been randomly generated. Since the largest TTL is 226, the attacking network cannot be more than 29 hops from the honeynet, but there are few pairs of hosts on the internet that are more than 29 hops apart so this is of little value. There is no evidence of a related scan prior to the attack in question in order to determine which hosts might respond so it can be assumed that the attacker expects to receive a response from any of the probes and must therefore be listening for responses to any of the source addresses. Also, some packets have the same source address. If the source addresses were really being spoofed to avoid detection then this would be odd behaviour. Perhaps it is to confuse the analysis even more, but combined with the above evidence I believe that the hosts that seem to be attacking are involved in this attack. It seems odd that the packets arrive within a very short time interval and that they arrive in order. Certainly this implies that the attack is being controlled centrally from elsewhere, and it could be that the packets actually originated from a single host but with spoofed source addresses to redirect the responses elsewhere. Whether this level of sophistication is necessary is unclear. It has the advantage that it hides the genuine source IP but the attacker still needs control over other hosts to set up listeners, so why they shouldn't also be used to perform the scan is not obvious. The more likely theory is that the controlling process orders out the scan sequentially and slowly enough that it remains sequential throughout. 5. Conclusion The attacker has taken control of a selection of hosts in the 213.68.212.0/23 subnet and is using them in a scan for backdoors opened by the RST.b trojan. 6. Answers to questions 6.1. What is the attacker attempting to achieve? The attack is to find hosts which have already been compromised by a trojan which will offer the attacker the ability to run arbitrary commands. As none of the honeynet hosts were infected no further action was seen, so the ultimate aim of the attacker is unknown. 6.2. How does UDP work to achieve this purpose? The trojan, once installed, puts the network interfaces into promiscuous mode and waits for UDP packets containing the string 'DOM' possibly followed by further instructions, including arbitrary shell commands. As UDP is stateless, these packets can carry a dialogue without involving the TCP stack of the OS, making this attack more likely to go unnoticed. 6.3. Why is the attacker using random src and dst UDP ports and random IP addresses? As the trojan listens for UDP packets on all ports by using promiscuous mode, it is not necessary to use a fixed dst port and using a random dst port will make it harder to spot this attack. Presumably the src port can be chosen freely by the source host and will be chosen randomly for the same reason. Alternatively, the source host may also be listening on all ports and so the victim may respond to any port, in which case randomising the src port further obfuscates the attack. As discussed at length above, the source IP addresses are not random, but represent hosts which are under the control of the attacker and which are being used in the attack. The destination IP addresses are sequentially scanned which suggests a systematic probe rather than a random one. 6.4. Are all the packets originating from the same machine or different ones? It is certainly true that the attacker wishes the responses to be sent to different machines. It is not immediately obvious that they all originated from the same machine although this would make for simpler attack software at little cost of losing the extra obfuscation. So, paranoia aside, the packets probably all came from where they say they did. 6.5. How can the attacker view the responses to his probes? The trojan, if installed, will reply to the source address in the probe packet. The attacker must therefore be listening for reply packets at the source address. If the trojan is not running then the probe packet will either be dropped or refused with an ICMP unreachable message. In this case, the probes were silently dropped. 6.6. Bonus: Can the attacker fingerprint the OS of the victim systems? In this case, no, the attacker received no information in response so he can deduce little about the OS of the victim. The standard response to a UDP packet to an invalid port is an ICMP port unreachable message so the only information given to the attacker is that there is some kind of firewalling going on. If the probe had received a positive response then the victim system must have been running a version of Linux which supports ELF, since this is the only setup the RST.b trojan infects. If the probe had received a negative response in the form of an ICMP packet then perhaps some information about the remote OS can be deduced, for example using the ToS field or any munging which is done to the returned packet. Without a large survey of this kind of information (as insecure.org has done with nmap's OS detection) there is probably little which can be positively deduced about the remote system, although it is simple to check that the remote system is _not_ some particular variant of an OS by testing against that OS. Appendix A. Tools used. Wget, gzip, md5sum to get the Snort log. Ethereal to analyse the data. Google. End of analysis.