-------------------------------------------------------------------------------- Honeynet Project: Scan of the Month 21 Analysis and Response June 21, 2002 Dan Macdonald < h o n e y n e t (at) t a z m a n (dot) n e t > -------------------------------------------------------------------------------- This document contains an analysis and response to questions posed as part of the Honeynet Projects Scan of the Month Challenge #21 for June 2002. The Scan consists of a tcpdump formated capture of UDP packets of unknown significance. The challenge consists of determining the significance of these packets. -------------------------------------------------------------------------------- ANALYSIS: -------------------------------------------------------------------------------- I downloaded the tarball containing the Snort capture, confirmed the MD5 signature, then unpacked it. Since the challenge specifically mentioned UDP packets, I first analysed only the udp captures in the file using the following (vvv turns on all the verbosity, xX tells it to decode and display the packet payloads, r reads the file): /usr/sbin/tcpdump -vvvxXr 0215\@000-snort.log udp This revealed the usual flotsam of NetBIOS naming requests and a couple buffer overflow attempts. Then I got near the end of the file and discovered 9 UDP packets, all with a common payload of 0x 444f 4d02, lacking UDP checksums and coming from a common subnet. To make sure I didn't miss anything with the filters, I then switched to an unfiltered tcpdump decode: /usr/sbin/tcpdump -vvvxXr 0215\@000-snort.log and scrolled back to that point in the capture, hoping to find the targets responses to these packets. Alas, there were none, probably due to the Snort configuration. The relevant part of the decode is as follows: 19:50:15.097431 213.68.213.135.5298 > 172.16.1.101.18030: [no cksum] udp 5 (ttl 190, id 54038, len 33) 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 . 19:50:15.173222 213.68.213.133.19566 > 172.16.1.102.18202: [no cksum] udp 5 (ttl 226, id 28949, len 33) 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 . 19:50:15.177698 213.68.213.135.9280 > 172.16.1.103.19757: [no cksum] udp 5 (ttl 151, id 22796, len 33) 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 . 19:50:15.178347 213.68.213.144.17773 > 172.16.1.104.3327: [no cksum] udp 5 (ttl 155, id 34062, len 33) 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 . 19:50:15.179336 213.68.213.130.19841 > 172.16.1.105.15316: [no cksum] udp 5 (ttl 152, id 23829, len 33) 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 . 19:50:15.180052 213.68.213.135.14604 > 172.16.1.106.12208: [no cksum] udp 5 (ttl 155, id 25878, len 33) 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 . 19:50:15.180834 213.68.213.140.1348 > 172.16.1.107.5274: [no cksum] udp 5 (ttl 158, id 12304, len 33) 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 . 19:50:15.181597 213.68.213.133.16932 > 172.16.1.108.16219: [no cksum] udp 5 (ttl 192, id 4865, len 33) 0x0000 4500 0021 1301 0000 c011 8f84 d544 d585 E..!.........D.. 0x0010 ac10 016c 4224 3f5b 000d 0000 444f 4d02 ...lB$?[....DOM. 0x0020 00 . 19:50:15.182350 213.68.213.134.18986 > 172.16.1.109.10903: [no cksum] udp 5 (ttl 203, id 49932, len 33) 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 . -------------------------------------------------------------------------------- QUESTIONS: -------------------------------------------------------------------------------- 1. What is the attacker attempting to achieve? This is the magic question. It would potentially be a lot easier to answer if Snort had captured the responses from the target boxes, but either Snort was not configured to do so or the boxes did not respond. Each UDP packet has a consistent payload (0x 444f 4d02) is missing a checksum, and has a varying TTL which is generally increasing (but not always). One possibility is that the attacker is using UDP as a ping mechanism to sidestep a firewall or IDS. If he were to send a UDP packet to a closed port, an ICMP Port Unreachable would need to be returned since this is the only way to report a closed port in UDP. A second use for this might be OS fingerprinting, although if this is the primary purpose of this traffic the attacker is likely looking for a specific OS to attack, not reconning a specific box. This is because the number of differences available in the UDP stack is generally not enough to identify an OS conclusively, with some exceptions. More on this in question 6. In reality, the actual purpose is probably the latter of the above two explanations: that is the attacker is scanning for a particular OS to attack. The speed at which these packets arrive and the unreliability of a generalized fingerprint based on only a UDP packet indicates that this is probably an automated tool looking for specific boxes of interest for later hacking. Given the variable TTLs in the packets, the attacker may be able to detect some rudimentary network architecture information as well, but it is not likely to be a goal in this case. The attacker is likely a script kiddie who is running a script due to the rapid arrival times and the sequential scan of IPs. If he were a sophisticated hacker attempting to map a multiple layer network he would probably be much more careful than to use the rapid-fire approach shown here. Plus, most multi-layer networks are going to either break at the logical subnetting breaks or use NAT. In the first case, the attacker doesn't show any interest in the breaks, and in the second, most NAT systems have potential to mangle the response so as to be useless for such purposes which would make any information gleaned unreliable. 2. How does UDP work to achieve this purpose? UDP works well for this since it is a stateless protocol. Since UDP is stateless, the only way to report a closed port is to return an ICMP Port Unreachable to the source address. This would tell the attacker that the host at that particular IP is indeed online, but without using the standard ICMP Echo Request mechanism that many networks block. UDP also tends to have much less attention spent on it by IDS and Admins, so it is less likely to trip an IDS the way attempting something similar with TCP would. 3. Why is the attacker using random src and dst UDP ports and random IP addresses? Probably to mask their real identity and to evade tripping a portscan warning. Notice that the source IPs while changing are still all coming from the same subnet. This may be for one or a combination of two reasons. The attackers ISP may have his router configured correctly to lessen IP spoofing, thus limiting the number of available IPs to spoof from. More likely, the attacker intentionally spoofed in the same subnet so that he could recieve results from his probes as explained in question 5. 4. Are all the packets originating from the same machine or different ones? Given the tight timing of the packets arriving at the targets (approx .08s between the first and second packets, approx .001 apart after that) and the fact that the packets arrived sequentially at the series of target hosts, it is likely that all the packets are generated from a single machine. If it were multiple machines (I.E. a DDoS) the timing would not likely be so precise both in terms of generating the packets and eliminating the possibility of net jitter causing them to arrive in a different order. More likely it is one machine generating the (spoofed) packet for the first machine, then waiting for a response before moving on to the next. 5. How can the attacker view the responses to his probes? If there are responses, since all the source IPs from the traffic in question appear to be located within the same subnet, all responses from the target hosts should be routed back to that same network. If the attacker is located in this subnet, (and we can reasonably conclude that they are) then the attacking host could potentially read the response traffic with a sniffer or an interface in promiscuous mode and a script. In fact, an automated script or application latter is likely the reason for the tight timing mentioned above in question 4. This is especially true if the 213.68.213.x network is a shared media network such as a hubbed ethernet, but may also be possible with MAC spoofing or other methods. Note that this need not be a /24 network, but can even be smaller than that, possible even as small as /27 (213.68.216.128-160) Bonus Question: 6. Can the attacker fingerprint the OS of the victim systems? Without seeing the responses from the hosts in question or knowing the OSs running on those hosts, it is impossible to say whether the attacker did conclusively fingerprint those systems in particular using only the packets in question. It may be possible to get a conclusive fingerprint using only the packets in question however based on information such as whether the OS inserts the correct UDP checksum (which would explain the missing checksum), how much data was echoed in the ICMP response, whether packet and datagram lengths are correct, etc. Due to the limited number of differences in UDP stacks, it is unlikely that the attacker is able to generally fingerprint the box, but instead is scanning for a particular OS version which matches a unique fingerprint. -------------------------------------------------------------------------------- TIME SPENT: -------------------------------------------------------------------------------- (in hours) 1 - Analysis 1 - Research 3 - Writeup