*********************** * SCAN 21 - June 2002 * *********************** - AUTHOR: Raul Siles (Spain). e-mail: raul_siles@hp.com - INITIAL ANALISYS: ==================== After checking the MD5 value of the downloaded Snort file for this scan, number 21, a network traces analysis is a must. We will use the network traces “Swiss Knife”, Ethereal (http://www.ethereal.org). This tool allow us to analyze network traces in tcpdump binary format, as the ones obtained with Snort. - UDP Packet analysis: ----------------------- The only UDP packets in the Snort network traces apart from some NetBIOS and RPC packets are the nine consecutive IP packets starting at packet number 3360 and ending at packet 3368. The source IP address for all packets is contained in the following addresses set: 213.68.213.135, 133, 144, 130, 140, 134. It seems to be some kind of horizontal scanning, cause the destination of every packet is a different host inside the Honeynet network, from 172.16.1.101 to .109. It is a fast scan, cause all the time delta between packets is less than 0.001 seconds (1 ms). Both, UDP source and destination ports seem to be random. All the packets contains a payload of 5 bytes: - String: "DOM.." - Hexadecimal values: "44 4f 4d 02 00" Packet length for all packets is 33 bytes: - IP header: 20 bytes - UDP header: 8 bytes - Payload: 5 bytes Once the IP and UDP port source and destination values have been commented, the other information that changes between packets is: - IP checksum, as expected, cause IP addresses and ports change. - IP ID, as expected, each new packet has a new ID for fragmentation/reassembly purposes. - TTL value: it changes from packet to packet. source IP TTL --------- --- 135 190 133 226 135 151 144 155 130 152 135 155 140 158 133 192 134 203 If all the packets have been generated from the same system, they have followed very different Internet paths. - RESPONSES TO QUESTIONS: ========================== 1. What is the attacker attempting to achieve? ----------------------------------------------- It seems that the set of UDP packet belong to a security scanning technique known as "UDP ping sweep". The purpose of this method is identify the hosts that are reachable and available in the target remote network scanned. The main question this scan tries to respond is: "Are the target hosts up and running?" There are multiple methods used to scan available remote hosts. Some of the most typical ones are: A. Standard ICMP echo request and reply packets (ping sweep): When a system sends an ICMP echo request, the destination host sends back an ICMP echo reply packet. B. Non-echo ICMP sweep: Using other ICMP types, it is possible to get information and see if a system is active or not. Other typically used ICMP types are: Information, Timestamp or Address Mask request. C. TCP scan: TCP SYN, FIN or ACK scans. Using TCP you can scan a network based on the activation of different TCP flags and how the TCP state diagram responds to them: sending back SYN-ACK or RST packets. D. UDP scan. It uses UDP packets, combined with ICMP responses to scan remote hosts (see QUESTION 2 for details). The ICMP echo packets, "A" method, usually fail to elicit a response cause network filtering devices stop inbound ICMP traffic. The TCP and UDP methods can be used to develop port scans, to be able to know which services are being offered by a remote system, while ICMP doesn´t have the port concept. This kind of scanning could be called "vertical scan", focused in analyzing just one system. On the other hand, all shown methods can also be used to test the reachability of a remote system, providing information about the availability of the remote host. This other scan type could be called "horizontal scan", focused on a big systems set. In the example analyzed, the port used doesn´t matter if it is capable of providing enough accurate information to know if the system is active or not. A closed port is the best candidate. A broader scan of this type allows to know which devices (IP addresses) are active in a remote IP network. This is the purpose of the UDP packets found on this scan of the month contest. Some tools are capable of execute a similar technique: - NetScanner: http://www.netscantools.com/nstpro_netscanner.html - NMAP: http://www.insecure.org/nmap/ The -u (UDP) option of NMAP implements this scanning method for root users. - Perl 5.6.1 documentation: "Net::Ping - check a remote host for reachability" Module "Net::Ping" allows the generation of TCP, ICMP and UDP ping packets. - HPING: http://www.kyuzz.org/antirez/hping/ - Numeric JOKE: ---------------- Is there any reason why the analyzed packets length is 33 bytes? Perhaps because the type and code of the ICMP Port Unreachable packet is 33 (type:3 and code:3) ;-) 2. How does UDP work to achieve this purpose? ---------------------------------------------- The "UDP ping sweep" is also called "UDP ICMP port unreachable scanning". Let´s see why ICMP is used in its name ;-) This scanning method uses the UDP protocol in combination with the ICMP error and control protocol. While UDP protocol is simpler than TCP, scanning it is actually significantly more difficult. This is because it is a connectionless protocol where open ports don't have to send an acknowledgement in response to a probe (as TCP does), and closed ports aren't even required to send an error packet. Fortunately, most hosts do send an ICMP Port Unreachable error when you send a packet to a closed UDP port. Thus you can find out if a port is NOT open, and by exclusion determine which ports which are (see filtering concerns bellow). The UDP protocol is defined in RFC 768. The ICMP protocol is defined in RFC 792 (and then later in RFCs 896, 950, 1122, 1191, 1256, 1349 and 1812): http://www.rfc-editor.org/. Neither UDP packets, nor the ICMP errors are guaranteed to arrive, so UDP scanners of this sort must also implement retransmission of packets that appear to be lost (or you will get a bunch of false positives). You consider it is open if you didn´t get any response for any of the packets. Take into account that if a host is protected by a filtering device, a port that is silently dropped (which most firewalls do) is detected as an opened port. This is the most common false positive you get when using this method. So, an advanced method to minimize this kind of false positive, improving this technique is to scan a large number of destination ports on the same host. If we do not receive a reply for any of them, it would like that a large number of UDP ports are opened. What is more probable is that the remote host is protected by a filtering device, and nearly all of the ports are closed. To remedy this, a thresold can be set to determine that a filtering device is being used when it is reached. For example, NMAP version 2.3beta13 uses it. This scanning technique is slow because of compensation for machines that took RFC 1812 (section 4.3.2.8) to heart and limit ICMP error message rate. For example, in NMAP documentation (http://www.insecure.org/nmap/nmap_doc.html) you can read that the Linux kernel (in net/ipv4/icmp.h) limits destination unreachable message generation to 80 per 4 seconds, with a 1/4 second penalty if that is exceeded. Solaris has much more strict limits (about 2 messages per second) and thus takes even longer to scan. As is typical, Microsoft ignored the suggestion of the RFC and does not seem to do any rate limiting at all on Win95 and NT machines. Thus we can scan all 65K ports of a Windows machine very quickly. For this method to work, the UDP packet payload could be any size, starting at 0 bytes. The captured packets have an UDP payload of 5 bytes. Also, you will need to be root for access to the raw ICMP socket necessary for reading the port unreachable response (although there are some techniques to be able to test if the ICMP packet has been received without being root, based on the return value of some network system calls: recvfrom() and write()). Many firewalls have two main filtering options: - discard: it simply discards or drops the packet. - reject: it sends a notification packet, for example, a TCP reset packet. In summary, the UDP port scan can only detect one of two UDP port states: 1) The port is closed or the firewall is rejecting packets destined for the port. 2) The port is open or the firewall is discarding packets destined for the port. During the past, there had been multiple tools based on the UDP method to check system availability, instead of using the traditional ICMP method. These tools used to work with the UDP standard port reserved for echo: port 7. They are really useful for troubleshooting purposes if ICMP packets are not allowed in the network. 3. Why is the attacker using random src and dst UDP ports and random IP addresses? ----------------------------------------------------------------------------------- The usage of random destination ports allow to check ports typically not used by common services, that will be closed in most systems, so the probability of getting the expected ICMP Port Unreachable message is really high. The best method for the UDP destination port testing should be to try on ports not included in the standard IANA list of assigned ports. This list is available in the following URL: ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers To be accurate, the choosen port should be definitely closed. The best example will be port 0, but it will be detected pretty easily by IDS. On the other side, the usage of random source IP addresses and ports try to simulate real Internet traffic, coming from multiple source clients. It does so using a technique called IP spoofing, to forge the real source IP address. Generating all these multiple requests is even more difficult to filter the scan attack by an incident response team that has detected it. 4. Are all the packets originating from the same machine or different ones? ---------------------------------------------------------------------------- All the packets seems to be originated from the same system, because although it is a fast scan (nine packets were captured in a fraction of a second), all packets arrived in a sequential order to its intended destination: 101, 102, ... 109. It will be very difficult to synchronized multiple machines to be so accurate in a sequential scan over Internet. Apart from that, all the general packet fields have the same information, for example, the DF bit, the TOS field... TTL values differs a lot between packets, being the minimum value equal to 151 and the maximum equal to 226. Probably, they have crossed different Internet paths before reaching the Honeynet target network, but it has no sense such a big difference if packets are coming from the same system. Apart from that, all the source IP addresses belong to the same class C network, allowing the attacker a greater control over the responses (see QUESTION 5). 5. How can the attacker view the responses to his probes? ---------------------------------------------------------- The expected responses were commented in QUESTION 2. The attacker expects to see an ICMP Port Unreachable packet coming back from the target, indicating that the destination host is active, although the selected destination port is closed. On the other hand, if no response is obtained, then the attacker cannot be sure if the target system doesn´t exists (the destination IP address is not used) or if it is protected by a filtering device. Due to the fact that the attacker tool is using IP spoofing, forging source IP addresses, attacker will need to monitor the path between the class C network used as source in the spoofing method, 213.68.213.0/24, and the target network, 172.16.1.0/24 (lets suppose both are class C networks). The easiest way of conforms to this requirement is through the usage of a sniffer in some of the systems belonging to the source network. If we suppose that the Snort capture is getting all the inbound and outbound packets to the Honeynet, as it should be, we can see there are no ICMP response packets, so the attacker will probably suppose that there is a filtering device in place, cause it is not possible that all the random UDP ports in the nine different systems will be opened. Bonus Question: ---------------- 6. Can the attacker fingerprint the OS of the victim systems? -------------------------------------------------------------- The OS fingerprinting methods can be classified in two sets: 1) Active fingerprinting: The attacker sends formatted packets to the victim, and analyzes how the target responds to them. 2) Passive fingerprinting: The attacker analyzes packets sent by the victim as a response to other packets not sent by the attacker. He is not sending its own packets, but it is just expecting other systems talk with the target, and look into their conversations. In this case, the attacker goal is not getting the target OS but just know if it is up or not. As a collateral effect, it could be able of getting the remote OS based on the ICMP Port Unreachable responses. Analyzing the UDP packets captured, where no special tricks in the IP header have been used, confirm that the attacker goal is not getting the target OS. UDP packets have not been manipulated for this purpose, cause TOS (RFC 1349) and Flags fields are equal to 0. Based on the idiosyncrasies in the responses of different operating systems to the UDP packets sent, the ICMP packets could be used to determine the type of operating system in use at a particular destination. The bible on the subject, ICMP security tricks, has been released by its author, Ofir Arkin: "ICMP usage in scanning": http://www.sys-security.com/html/projects/icmp.html Using direct ICMP fingerprinting will not always work, as most firewalls will block some (or all) incoming ICMP packets. However, they do not always block outgoing packets, so the UDP technique used here should probably work. In the network traces provided, we didn´t see any ICMP messages (the traces finish 10 minutes after receiving the UDP flow). So, it seems that the ICMP packets were not sent back. Based on the Orfin Arkin study, there are some operating systems that never send the ICMP Port Unreachable message. We could be dealing with some of this systems (HP-UX, AIX, DG-UX (page 90)) as the destination system, or perhaps some system is filtering packets. Some of the fields that could allow to the OS detection are: - DF bit - TTL field - TOS field - ICMP error messaging size (echoing part of the offending datagram in the response) - REFERENCES: UDP ping scans and OS fingerprinting: ---------------------------------------------------- - NMAP OS detection: http://www.insecure.org/nmap/nmap-fingerprinting-article.html - NMAP documentation: http://www.insecure.org/nmap/nmap_manpage.html - P0F: http://www.stearns.org/p0f/ - ICMP based remote OS TCP/IP stack fingerprinting techniques: http://www.phrack.com/phrack/57/p57-0x07 - (Honeynet project) Know your enemy - Passive OS fingerprinting: http://project.honeynet.org/papers/finger/ - ICMP fingerprinting (Xprobe tool): http://www.sys-security.com/archive/articles/login.pdf - How Does Network Security Scanning Work Anyway?: http://rr.sans.org/securitybasics/netsec_scanning.php