----------------------------------- scan of the month #21 Justin Wright [jwright@cryptek.com] ----------------------------------- The "flurry of strange UDP packets" that I identified are packets #3360 to #3368. A set of packets sent to 9 consecutive IP's (172.16.1.101-109) from 6 unique IP source addresses (213.68.213.130, 133, 134, 135, 140, 144). 1. What is the attacker attempting to achieve? The attacker is attempting to scan a list of IP's (172.16.1.101-109) to see if they are alive. This is very similar to a standard ping scan, except the attacker uses UDP packets instead of ICMP echo packets. An IP is "alive" if there is a computer using that IP. It is useful to an attacker to scan a set of IP's like this to find ones that are alive in order to find potential targets of attack and cull out any IP's that are not alive and therefore would be futile to attack (since they don't exist). 2. How does UDP work to achieve this purpose? The purpose, as stated above, is to find out which IP's are alive and which are not. To understand how it works, I will first refer to a more common way of finding out if an IP is alive. This is using ICMP Echo packets. The way in which you use ICMP Echo packets is you send a ICMP Echo Request to the IP in question and if you recieve an ICMP Echo Reply, you know that there is a computer at that IP that you can talk to. The attacker is using UDP packets in much the same way. However, in using UDP packets, there will be three common reactions per UDP packet sent by an attacker. These three responses are: 1) There is no computer with that IP address or (as is probable in this case) ICMP packets are being dropped somewhere between the target and the attacker. If this is the case, then the attacker will recieve no response to the UDP packet he sent. From the packet log, this seems to be the case for all 9 UDP packets sent. However, from the packet log, we know that at least one IP (172.16.1.102) is alive from the IRC traffic it is generating and probably others are alive as well (172.16.1.105,108). It is my guess that the machines behind these three IP's are configured not to generate the type of replies that they would normally (discussed below). 2) There is a computer with that IP address, but not listening on the port specified for UDP traffic. In this case (barring the computer is configured to do so as mostly are by default), the target will respond to the UDP packet with an ICMP Destination Unreachable (Type 3) saying Port Unreachable (Code 3). Basically, the target machine that recieved this packet is telling the attacker that it is not currently listening for UDP packets at the port specified. From this ICMP Destination Unreachable reply, the attacker now knows that the IP is alive and could potentially be a target for further attack. This is very similar to the attacker sending an ICMP Echo Request and getting back an ICMP Echo Response. 3) There is a computer with that IP address (alive) and it is listening for UDP packets on the port specified by the UDP packet. In this case, the daemon listening on that port determines what the reaction will be. In most cases, the daemon will not understand the packet sent to it and just drop it without sending back a response. I tested this briefly by sending UDP packets to several daemons running (nmap -sU) on one of my machines and did not get a single response back. This could account for the packet log, however I find it highly unlikely because the attacker chose random high ports. The possibility of a daemon/process listening on these specific ports if very slim. It is likely that the attacker did this on purpose to mitigate the risk of a false negative reaction. 3. Why is the attacker using random src and dst UDP ports and random IP addresses? The source ports on the UDP packets have no affect on the results of the scan. Most likely, the attacker chose to make them random high ports so that the packets would look more like random traffic instead of a probe. The destination ports are a factor in what the results of the scan are. As discussed above, the attacker would want to address the UDP packets to UDP ports that the victim system is not listening on. Choosing random high ports gives the attacker good probability that the victim system would not be listening to such a port. It is still possible, but not likely. As with the random source ports, the random destination ports make the packets look more like random traffic than a planned probe. It is interesting to note here that this only works if you look at each packet in the scan individually. If they are seen together, they are obviously related and can be identified as a scan. So the attacker must have been assuming or hoping that the victim IPs were on disperate company or individual networks that don't share information. The random source IPs were random in a very limited sense. All of the source IP's were only 11 IP addresses apart, probably on the same subnet. Most likely the attacker chose source IP's that either ended on the same subnet or were routed through the attackers machine (see below). The destination addresses were not random at all. The packets probed 9 IP addresses sequentially. Obviously a scan on a specific range of IP addresses and not a scan of random IP addresses. 4. Are all the packets originating from the same machine or different ones? At first glance (by looking at the source IP) it looks as though the packets are originating from different machines. However, it is very likely that the packets all originated from the same machine. The reason for this is that the packets came out in order (going to sequencial IP addresses) and with a very small delay in between the packets. The odds of 6 different machines sending out packets that arrived that close together and sequencial are slim. It is interesting to note that the attacker may have tried to increase this facade by randomizing the Time To Live (TTL) field in the IP headers. Normally the TTL is set to a consistant number depending on the Operating System. From this scan we can see that the TTL changes even when the packet originates from the same IP, which further leads to the conclusion that the fields in the packets are being set at random by just one machine. 5. How can the attacker view the responses to his probes? There are two remote ways for an attacker to view any responses to his probing. The first way is for the attacker to be connected to the same hub as the machines he is spoofing. In this case, all of the machines plugged into this hub would be able to see all packets that are sent or recieved by any of the other machines on the hub. So the attacker could have sent packets that look like they are coming from random machines on this hub and have a sniffer running to capture any responses that are sent back to those machines. The second way for the attacker to see the responses is to have access to a machine that is on the route from the target and the spoofed computers. This could be a router or a firewall or a gateway, etc. As the responses are coming back, the attacker can watch for them as they are passed along. Bonus Question: 6. Can the attacker fingerprint the OS of the victim systems? Assuming the attacker gets responses from the UDP packets sent out, the ability to fingerprint the OS of the victim systems is very limited. From this scan, the attacker would recieve only one packet from each victim system and the packet would be an ICMP Destination Unreachable. One ICMP Destination Unreachable packet would generally not be enough data to make a solid fingerprinting decision. However, there is some data that the attacker could use to make a guess. This data would mostly reside in the IP header fields of the response. Some of the fields that the attacker could look at to try and identify what type of OS sent the packet would be the Flags field (whether or not the packet can be fragmented) and the TTL. Both of these fields can be peculiar to an OS and could potentially provide some insight. However this has limited use in that the attacker would have to rely on probing a system that uses a unique number in one of those fields. Without the data from a TCP header (sequence, acknowledgement, etc), OS fingerprinting is much less reliable. The attacker would most likely not be able to guess the OS of the victim systems without probing further with multiple TCP packets to the same machine. Justin Wright Cryptek, Inc. Trusted Architecture Division