Scan 21 This month's challenge is to make sense of a seemingly innocuous flurry of UDP packets. Skill Level: Intermediate Marek Gutkowski -------------------------------------------------------------------------------- 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. Download: 0215@000-snort.log.tar.gz MD5 = 58abd0cb0cbe4c31930225dd229352a5 What is the attacker attempting to achieve? How does UDP work to achieve this purpose? Why is the attacker using random src and dst UDP ports and random IP addresses? Are all the packets originating from the same machine or different ones? How can the attacker view the responses to his probes? Bonus Question: Can the attacker fingerprint the OS of the victim systems? -------------------------------------------------------------------------------- Analysis First, we need to download, verify, and decompress the log: $ md5sum 0215@000-snort.log.tar.gz 58abd0cb0cbe4c31930225dd229352a5 0215%40000-snort.log.tar.gz $ tar -xzf 0215@000-snort-log.tar.gz I was looking for UDP packets, so I did: $ tcpdump -r 0215@000-snort.log 'udp' 04:26:07.599487 216-164-2-74.hybrid.nyr.ny.cable.rcn.com.netbios-ns > 172.16.1.107.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 13:07:45.117713 216-118-19-214.ip.pdq.net.netbios-ns > 172.16.1.103.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 13:07:46.607182 216-118-19-214.ip.pdq.net.netbios-ns > 172.16.1.103.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 13:07:48.103265 216-118-19-214.ip.pdq.net.netbios-ns > 172.16.1.103.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 17:39:58.939969 208.187.189.25.902 > 172.16.1.102.sunrpc: udp 56 17:39:58.942226 172.16.1.102.sunrpc > 208.187.189.25.902: udp 28 (DF) 17:39:59.138765 208.187.189.25.903 > 172.16.1.102.32775: udp 1076 17:39:59.142381 172.16.1.102.32775 > 208.187.189.25.903: udp 32 (DF) 17:39:59.356450 208.187.189.25.903 > 172.16.1.105.sunrpc: udp 56 17:39:59.359260 172.16.1.102.sunrpc > 208.187.189.25.903: udp 28 (DF) 17:39:59.571651 208.187.189.25.904 > 172.16.1.105.32775: udp 1076 17:39:59.575558 172.16.1.102.32775 > 208.187.189.25.904: udp 32 (DF) 17:39:59.785398 208.187.189.25.905 > 172.16.1.108.sunrpc: udp 56 17:39:59.788330 172.16.1.102.sunrpc > 208.187.189.25.905: udp 28 (DF) 17:39:59.952914 208.187.189.25.906 > 172.16.1.108.32775: udp 1076 17:39:59.956859 172.16.1.102.32775 > 208.187.189.25.906: udp 32 (DF) 18:47:38.380532 knet-18.knet.on.ca.netbios-ns > 172.16.1.106.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 18:47:39.871458 knet-18.knet.on.ca.netbios-ns > 172.16.1.106.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 18:47:41.380238 knet-18.knet.on.ca.netbios-ns > 172.16.1.106.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 21:22:22.838009 216.222.44.229.netbios-ns > 172.16.1.106.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 21:22:24.400460 216.222.44.229.netbios-ns > 172.16.1.106.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 01:50:15.097431 213.68.213.135.5298 > 172.16.1.101.18030: udp 5 01:50:15.173222 213.68.213.133.19566 > 172.16.1.102.18202: udp 5 01:50:15.177698 213.68.213.135.9280 > 172.16.1.103.19757: udp 5 01:50:15.178347 213.68.213.144.17773 > 172.16.1.104.3327: udp 5 01:50:15.179336 213.68.213.130.19841 > 172.16.1.105.15316: udp 5 01:50:15.180052 213.68.213.135.14604 > 172.16.1.106.12208: udp 5 01:50:15.180834 213.68.213.140.1348 > 172.16.1.107.5274: udp 5 01:50:15.181597 213.68.213.133.16932 > 172.16.1.108.16219: udp 5 01:50:15.182350 213.68.213.134.18986 > 172.16.1.109.10903: udp 5 Last 9 packets look suspicious: they were coming from different addresses (but on the same network!) and different ports, while having the same length (5 data bytes). Destination IP's were 172.16.1.101 - 172.16.1.109. I needed more information about these nine packets, so I did: $ tcpdump -r 0215@000-snort.log -x -X -ttt 'net 213.68.213.0/24' 000000 213.68.213.135.5298 > 172.16.1.101.18030: udp 5 0x0000 4500 0021 d316 0000 be11 d173 d544 d587 E..!.......s.D.. 0x0010 ac10 0165 14b2 466e 000d 0000 444f 4d02 ...e..Fn....DOM. 0x0020 00 . 075791 213.68.213.133.19566 > 172.16.1.102.18202: udp 5 0x0000 4500 0021 7115 0000 e211 0f76 d544 d585 E..!q......v.D.. 0x0010 ac10 0166 4c6e 471a 000d 0000 444f 4d02 ...fLnG.....DOM. 0x0020 00 . 004476 213.68.213.135.9280 > 172.16.1.103.19757: udp 5 0x0000 4500 0021 590c 0000 9711 727c d544 d587 E..!Y.....r|.D.. 0x0010 ac10 0167 2440 4d2d 000d 0000 444f 4d02 ...g$@M-....DOM. 0x0020 00 . 000649 213.68.213.144.17773 > 172.16.1.104.3327: udp 5 0x0000 4500 0021 850e 0000 9b11 4270 d544 d590 E..!......Bp.D.. 0x0010 ac10 0168 456d 0cff 000d 0000 444f 4d02 ...hEm......DOM. 0x0020 00 . 000989 213.68.213.130.19841 > 172.16.1.105.15316: udp 5 0x0000 4500 0021 5d15 0000 9811 6d76 d544 d582 E..!].....mv.D.. 0x0010 ac10 0169 4d81 3bd4 000d 0000 444f 4d02 ...iM.;.....DOM. 0x0020 00 . 000716 213.68.213.135.14604 > 172.16.1.106.12208: udp 5 0x0000 4500 0021 6516 0000 9b11 626f d544 d587 E..!e.....bo.D.. 0x0010 ac10 016a 390c 2fb0 000d 0000 444f 4d02 ...j9./.....DOM. 0x0020 00 . 000782 213.68.213.140.1348 > 172.16.1.107.5274: udp 5 0x0000 4500 0021 3010 0000 9e11 946f d544 d58c E..!0......o.D.. 0x0010 ac10 016b 0544 149a 000d 0000 444f 4d02 ...k.D......DOM. 0x0020 00 . 000763 213.68.213.133.16932 > 172.16.1.108.16219: udp 5 0x0000 4500 0021 1301 0000 c011 8f84 d544 d585 E..!.........D.. 0x0010 ac10 016c 4224 3f5b 000d 0000 444f 4d02 ...lB$?[....DOM. 0x0020 00 . 000753 213.68.213.134.18986 > 172.16.1.109.10903: udp 5 0x0000 4500 0021 c30c 0000 cb11 d476 d544 d586 E..!.......v.D.. 0x0010 ac10 016d 4a2a 2a97 000d 0000 444f 4d02 ...mJ**.....DOM. 0x0020 00 . Now, I had a hex (-x) and character (-X) dump of packet data, and a delay between packets (-ttt). It was easy to notice that all of them carried the same data (44 4f 4d 02 00, displayed as "DOM.." on character dump). A Google search on "+DOM +UDP" lead me (after some irrelevant links) to a Qualys web page (http://www.qualys.com/forms/remoteshellb.html). I wasn't very happy to see a registration form, but all the information I needed was right there. The page said: RST.b is a newly discoverd Trojan which affects various Linux platforms and installs backdoor functionality for executing arbitrary commands on infected systems. RST.b was identified and examined by Qualys researchers. I had enough keywords to perform a next Google search ("Qualys rst.b DOM UDP"). The answer was http://lists.insecure.org/incidents/2002/Jan/0073.html: Technical Description: ---------------------- The Remote Shell Trojan RST.b operates as both a self-replicating program and a remote control backdoor program. Once a host has been infected - commonly initiated through the execution of binary email attachments or downloaded software - the Remote Shell Trojan RST.b then initiates a virus-like self replication process that infects additional executable binaries in the current working directory and in the /bin directory. No memory resident infection activities have been identified so far. The Infection Process: ---------------------- The infection method used by RST.b is a well-known parasite technique for ELF. It will insert 4096 Bytes physically into the file between the text and data segments. It then modifies the appropriate headers of the binary to account for the change in binary structure. The entry point of the binary is modified to jump to the location of the parasite. Once any executable binary has been infected and is launched, the Remote Shell Trojan code will be executed. After calling ptrace to prevent analysis and debugging, RST.b then issues the HTTP GET request "GET /~telcom69/gov.php HTTP/1.0" to port 80 on the host 207.66.155.21 (ns1.xoasis.com). The requested content does not appear to exist on this host. Additionally, the infected machine will be turned into a network sniffer by turning on the promiscuous flags on ppp0 and eth0 and the backdoor process will be created. The installed backdoor process assumes the credentials of the infected program and will remain active even after termination of the "host" program. In some instances, due to a programming error in the backdoor process, it will terminate together with the termination of the "host" program. The Backdoor Process: --------------------- As the infection process turns an infected machine into promiscuous mode, it is listening for specially crafted UDP packets on any port. An earlier posting on securityfocus.com on this new Trojan has indicated the protocol to be EGP, which is incorrect after careful analysis of the binary. To activate the backdoor, an attacker needs to send a UDP packet containing the three-byte ASCII string "DOM" at a specific offset. Additionally, the packet contains an activation code, determining the type of action from the backdoor process. This could be either: 1) A response UDP packet containing the three-byte ASCII string "DOM" sent to port 0x1111 (4369) of the attacker's host. This provides a simple way querying for infected systems on the Internet. 2) The execution of any command contained within the packet by passing it to /bin/sh -c. This provides an attacker execution of arbitrary commands on the target system at the credential- and permissions-level of infected binary program that has been launched. Our packets contained some sort of echo requests. Analysis of Qualys' rst.b detector's source code (available after registration) confirmed my assumption. To check if a host is infected, the attacker sends a UDP packet to any port of the victim's machine, containing the string "DOM" and a decimal 2. If a backdoor is active, it replies with a string "DOM" sent to port 4369 of attacker's host. Nothing like that happened - the honeypot was clean. Another thing worth noting is that only three of these hosts were actually up (.102, .105, .108). We can tell that by looking on incoming/outgoing TCP packet counts for each of the hosts: $ for i in 1 2 3 4 5 6 7 8 9; do echo -n "172.16.1.10$i: "; tcpdump -r 0215\@000-snort.log "tcp and src host 172.16.1.10$i" | wc -l; done 172.16.1.101: 0 172.16.1.102: 1023 172.16.1.103: 0 172.16.1.104: 0 172.16.1.105: 49 172.16.1.106: 0 172.16.1.107: 0 172.16.1.108: 52 172.16.1.109: 0 $ for i in 1 2 3 4 5 6 7 8 9; do echo -n "172.16.1.10$i: "; tcpdump -r 0215\@000-snort.log "tcp and dst host 172.16.1.10$i" | wc -l; done 172.16.1.101: 31 172.16.1.102: 1924 172.16.1.103: 29 172.16.1.104: 33 172.16.1.105: 50 172.16.1.106: 47 172.16.1.107: 34 172.16.1.108: 46 172.16.1.109: 32 As we can see, snort captured TCP packets going to each of nine hosts, but only three of them replied. Answers What is the attacker attempting to achieve? The attacker is trying to determine if nine hosts (172.16.1.101 - 172.16.1.109) are infected with rst.b trojan. If they were, he could easily execute arbitrary commands on these machines. How does UDP work to achieve this purpose? On infected systems, a special sniffer is installed. It waits for UDP packets containing a string "DOM" followed by a command (decimal 2 in this case). Why is the attacker using random src and dst UDP ports and random IP addresses? The sniffer doesn't check src and dst ports. Different IP addresses are used to make analysis harder, and to evade IDS. The attacker probably controls whole 213.68.213.0/24 network (located in Bochum, Germany, according to RIPE), so all replies from a trojan would be received. Are all the packets originating from the same machine or different ones? All packets were probably sent by the same machine, and the same program. We can tell this from timings and packet sequence. Note that the attacker didn't use Qualys' rst.b detector: our packets contain 5 data bytes, while Qualys' program sends 8 data bytes. How can the attacker view the responses to his probes? Attacker's machine listened for responses arriving to any of the addresses used (probably with a sniffer). Bonus Question:Can the attacker fingerprint the OS of the victim systems? At first glance, no. The attacker receives no reply, because the trojan is not active, and none of UDP ports scanned is open. The attacker has no data to perform OS fingerprinting. On the other hand, an hour before the scan was performed, somebody from Germany (213.20.0.92, 217.0.80.154) checked for anonymous FTP service on 172.16.1.101 - 172.16.1.109. Three machines that were up - .102, .105, .108 - happily introduced themselves as buzzy, scrappy and doohy, running under SunOS 5.8. This FTP scan and rst.b scan might be performed by the same person. On the other hand, why would a blackhat check for a Linux trojan on a SunOS machine? Tools used tcpdump Marek Gutkowski