Did
you know that you can find out which operating system a networked device is
running just by looking at the way it communicates on the network? Let’s take a
look at how we can discover what operating system our devices are running.
Why Would You Do This?
Determining
what OS a machine or device is running can be useful for many reasons. First
lets take a look at an everyday perspective, imagine you want to switch to a
new ISP who offers uncapped internet for $50 a month so you take a trial of
their service. By using OS fingerprinting you will soon discover that they have
rubbish routers and offer a PPPoE service offered on a bunch of Windows Server
2003 machines. Doesn’t sound like such a good deal anymore, huh?
Another
use for this, albeit not so ethical, is the fact that security holes are OS
specific. For example, you do a port scan and find port 53 open and the machine
is running an outdated and vulnerable version of Bind, you have a SINGLE chance
to exploit the security hole since a failed attempt would crash the daemon.
How Does OS Fingerprinting Work?
When
doing passive analysis of current traffic or even looking at old packet
captures, one of the easiest, effective, ways of doing OS Fingerprinting is by
simply looking at the TCP window size and Time To Live (TTL) in the IP header
of the first packet in a TCP session.
Here
are the values for the more popular operating systems:
Operating System
|
Time To Live
|
TCP Window Size
|
Linux (Kernel 2.4 and 2.6)
|
64
|
5840
|
Google Linux
|
64
|
5720
|
FreeBSD
|
64
|
65535
|
Windows XP
|
128
|
65535
|
Windows Vista and 7 (Server 2008)
|
128
|
8192
|
iOS 12.4 (Cisco Routers)
|
255
|
4128
|
The
main reason that the operating systems have different values is due to the
fact that the RFC’s for TCP/IP don’t stipulate default values. Other
important thing to remember is that the TTL value will not always match up to
one in the table, even if your device is running one of the listed operating
systems, you see when you send an IP packet across the network the sending
device’s operating system sets the TTL to the default TTL for that OS, but as
the packet traverses routers the TTL is lowered by 1. Therefore, if you see a
TTL of 117 this can be expected to be a packet that was sent with a TTL of 128
and has traversed 11 routers before being captured.
Using
tshark.exe is the easiest way to see the values so once you have got a packet
capture, make sure you have Wireshark installed, then navigate to:
C:\Program
Files\
Now
hold the shift button and right-click on the wireshark folder and select open
command window here from the context menu
Now
type:
tshark -r
"C:\Users\Taylor Gibb\Desktop\blah.pcap" "tcp.flags.syn eq
1" -T fields -e ip.src -e ip.ttl -e tcp.window_size
Make
sure to replace “C:\Users\Taylor Gibb\Desktop\blah.pcap” with the absolute path
to your packet capture. Once you hit enter you will be shown all the SYN
packets from your capture an easier to read table format
Now
this is a random packet capture I made of me connecting to the How-To Geek
Website, amongst all the other chatter Windows is doing I can tell you two
things for sure:
- My local network is 192.168.0.0/24
- I am on a Windows 7 box
If
you look at the first line of the table you will see I am not lying, my IP
address is 192.168.0.84 my TTL is 128 and my TCP Window Size is 8192, which
matches up to the values for Windows 7.
The
next thing I see is a 74.125.233.24 address with a TTL of 44 and a TCP Window
Size of 5720, if I look at my table there is no OS with a TTL of 44, however it
does say that the Linux that Google’s servers run have a TCP Window Size
5720. After doing a quick web search of the IP address you will see that
it is in fact a Google Server.
