As the number of devices that need to be fingerprinted continues to grow, so does the need for accurate and reliable fingerprinting techniques. One such technique is OS fingerprinting, which uses the time-to-live (TTL) and TCP window size values of a connection to identify a remote device. In this article, we will discuss how OS fingerprinting works and how it can be used to identify devices on a network. We will also provide some tips on how to improve the accuracy of this technique. ..
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:
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:
Now hold the shift button and right-click on the wireshark folder and select open command window here from the context menu
Now type:
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.
What else do you use tshark.exe for, tell us in the comments.
