Scan of the Month: Scan 21 Ian Cuthbertson Senior Systems Engineer Nokia Internet Communications -------------------------------------------------------------------------------- Tools used to decode this trace 1. Windump (http://windump.polito.it/) 2. Ethereal (http://www.ethereal.com/) Firstly, as the trace contains a large amount of data use some filters to get only the packets of interest into a file. windump -r 0215@000-snort.log -n -w 0215udp "udp and src net 213.68.213.0 mask 255.255.255.0" A hex dump of this file gives the following output 00:50:15.097431 213.68.213.135.5298 > 172.16.1.101.18030: udp 5 4500 0021 d316 0000 be11 d173 d544 d587 ac10 0165 14b2 466e 000d 0000 444f 4d02 00 00:50:15.173222 213.68.213.133.19566 > 172.16.1.102.18202: udp 5 4500 0021 7115 0000 e211 0f76 d544 d585 ac10 0166 4c6e 471a 000d 0000 444f 4d02 00 00:50:15.177698 213.68.213.135.9280 > 172.16.1.103.19757: udp 5 4500 0021 590c 0000 9711 727c d544 d587 ac10 0167 2440 4d2d 000d 0000 444f 4d02 00 00:50:15.178347 213.68.213.144.17773 > 172.16.1.104.3327: udp 5 4500 0021 850e 0000 9b11 4270 d544 d590 ac10 0168 456d 0cff 000d 0000 444f 4d02 00 00:50:15.179336 213.68.213.130.19841 > 172.16.1.105.15316: udp 5 4500 0021 5d15 0000 9811 6d76 d544 d582 ac10 0169 4d81 3bd4 000d 0000 444f 4d02 00 00:50:15.180052 213.68.213.135.14604 > 172.16.1.106.12208: udp 5 4500 0021 6516 0000 9b11 626f d544 d587 ac10 016a 390c 2fb0 000d 0000 444f 4d02 00 00:50:15.180834 213.68.213.140.1348 > 172.16.1.107.5274: udp 5 4500 0021 3010 0000 9e11 946f d544 d58c ac10 016b 0544 149a 000d 0000 444f 4d02 00 00:50:15.181597 213.68.213.133.16932 > 172.16.1.108.16219: udp 5 4500 0021 1301 0000 c011 8f84 d544 d585 ac10 016c 4224 3f5b 000d 0000 444f 4d02 00 00:50:15.182350 213.68.213.134.18986 > 172.16.1.109.10903: udp 5 4500 0021 c30c 0000 cb11 d476 d544 d586 ac10 016d 4a2a 2a97 000d 0000 444f 4d02 00 What is the attacker attempting to achieve? As the attacker is incrementing the destination address is sequence, it would be reasonable to assume the attacker is scanning the subnet for active hosts. How does UDP work to achieve this purpose? UDP will achieve this purpose, because any host which is active will respond with an "ICMP Port unreachable" message. They may also get responses from the router to indicate hosts are not active ("ICMP Host Unreachables"). Why is the attacker using random src and dst UDP ports and random IP addresses? The attacker is using random source and destination ports and random IP addresses to try and fool simple IDS systems. Changing these parameters could cause a simple IDS system not to notice this scan. Are all the packets originating from the same machine or different ones? All the packets appear to have been sourced from the same machine. I say this because the time delta between the packets is very small, which tends to point to an automated script running on a single machine. Although displaying the packets with a -v option shows varying ttl values: 00:50:15.097431 213.68.213.135.5298 > 172.16.1.101.18030: udp 5 (ttl 190, id 54038) 00:50:15.173222 213.68.213.133.19566 > 172.16.1.102.18202: udp 5 (ttl 226, id 28949) 00:50:15.177698 213.68.213.135.9280 > 172.16.1.103.19757: udp 5 (ttl 151, id 22796) 00:50:15.178347 213.68.213.144.17773 > 172.16.1.104.3327: udp 5 (ttl 155, id 34062) 00:50:15.179336 213.68.213.130.19841 > 172.16.1.105.15316: udp 5 (ttl 152, id 23829) 00:50:15.180052 213.68.213.135.14604 > 172.16.1.106.12208: udp 5 (ttl 155, id 25878) 00:50:15.180834 213.68.213.140.1348 > 172.16.1.107.5274: udp 5 (ttl 158, id 12304) 00:50:15.181597 213.68.213.133.16932 > 172.16.1.108.16219: udp 5 (ttl 192, id 4865) 00:50:15.182350 213.68.213.134.18986 > 172.16.1.109.10903: udp 5 (ttl 203, id 49932) This would either indicate several different sources or crafted packets. Based on the timing issue outlined about I would suggest these packets have been crafted. If the ttl values were considerably lower this could be considered as some sort of perimeter scanning technique, but this appears not to be the case. Also note that the udp payload is the same on all packets "444f 4d02 00", which in ASCII can be decoded as "DOM..". This would indicate all packets being generated by the same tool. How can the attacker view the responses to his probes? The attacker will only be able to review the responses to these probes if he is on a path between 213.68.213.128/27 and the subnet he is trying to scan. As he is using a tighly defined set or source addresses I would suggest he may we be on the 213.68.213.128/27 subnet and able to capture all packets returning to those machines. Can the attacker fingerprint the OS of the victim systems? The attacker may be able to fingerprint the systems using this UDP scan. Examples include "taken from http://www.insecure.org/nmap/nmap-fingerprinting-article.txt" "ICMP Message Quoting -- The RFCs specify that ICMP error messages quote some small amount of an ICMP message that causes various errors. For a port unreachable message, almost all implementations send only the required IP header + 8 bytes back. However, Solaris sends back a bit more and Linux sends back even more than that. The beauty with this is it allows nmap to recognize Linux and Solaris hosts even if they don't have any ports listening ICMP Error message echoing integrity -- I got this idea from something Theo De Raadt (lead OpenBSD developer) posted to comp.security.unix. As mentioned before, machines have to send back part of your original message along with a port unreachable error. Yet some machines tend to use your headers as 'scratch space' during initial processing and so they are a bit warped by the time you get them back. For example, AIX and BSDI send back an IP 'total length' field that is 20 bytes too high. Some BSDI, FreeBSD, OpenBSD, ULTRIX, and VAXen fuck up the IP ID that you sent them. While the checksum is going to change due to the changed TTL anyway, there are some machines (AIX, FreeBSD, etc.) which send back an inconsistent or 0 checksum. Same thing goes with the UDP checksum. All in all, nmap does nine different tests on the ICMP errors to sniff out subtle differences like these. Type of Service -- For the ICMP port unreachable messages I look at the type of service (TOS) value of the packet sent back. Almost all implementations use 0 for this ICMP error although Linux uses 0xC0. This does not indicate one of the standard TOS values, but instead is part of the unused (AFAIK) precedence field. I do not know why this is set, but if they change to 0 we will be able to keep identifying the old versions _and_ we will be able to identify between old and new."