Precedence Bits Echoing (Fingerprinting WIN2K, Ultrix, HPUX, OpenVMS and more)

["Ofir Arkin" <ofir () itcon-ltd com>]

Background:
Each IP Datagram has an 8-bit field called the "TOS Byte",
which represents the IP support for prioritization and
Type-of-Service handling.

The "TOS Byte" consists of three fields.

The "Precedence field", which is 3-bit long, is intended to
prioritize the IP Datagram. It has eight levels of prioritization.

Higher priority traffic should be sent before lower priority
traffic.

The second field, 4 bits long, is the "Type-of-Service" field.
It is intended to describe how the network should make tradeoffs
between throughput, delay, reliability, and cost in routing an
IP Datagram.

The last field, the "MBZ" (must be zero), is unused and must be
zero. Routers and hosts ignore this last field. This field is 1
bit long.

The precedence bits behavior is a problem. RFC 1122, which defines
the requirements for Internet Hosts, does not outline the way to
handle the Precedence Bits with ICMP.

RFC 1812, Requirements for IP version 4 routers state that:

"An ICMP reply message MUST have its IP Precedence field set to the
value as the IP Precedence field in the ICMP request that provoked
the reply".

Echoing back the Precedence field value has its logic, because the TOS
field should be echoed back with an ICMP Query replies, and both the
Precedence field and the TOS field were to dictate very explicit types
of behavior with certain types of data.

As you can see we do not have a clear ruling about this issue. I was
thinking it might be a ground for an operating system fingerprinting method.


The fingerprinting method:
Most operating systems I have checked will behave as the next behavioral
example with AIX 4.3. With this example an ICMP Echo request is sent which
carries a value for the TOS field.

[root@godfather precedence_echo]# /usr/local/bin/sing -c 5 -TOS 128 y.y.y.y
SINGing to y.y.y.y (y.y.y.y): 16 data bytes
16 bytes from y.y.y.y: seq=0 ttl=239 TOS=128 time=5896.472 ms
16 bytes from y.y.y.y: seq=1 ttl=239 TOS=128 time=5952.071 ms
16 bytes from y.y.y.y: seq=2 ttl=239 TOS=128 time=6102.020 ms
16 bytes from y.y.y.y: seq=3 ttl=239 TOS=128 time=6261.997 ms
16 bytes from y.y.y.y: seq=4 ttl=239 TOS=128 time=5842.726 ms

--- y.y.y.y sing statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 5842.726/6011.057/6261.997 ms
[root@godfather precedence_echo]#

The Host queried is using the value used for the ICMP Echo Request
with its ICMP Echo Reply.

Some operating systems are the exception.

The next example is with Microsoft Windows 2000. The same ICMP Echo
Request was sent:

[root@godfather precedence_echo]# /usr/local/bin/sing -c 5 -TOS 128 y.y.y.y
SINGing to y.y.y.y (y.y.y.y): 16 data bytes
16 bytes from y.y.y.y: seq=0 ttl=111 TOS=0 time=6261.043 ms
16 bytes from y.y.y.y: seq=1 ttl=111 TOS=0 time=6422.019 ms
16 bytes from y.y.y.y: seq=2 ttl=111 TOS=0 time=6572.675 ms
16 bytes from y.y.y.y: seq=4 ttl=111 TOS=0 time=6282.022 ms

--- y.y.y.y sing statistics ---
5 packets transmitted, 4 packets received, 20% packet loss
round-trip min/avg/max = 6261.043/6384.440/6572.675 ms
[root@godfather precedence_echo]#

The ICMP Echo Reply will not use the value assigned to the Precedence Bits
with the ICMP Echo Request.

Which operating systems share this behavioral pattern?
Microsoft Windows 2000 Family, and ULTRIX.

Differentiating between Microsoft Windows 2000 and Ultrix is easily achieved
if we examine the IP TTL field value. With ULTRIX the value assigned to the
ICMP Echo reply will be 255, with Microsoft Windows 2000 it will be 128.

Another interesting case is with HPUX 11.0. Lets examine the trace and logs:

[root@godfather precedence_echo]# /usr/local/bin/sing -c 2 -TOS 128 y.y.y.y
SINGing to y.y.y.y (y.y.y.y): 16 data bytes
16 bytes from y.y.y.y: seq=0 ttl=242 TOS=128 time=639.274 ms
16 bytes from y.y.y.y: seq=1 DF! ttl=242 TOS=0 time=310.427 ms

--- y.y.y.y sing statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 310.427/474.850/639.274 ms

The first reply from the HPUX machine echoed back the TOS field value we
were
using with the ICMP Echo Request. But what have happened between the first
and the second reply?

The first request was sent, as an instant reply the HPUX 11.0 machine
started
its PMTU discovery process with ICMP Echo Requests and sent an ICMP Echo
Request
1500 bytes long.

The first ICMP Echo Reply received from the HPUX 11.0 machine for the ICMP
Echo
Request echoed back the TOS field value.

The second ICMP Echo Reply received did not echo back the TOS field value,
and set the
DF bit. The PMTU discovery process finished its initial stages and went to
regular
operation. From now on the ICMP Echo Replies did not echo the TOS field
value.

This gives us the ability to track down HPUX 11.0 (and 10.30) machines when
they
are using the PMTU Discovery process.


Changed Pattern with other ICMP Query Message Types
We can identify change of pattern with OpenVMS, Windows 98, 98SE, and ME.
With ICMP
Echo replies they all would echo back the TOS field value, but with ICMP
Timestamp
replies they will change the behavior and send back 0x000. Since OpenVMS use
255 as
its IP TTL field value, and the Microsoft Windows based machines use 128, we
can
differentiate between them and isolate OpenVMS, and the Microsoft based OSs.

Further distinction between the Microsoft operating systems can be achieved
if we will
query them with ICMP Address Mask request, which only Microsoft Windows
98/98SE will
answer for. The Microsoft Windows ME will not reply, enabling us to identify
it.

Operating systems verified against:
LINUX based on Kernel 2.2.x & 2.4Tx; FreeBSD 4.0, 4.1.1; NetBSD; OpenBSD;
Sun Solaris 2.6,2.7,2.8; HPUX 11.0; AIX 4.3,4.2.1,4.1,3.2; ULTRIX 4.2-4.5;
OpenVMS 7.1-2; Compaq Tru64 v5.6; DGUX v5.6; Microsoft Windows 98,98SE,ME,
NT4SP6a Server, 2000 Pro, 2000 Server, 2000 Advanced Server.

This post was sent to Bugtraq as well.

Ofir Arkin  [ofir () itcon-ltd com]
Senior Security Analyst
Chief of Grey Hats
ITcon, Israel.
http://www.itcon-ltd.com

Founder
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).