COMMAND
kernel
SYSTEMS AFFECTED
Win32
PROBLEM
Ofir Arkin found following. RFC 791 gives a description about
the IP Identification field.
The identification field value is used to uniquely identify the
fragments of a particular datagram. Fragments of a particular
datagram are assembled if they have the same source, destination,
protocol, and Identifier. The identifier is being chosen to be
unique for this "this source, destination pair and protocol for
the time the datagram (or any fragment of it) could be alive in
the internet" (http://www.ietf.org/rfc/rfc0791.txt).
The IP identifier field can have 65,536 different values. It is
important for an operating system to have some sort of a mechanism
in order to control the identification numbers correctly.
Since every operating system should have its own mechanism in
order to deal with this field numbering we might find some
patterns different from one operating system to another.
The Gap between one IP ID field value to the next. With the
implementation in many operating systems, the Kernel is increasing
the IP ID field value by 1, from one packet to the next.
However, there are operating systems that will increase the value
of the IP ID field value with a value different than 1, from one
packet to the next.
In the next example we have sent two ICMP Echo requests from a
Windows NT 4 Server with SP6a based machine targeting a LINUX
machine based on Kernel 2.2.14:
08/10-16:55:06.638539 10.0.0.117 -> 10.0.0.105
ICMP TTL:32 TOS:0x0 ID:28416
ID:256 Seq:768 ECHO
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 abcdefghijklmnop
71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 qrstuvwabcdefghi
08/10-16:55:06.638592 10.0.0.105 -> 10.0.0.117
ICMP TTL:255 TOS:0x0 ID:1452
ID:256 Seq:768 ECHO REPLY
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 abcdefghijklmnop
71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 qrstuvwabcdefghi
08/10-16:55:07.639784 10.0.0.117 -> 10.0.0.105
ICMP TTL:32 TOS:0x0 ID:28672
ID:256 Seq:1024 ECHO
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 abcdefghijklmnop
71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 qrstuvwabcdefghi
08/10-16:55:07.639841 10.0.0.105 -> 10.0.0.117
ICMP TTL:255 TOS:0x0 ID:1453
ID:256 Seq:1024 ECHO REPLY
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 abcdefghijklmnop
71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 qrstuvwabcdefghi
The first ICMP Echo request sent from the Microsoft NT 4 based
machine was sent with IP ID of 28416. The second ICMP Echo
request was sent with IP ID value of 28672. Simple calculation
will show a gap of 256 between the IP ID field values.
Looking at the replies the LINUX based machine produced, we see a
gap of 1 between one IP ID to the next.
Other OSs that act the same. The other operating systems that
act the same are the older Microsoft based operating systems.
They include – Windows 95, Windows 98, Windows 98 SE, Windows NT
4 family (regardless of the Service Pack installed).
With newer versions of their operating systems (MS Windows ME, MS
Windows 2000 family), Microsoft has changed this behavior, and
now acts as most operating systems do.
We can use this information as another parameter for Active OS
fingerprinting and for Passive OS fingerprinting. One example
might be when we need another parameter to differentiate between
a Windows NT 4 based machine to a Windows 2000 based machine.
In the real world when we wish to use this information for
fingerprinting operating systems we will see something a bit
different that we should be aware of. Since the machines we try
to fingerprint are hosts available on the Internet they might
communicate with other hosts on the Internet while we query them.
Therefore the gap we will have from one IP ID to the next might
be higher than 256 (in the older MS based OSs case). With the
older implementations of Microsoft based operating systems
identifying these OSs is quite simple. We will extract the first
IP ID from the second IP ID and divide the result with 256. The
result should be a complete number.
With the operating systems that use a gap of 1 between one IP ID
field number to the next, we might have a gap a bit higher than 1,
usually between 2-8 (but it can be more than that as well).
In the next example a Microsoft ME based machine sent two ICMP
Echo requests targeting a LINUX based on kernel 2.2.14 machine.
The gap between the first IP ID field value to the next is 5 with
the LINUX machine:
08/10-16:49:45.633417 10.0.0.117 -> 10.0.0.105
ICMP TTL:32 TOS:0x0 ID:134
ID:768 Seq:256 ECHO
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 abcdefghijklmnop
71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 qrstuvwabcdefghi
08/10-16:49:45.633465 10.0.0.105 -> 10.0.0.117
ICMP TTL:255 TOS:0x0 ID:810
ID:768 Seq:256 ECHO REPLY
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 abcdefghijklmnop
71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 qrstuvwabcdefghi
08/10-16:49:46.635971 10.0.0.117 -> 10.0.0.105
ICMP TTL:32 TOS:0x0 ID:135
ID:768 Seq:512 ECHO
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 abcdefghijklmnop
71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 qrstuvwabcdefghi
08/10-16:49:46.636018 10.0.0.105 -> 10.0.0.117
ICMP TTL:255 TOS:0x0 ID:815
ID:768 Seq:512 ECHO REPLY
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 abcdefghijklmnop
71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 qrstuvwabcdefghi
There is something much more interesting about non-random
incrementing IP ID numbers: you can use such operating systems to
execute spoofed TCP port scans. Aaron Campbell has explained this
technique (originally described on Bugtraq over 2 years ago).
Imagine three hosts:
Host A - Attacker.
Host B - Idle machine, OS that increments IP IDs by fixed
amount each pkt.
Host C - Victim.
Suppose Host A would like to know if port 22 is listening on Host
C.
Host A communicates initially with Host B to determine Host B's
current IP ID number and takes note of it. Host A sends a TCP
SYN packet to port 22 of Host C with the src address field
spoofed as Host B. If the port is open, Host C sends a SYN/ACK
packet to Host B in response. If the port is closed, an RST is
sent back instead. In the case of the open port, Host B would
respond to the SYN/ACK with an RST. In the case of the closed
port, Host B would ignore the RST and perform no action.
Once this is done, Host A communicates once again with Host B to
determine the current IP ID and compares it with the saved one
from before. If port 22 was open on Host C, Host B responded with
an RST, increasing its IP ID by one. If it was closed, Host B
responded with nothing and the IP ID did not change. Therefore,
in the case where "fixed amount" = 1, the IP ID has increased by
2 if the port was open or 1 if it was closed.
SOLUTION
Newer OS versions changed the behaviour.