Get a MacBook Air with Online Courses Now

Intrusion Detection FAQ: What is XProbe?

Gregory Lajon

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
:
Usage :

#x
X probe ver. 0.0.1p1
------------------
usage: x [-p portnum] [-i interface] [-v] host[/netmask]
#


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.78


X probe ver. 0.0.1p1
------------------
Interface: eth0/xxx.xxx.xxx.153

LOG: Target: xxx.xxx.xxx.78
LOG: Netmask: 255.255.255.255
LOG: probing: xxx.xxx.xxx.78
TEST: UDP to xxx.xxx.xxx.78:32132 [98 bytes] sent, waiting for reponse.
TREE: IP total length field value is >20 bytes from the original
TREE: *** AIX!BSDI!NetBSD 1.1.x-1.2.x!MacOS X 1.0-1.2
FINAL:[ AIX ]

Xprobe 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)

0x0000 4500 0062 bb62 4000 fa11 5ccd xxxx xx99 E..b.b@...\...T.
0x0010 xxxx xx4e 9a1b 7d84 004e 7f57 0000 0000 ...N..}..N.W....
0x0020 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0050 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060 0000 ..

15:28:31.353701 xxx.xxx.xxx.78 > xxx.xxx.xxx.153: icmp: xxx.xxx.xxx.78 udp port 32132 unreachable (DF)
0x0000 4500 0038 dd55 4000 fb01 3a14 xxxx xx4e E..8.U@...:....N
0x0010 xxxx xx99 0303 e4fa 0000 0000 4500 0076 ..T.........E..v
0x0020 bb62 4000 f611 60cd xxxx xx99 xxxx xx4e .b@...`...T....N
0x0030 9a1b 7d84 004e 0000 ..}..N..


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.80

probe ver. 0.0.1p1
------------------
Interface: eth0/xxx.xxx.xxx.153

LOG: Target: xxx.xxx.xxx.80
LOG: Netmask: 255.255.255.255
LOG: probing: xxx.xxx.xxx.80
TEST: UDP to xxx.xxx.xxx.80:32132 [98 bytes] sent, waiting for reponse.
TREE: IP total length field value is OK
TREE: Frag bits are OK
TEST: ICMP echo request to xxx.xxx.xxx.80 [68 bytes] sent, waiting for reponse.
TREE: Microsoft Windows Family TCP stack
TREE: Other Windows-based OS (ttl: 127)
TREE: Other Windows-based OS (98/98SE/NTsp3-/NTsp4+)
TEST: ICMP time stamp request to xxx.xxx.xxx.80 [68 bytes] sent, waiting for reponse.
Receive timeout. Quitting..
TREE: Windows NTsp3-!Windows NTsp4+
TEST: ICMP address mask request to xxx.xxx.xxx.80 [48 bytes] sent, waiting for reponse.
Receive timeout. Quitting..
FINAL:[ Windows NTsp4+ ]

Here 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)

0x0000 4500 0062 fbc0 4000 fa11 4b4b xxxx xx99 E..b..@...KK..T.
0x0010 xxxx xx50 045d 7d84 004e 43f2 0000 0000 ..UP.]}..NC.....
0x0020 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0050 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060 0000 ..
19:17:12.301800 xxx.xxx.xxx.80 > xxx.xxx.xxx.153: icmp: xxx.xxx.xxx.80 udp port 32132 unreachable
0x0000 4500 0038 8ca6 0000 7f01 75a0 xxxx xx50 E..8......u...UP
0x0010 xxxx xx99 0303 36db 0000 0000 4500 0062 ..T...6.....E..b
0x0020 fbc0 4000 f911 4c4b xxxx xx99 xxxx xx50 ..@...LK..T...UP
0x0030 045d 7d84 004e 43f2 .]}..NC.
19:17:12.303412 xxx.xxx.xxx.153 > xxx.xxx.xxx.80: icmp: echo request (DF) [tos 0x6,ECT]
0x0000 4506 0044 e223 4000 fa01 6510 xxxx xx99 E..D.#@...e...T.
0x0010 xxxx xx50 087b 13ba 8c1a 57b0 0000 0000 ..UP.{....W.....
0x0020 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040 0000 0000 ....
19:17:12.303957 xxx.xxx.xxx.80 > xxx.xxx.xxx.153: icmp: echo reply (DF) [tos 0x6,ECT]
0x0000 4506 0044 8da6 4000 7f01 348e xxxx xx50 E..D..@...4...UP
0x0010 xxxx xx99 0000 1c35 8c1a 57b0 0000 0000 ..T....5..W.....
0x0020 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040 0000 0000 ....
19:17:12.305876 xxx.xxx.xxx.153 > xxx.xxx.xxx.80: icmp: time stamp query id 32242 seq 37077
0x0000 4500 0044 09bd 0000 fa01 7d7d xxxx xx99 E..D......}}..T.
0x0010 xxxx xx50 0d7b e3bc 7df2 90d5 0000 0000 ..UP.{..}.......
0x0020 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040 0000 0000 ....
19:17:22.302686 xxx.xxx.xxx.153 > xxx.xxx.xxx.80: icmp: address mask request
0x0000 4500 0030 7f19 0000 fa01 0835 xxxx xx99 E..0.......5..T.
0x0010 xxxx xx50 1100 3873 0000 b68c 0000 0000 ..UP..8s........
0x0020 0000 0000 0000 0000 0000 0000 0000 0000 ................

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.

Countermeasures

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.

Firewall countermeasures:
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.

Conclusion
:
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.

References
:
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