Bugtraq mailing list archives

Using the TOS Byte's Unused Bit (Fingerprinting WIN2K, ULTRIX and more)


From: Ofir Arkin <ofir () ITCON-LTD COM>
Date: Fri, 17 Nov 2000 16:37:04 +0200

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.

RFC 1349 states that the last field of the TOS byte, the "MBZ"
(must be zero), is unused and must be zero. The RFC also states
that routers and hosts ignore the value of this bit.

This is the only statement about the unused bit in the TOS Byte
in the RFCs. The RFC states: "The originator of a datagram sets
this field to Zero".

Obviously it was meant that this field would be always zero. But
what will happen if we would set this bit with our ICMP Echo
Requests? Will this bit be zero out on reply or will it be echoed back?

The Method:
Only with ICMP Echo requests we can have a clear identification of OSs.

The next example is an ICMP Echo Request sent with the TOS bit in
the TOS Byte set, targeting a FreeBSD 4.1.1 machine:

[root@godfather /root]# /usr/local/bin/sing  -c 2 -TOS 1 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=233 TOS=1 time=330.461 ms
16 bytes from y.y.y.y: seq=1 ttl=233 TOS=1 time=723.300 ms

--- y.y.y.y sing statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 330.461/526.880/723.300 ms
[root@godfather /root]#

Echoing back the Unused bit in the TOS Byte represents the behavior of
most of the operating systems I have checked this method against.

Which operating systems are the exceptions?
The next example is with Microsoft Windows 2000 Pro as the targeted
machine:

[root@godfather precedence_echo]# /usr/local/bin/sing -c 2 -TOS 1 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=299.188 ms
16 bytes from y.y.y.y: seq=1 ttl=111 TOS=0 time=280.321 ms

--- y.y.y.y sing statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 280.321/289.755/299.188 ms
[root@godfather precedence_echo]#

The tcpdump trace:

00:17:01.765492 ppp0 > x.x.x.x > y.y.y.y: icmp: echo request [tos 0x1]  (ttl
255, id 13170)
                         4501 0024 3372 0000 ff01 d82b xxxx xxxx
                         yyyy yyyy 0800 f015 7a3c 0000 5dc5 0d3a
                         17ae 0b00

00:17:02.064284 ppp0 < y.y.y.y > x.x.x.x: icmp: echo reply (ttl 111, id
29961)
                         4500 0024 7509 0000 6f01 2696 yyyy yyyy
                         xxxx xxxx 0000 f815 7a3c 0000 5dc5 0d3a
                         17ae 0b00

Another OS that behaves the same is ULTRIX:

[root@godfather precedence_echo]# /usr/local/bin/sing -c 2 -TOS 1 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=237 TOS=0 time=371.776 ms

--- y.y.y.y sing statistics ---
2 packets transmitted, 1 packets received, 50% packet loss
round-trip min/avg/max = 371.776/371.776/371.776 ms
[root@godfather precedence_echo]#

We will use, again, the IP TTL field value to differentiate
between the two operating systems.


Changed Pattern with Replies for Different ICMP Query Types:
We have a changed pattern with Microsoft Windows 98/98SE/ME when
using other ICMP Query message types other than ICMP Echo Request.
Instead of echoing this field back, they will zero out this field
with their replies.

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.

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


Current thread: