Erik Hjelmvik
,
Saturday, 05 November 2011 14:45:00 (UTC/GMT)
Network traffic from a computer can be analyzed to detect what operating system it is running.
This is to a large extent due to differences in how the TCP/IP stack is implemented in various operating systems.
We will in this blog post explain the different methods that can be used to identify what operating a computer is running
by analyzing the packets it generates on the network.
Active approaches
The popular port scanner Nmap can identify the operating system (OS) of a remote computer
by sending six packets with specially crafted option combinations in the TCP layer
(for example window scale, NOP and EOL options).
Nmap then watches how the scanned host responds to these odd packets.
Fyodor (author of Nmap) gives a good overview of these techniques in
issue 54 of phrack magazine from way back in 1998.
Passive OS identification
Active measures, like those employed by Nmap,
are unfortunately not available when doing passive analysis of live traffic or when analyzing previously captured network traffic.
Passive analysis requires much more subtle variations in the network traffic to be observed, in order to identify a computer's OS.
A simple but effective passive method is to inspect the initial Time To Live (TTL) in the IP header and the TCP window size
(the size of the receive window) of the first packet in a TCP session, i.e. the SYN or SYN+ACK packet.
Below are some typical initial TTL values and window sizes of common operating systems:
Operating System (OS) | IP Initial TTL | TCP window size |
---|
Linux (kernel 2.4 and 2.6) | 64 | 5840 |
Google's customized Linux | 64 | 5720 |
FreeBSD | 64 | 65535 |
Windows XP | 128 | 65535 |
Windows 7, Vista and Server 2008 | 128 | 8192 |
Cisco Router (IOS 12.4) | 255 | 4128 |
One reason for why the TTL and window size values varies between different OS's is because the RFC's for
TCP and IP do not
require implementations to use any particular default value for these fields.
There is, however, a recommendation in RFC 1700 saying:
The current recommended default time to live (TTL) for the Internet Protocol (IP) is 64
This recommendation is obviously not followed in many IP implementations.
The initial TTL value is often a bit tricky to analyze since the TTL value of a sniffed packet will vary depending on where you sniff it from.
The sending host will set the TTL value to the OS's default TTL value,
but this value will then be decremented by one for every router the packet passes on its way to the destination IP address.
An observed IP packet with a TTL value of 57 can therefore be expected to be a packet with an initial TTL of 64
that has done 7 router hops before it was sniffed.
The TTL and window size table above can be used in order to do manual OS fingerprinting of network traffic.
Here is an example showing how to display relevant fields of the first few packets from the
publicly available pcap file
for the 2009-M57-Patents scenario with tshark:
$ tshark -r day12-1.dmp -R "tcp.flags.syn eq 1" -T fields -e ip.src -e ip.ttl -e tcp.window_size -c 16 | sort -u
192.168.1.105 128 8192
192.168.1.106 128 65535
74.125.19.139 54 5720
87.106.12.47 45 5840
87.106.12.77 45 5840
87.106.13.61 45 5840
87.106.13.62 45 5840
87.106.1.47 45 5840
87.106.1.89 45 5840
87.106.66.233 45 5840
The first column here is the IP address (ip.src), the second is the TTL (ip.ttl) and the third the TCP window size (tcp.window_size).
Note that the TTL value is only at the initial value for the hosts on the local network (192.168.1.0/24),
while the packets from the other hosts seem to have performed 10 or 19 router hops.
We can, just by matching the TTL and window sizes of these hosts with the table above, easily determine that 192.168.1.106
is running Windows XP (TTL=128, window_size=65535) and 192.168.1.105 is running some more modern flavor of Windows (TTL=128, window_size=8192).
The google machine (with IP 74.125.19.139) can also easily be singled out due to its characteristic window size of 5720.
The other machines (87.106.x.x) all seem to be running Linux.
Do you feel manual OS classification would take too much time?
There are, luckily, multiple tools like ettercap,
p0f, Satori and
NetworkMiner which all automate the OS identification task.
Just feed these tools with some live network traffic or a pcap file and they'll fingerprint the OS's for you.
DHCP Fingerprinting
An alternative to fingerprinting the TCP/IP stack implementation of an OS is to look at its DHCP implementation.
Eric Kollmann (the creator of Satori) has written a great paper on DHCP fingerprinting titled
Chatter on the Wire: A look at DHCP traffic.
Eric's DHCP fingerprinting database is used in his tool Satori as well as in
NetworkMiner.
There is also a project titled Fingerbank,
which maintains another DHCP fingerprinting database.
Application Layer
Even more info about the operating system of a host can be extracted by inspecting the application layer data in traffic,
such as server banners in HTTP, SSH and FTP as well as HTTP client User-Agent strings.
All these layer 7 banner types are displayed in NetworkMiner's Hosts tab under the “Host Details” node.
A User-Agent string showing “Windows NT 5.1” (like in the screen shot above) means that the client is running Windows XP.
Microsoft provides an article titled Understanding User-Agent Strings,
which provides this mapping between User-Agent strings and operating system:
Platform token | Description |
---|
Windows NT 6.1 | Windows 7 |
Windows NT 6.0 | Windows Vista |
Windows NT 5.2 | Windows Server 2003; Windows XP x64 Edition |
Windows NT 5.1 | Windows XP |
Happy fingerprinting!
Posted by Erik Hjelmvik on Saturday, 05 November 2011 14:45:00 (UTC/GMT)
Tags: #Satori
#NetworkMiner