RFC 1349 define the usage of the Type-of-Service field in the IP Header with ICMP datagrams. It distinguishes between ICMP error messages, ICMP query messages, and ICMP reply messages. Simple rules are defined: - ICMP Error message is always sent with the default TOS (0x00) - An ICMP request message may be sent with any value in the TOS field (The RFC further specify that although ICMP request messages are normally sent with the default TOS, there are sometimes good reasons why they would sent with some other TOS values). - An ICMP reply message is sent with the same value in the TOS field as was used in the corresponding ICMP request message. Using this logic I have decided to check if certain operating systems react correctly to an ICMP Query messages with a Type-of-Service field value, which is different than the default (0x00). The check out was produced with ICMP query message types sent with a Type-of-Service field set to a known value, than set to an unknown value (the term known and unknown are used here because I was not experimenting with non-legit values, and since any value may be sent inside this field). The following example is an ICMP Echo request sent to my FreeBSD 4.0 machine. The tool used here is HPING2 beta 54. The –o option with HPING2 enable it to insert Type-of-Service values. [root@aik /root]# hping2 -1 -o 8 192.168.1.15 default routing not present HPING 192.168.1.15 (eth0 192.168.1.15): icmp mode set, 28 headers + 0 data bytes46 bytes from 192.168.1.15: icmp_seq=0 ttl=255 id=16 rtt=1.1 ms 46 bytes from 192.168.1.15: icmp_seq=1 ttl=255 id=17 rtt=0.4 ms 46 bytes from 192.168.1.15: icmp_seq=2 ttl=255 id=18 rtt=0.3 ms … --- 192.168.1.15 hping statistic --- 11 packets tramitted, 11 packets received, 0% packet loss round-trip min/avg/max = 0.3/0.4/1.1 ms Snort Trace: 08/09-21:48:37.280337 192.168.1.200 -> 192.168.1.15 ICMP TTL:64 TOS:0x8 ID:60783 ID:48899 Seq:0 ECHO 08/09-21:48:37.280928 192.168.1.15 -> 192.168.1.200 ICMP TTL:255 TOS:0x8 ID:16 ID:48899 Seq:0 ECHO REPLY 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 .. As it can be seen the TOS field value remained the same in the reply as the RFC states. Experimenting with a Hex value of 0x10 produced the same behavior. Since FreeBSD 4.0 does not respond to ICMP Information requests, or to ICMP Address Mask Requests I had to verify this behavior with ICMP Timestamp request and see if in the reply the TOS field value is the same as it is in the request - It is. Ok. I was curious again. I imagined that the Microsoft implementation of the things might be a little different. When I was examining ICMP Echo requests I noticed something is wrong with a certain Microsoft OS: [root@aik /root]# hping2 -1 -o 10 192.168.1.1 default routing not present HPING 192.168.1.1 (eth0 192.168.1.1): icmp mode set, 28 headers + 0 data bytes 46 bytes from 192.168.1.1: icmp_seq=0 ttl=128 id=74 rtt=0.9 ms 46 bytes from 192.168.1.1: icmp_seq=1 ttl=128 id=75 rtt=0.5 ms 46 bytes from 192.168.1.1: icmp_seq=2 ttl=128 id=76 rtt=0.5 ms … --- 192.168.1.1 hping statistic --- 8 packets tramitted, 8 packets received, 0% packet loss round-trip min/avg/max = 0.5/0.6/0.9 ms [root@aik /root]# Snort trace: Initializing Network Interface... Decoding Ethernet on interface eth0 -*> Snort! <*- Version 1.6 By Martin Roesch (roesch@clark.net, www.clark.net/~roesch) 08/09-21:43:53.257483 192.168.1.200 -> 192.168.1.1 ICMP TTL:64 TOS:0x10 ID:34638 ID:45571 Seq:0 ECHO 08/09-21:43:53.258294 192.168.1.1 -> 192.168.1.200 ICMP TTL:128 TOS:0x0 ID:86 ID:45571 Seq:0 ECHO REPLY 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 .. Oops! Some one zero out my Type-of-Service field! To keep the story short - Microsoft Windows 2000 family (Professional, Server, Advanced Server) all zero out the TOS field with ICMP Echo replies for ICMP Echo request with the TOS field value different than the default! Other Microsoft Windows operating systems maintain the value in their replies, as well as : Linux Kernel 2.2.x, Linux Kernel 2.4t-x, FreeBSD 4.0, OpenBSD 2.7, NetBSD 1.4.2, SUN Solaris 2.7 & 2.8, Compaq Tru64 UNIX 5.0, AIX 4.1, OpenVMS v7. Is this makes those Microsoft Windows 2000 machines identified easily and uniquely? 99.9% yes. The other 0.01 % belongs to Ultrix. Only Ultrix behaved like the Microsoft Windows 2000 machines. How can we distinguish between the two? First, there are much fewer Ultrix machines out there than Microsoft’s Windows 2000 (I see your faces – not convincing enough). Secondly, if we would send an ICMP Information request or an ICMP Address Mask request than only Ultrix would answer our request (if not filtered of course) and not the Microsoft Windows 2000 machines. Other ICMP query message types help us to identify a unique group of Microsoft operating systems. As a rule all operating systems except the named Microsoft windows operating systems here, maintain a single behavior regarding the Type-of-Service field. All would maintain the same values with different types of ICMP requests. But, again, Microsoft have some of the “top” people understanding TCP/IP to the degree we humans do not understand so we have the following Microsoft operating systems zero out (0x00) the Type-of-Service field on the replies for ICMP Timestamp requests: Microsoft Windows 98/98SE/ME. Microsoft Windows 2000 machines would zero out this field as well (maintaining its initial behavior with ICMP Echo replies). This means that Microsoft Windows 98/98SE/ME would not zero out the Type-of-Service field value with ICMP Echo requests but will do so with ICMP Timestamp requests. Here we got a way to fingerprint Microsoft Windows 2000 machines from the rest of the world and from the rest of the Microsoft Windows operating systems. P.S. This info was also posted to Bugtraq. Ofir Arkin [ofir@itcon-ltd.com] Senior Security Analyst ITcon, Israel. Homepage: http://www.sys-security.com "Opinions expressed do not necessarily represent the views of my employer." -------------------------------------------------- For help using this (nmap-hackers) mailing list, send a blank email to nmap-hackers-help@insecure.org . List run by ezmlm-idx (www.ezmlm.org).