In summer 2001, Fyodor Yarochkin and Ofir Arkin released a tool called Xprobe v0.0.1p1 based on the work of Ofir Arkin “ICMP Usage in Scanning”. This is a proof of concept tool in its first version. The purpose of this tool is to identify the OS running on a distant host. OS fingerprinting is part of the reconnaissance phase preceding an attack.
This paper is divided in three parts. The first one presents the techniques used by Xprobe. The second shows network traces generated by the tool. The last part discusses some countermeasures necessary to protect the network.
Internet Control Message Protocol (ICMP) is a service protocol in the TCP/IP suite of protocols. There are three categories of ICMP messages : error message, request message and reply message. ICMP is not limited to the ping program. OS fingerprinting based on ICMP is possible due to differences in implementation of ICMP of each operating system.
Xprobe sends UDP and ICMP datagrams to the system being probed. ICMP messages generated by the host in response to the stimuli are then analysed. The results dictates the choice of the next test to apply.
The first stimulus is a UDP datagram sent to a closed port. The expected response is a ICMP port unreachable (type 3 code 3). The payload of an ICMP error message contains the original IP header and at least 64 bits (8 bytes) of original data datagram. The size of data echoed will vary depending on the implementation. Some fields in the original datagram may be wrongly echoed or simply zeroed. In normal usage, only a few fields echoed are actually considered by the receiving host. This is the reason why errors in the following echoed fields usually go unnoticed : IP total length, IP ID, 3 bits Flags, fragment offset, IP header checksum, UDP checksum. Through this analysis, Xprobe is able to categorize OSes.
If the first stimulus did not provide enough information, Xprobe sends a crafted ICMP echo request (type 8). This datagram has a specific TOS value, the DF bit is set and the ICMP code is not null. The victim replies with a ICMP echo reply (type 0). Xprobe watch if the values of TOS, DF and ICMP code are echoed, The TTL value is also analysed. If the results of the previous tests are inconclusive, Xprobe will initiate test for ICMP features not implemented in all IP stacks, i.e. some OSes will not respond to a timestamp request or a netmask request.
In the current version of the tool, a maximum of 4 datagrams will be sent to detect an OS. Xprobe can distinguish several flavours of Windows (95, 98, ME, NT, 2000), a significant improvement in the field of active OS fingerprinting, compared with TCP based OS fingerprinting à la Nmap. This first version of Xprobe was only able to detect a limited amount of OSes and will wrongly identify others. For example, a HP laserjet network printer is detected as a Win2K system.
Xprobe in action:
You can choose the destination port number of the initial UDP datagram (default is 32132), the network interface to use and ask for verbose output.
First probe against AIX 4.3.2 on RS/6000
# x xxx.xxx.xxx.78Xprobe found the correct OS. Let’s see tcpdump output of the fingerprinting :
15:28:31.352777 xxx.xxx.xxx.153.39451 > xxx.xxx.xxx.78.32132: udp 70 (DF)
As can be seen above with one packet sent and one packet received, it is enough to identify as running AIX.
Xprobe (running on machine xxx.xxxx.xxx.153) sends a UDP packet with a payload of 70 bytes to a closed UDP port on xxx.xxx.xxx.78. The probed machine replies with a ICMP port unreachable (type 3, code 3) and quotes the original IP header + 64 bits of original data datagram (i.e. the UDP header). A look at the quoted header shows that at offset 0x1e (bytes 30-31), the IP datagram length is set to 0x0076. In the original packet it was 0x0062 (seen at offset 2) 0x0076 – 0x0062 = 20. The echoed IP length has been increased by 20, the size of the IP header. A manual computation shows that the echoed IP header checksum does not take into account the error in the IP length field (0x60cd, located at offset 0x26 (bytes 38-39)). According to the white paper, these two characteristics are enough to determine an AIX machine because other systems that increase the IP length header by 20, zeroes the IP header checksum. Also visible is that the UDP checksum has been zeroed (word at offset 0x36 (bytes 54-55))
Xprobe against a NT4 sp5 workstation :
# x xxx.xxx.xxx.80Here again, the correct OS has been found. Let’s see the tcpdump output :
19:17:12.298303 xxx.xxx.xxx.153.1117 > xxx.xxx.xxx.80.32132: udp 70 (DF)Xprobe sent 4 packets and received 2. The ICMP port unreachable payload does not contain errors that can help us. We can notice that the DF bit has not been echoed. Xprobe sends a echo request (ICMP type 8) with a code different from 0 (0x7b, located at offset 0x15 (byte 21)). The TOS byte is set to (0x06). In the reply, the windows host zeroes the ICMP code. This is in contradiction with RFC 792 : “To form an echo reply message, the source and destination addresses are simply reversed, the type code changed to 0, and the checksum recomputed.”. This behavior is a characteristic of windows family of operating systems. The TTL of the echo reply is 0x7f=127. Assuming the initial TTL value is 128 eliminates Windows95, which has an initial TTL value of 32. The TOS field is echoed, so this is not a Win2K host. Now, the host can be NT, 98 or ME. Xprobe sends an ICMP time stamp query which generates no reply therefore the system is Windows NT. Our probed host does not reply to the ICMP address mask request, indicating a Service Pack of 4 or above.
The traces above have been generated on a quiet LAN, with no filtering devices between the hosts. It is very unlikely that datagrams could have been lost.
How can my IDS detect the use of Xprobe against my network ?
As opposed to nmap, the current version of Xprobe sends only RFC compliant datagrams, making detection difficult without generating false positives.
The first UDP datagram sent to a closed port may look like a port probe. To detect the probes of this particular tool, one can set up a rule on your IDS to detect UDP packets sent to port 32132 with a UDP payload of 70 bytes and a content full of zeros. Since the destination port is adjustable at command line, it is possible to ignore it in the rule. Keep in mind that any UDP datagram of at least 70 bytes will do the job. Detecting variations of the original code may not be possible. A malicious attacker can modify the program, set the source port to 53 and change the payload so that it looks like a DNS reply to a spoofed address. A review of the firewall policies will be necessary in order to limit this reconnaissance methodology.
The echo request packet is easier to detect because it has 2 particularities : TOS=0x06 and ICMP code = 0x7b (123). You may want to detect ICMP echo requests with TOS != 0 and ICMP code != 0 in order to detect variants of the original code.
Depending on the environment, the IDS can rise alerts when unusual ICMP requests like timestamp and netmask are detected at the border.
We have seen that ICMP OS fingerprinting attempts detection can be very challenging. Intrusion Detection is good. Intrusion Prevention is better. Maybe it is time to have a closer look at the ICMP traffic you let go through your firewall.
ICMP may be restricted at the firewall without regarding the direction of the traffic. However, we will try to let our internal users being able to ping or traceroute the external world.
Before restricting ICMP traffic, be prepared to explain to your remote users that if ping or traceroute are not working across the firewall, it does not necessarily mean that the firewall or the network is down. If they notice a slow down, it can be due to timeouts because they did not receive error messages like port or host unreachable.
We have seen that outgoing ICMP error messages carry a lot of valuable information that can be used against your organisation. You should block all outgoing error messages, i.e. ICMP type 3, 4, 5, 11 and 12. Be careful with ICMP type 3 code 4 (Fragmentation needed but DF flag set) if parts of your network have smaller MTU than your Internet link.
Incoming ICMP requests is another category of messages that requires attention. Someone outside your network requesting an address mask or a timestamp may not have the best intents. You can certainly block incoming ICMP type 15,17 and 37 without impacting the users. Blocking incoming echo requests (ping) is a good thing, but may not be possible in your environment. However, check if your filtering device can at least block ICMP type 8 code !=0.
Outgoing ICMP reply corresponding to the blocked incoming ICMP request should also be blocked and an alert raised if detected. We are talking about ICMP type 16, 18 and 38.
Do not forget to limit unneeded incoming UDP traffic if you can.
Xprobe, even in its beta version is a good proof of concept tool that should help sensibilize security community about ICMP. It is also useful when you want to know more about a machine reported as Windows by nmap. Next versions of Xprobe should be smarter in presence of filtering devices.
Xprobe is released under the GNU general public licence. You can get it at : http://www.sys-security.com/html/projects/X.html
ICMP based remote OS TCP/IP stack finger printing techniques. Ofir Arkin & Fyodor Yarochkin. Phrack 57, file 7 http://www.phrack.org
ICMP usage in scanning V3.0, Ofir Arkin. 2001 http://www.sys-security.com
RFC792 INTERNET CONTROL MESSAGE PROTOCOL by Jon POSTEL, Sept 1981
The Truth About ICMP Lindsay van Eden May 17, 2001 http://www.sans.org/infosecFAQ/threats/ICMP.htm
TCP/IP Illustrated, Volume 1: The Protocols (The Addison-Wesley Professional Computing Series) by W. Richard Stevens