fingerprinting-detect remote operating system

In this post we will try to analyze and study one of the first initial steps taken by an intruder to gain access to a network. We will see its implications & how to prevent the intruder from collecting such information.

We will be discussing Fingerprinting in this post. Operating system finger printing and network scanning is generally the first step taken by most of the intruder to gain access. The more information the intruder, has about your network, the more easy it becomes for them to achieve a successful break-in.

The techniques that we discuss here can also be used to do penetration testing on your network. This post is going to be pretty big, as we will be discussing various tools and techniques. So i have decided to make this topic divided in two parts. In this post we will be concentrating more on Operating System fingerprinting techniques, and on our second part of this post we will be discussing application fingerprinting.

What is OS Fingerprinting?

Most of the computer security people out there, are already aware of the term, in fact it has become a cliche for them. There are many operating system's out there in the market, and all of them are made by different team of programmer's. And each one is slightly different from the other, in the way they respond to a service or network request.

But smart people can make use of this difference, as a way to identify the remote operating system. A relatively accurate guess can be made about the operating system, based on the way a machine replies to a network packet.

fingerprinting one's own network can be useful in maintaining a good updated inventory details of machine's on your network. But to an intruder, these kind of information, can help identifying the role of a particular machine in the network.

TCP/IP is the protocol that the internet relies heavily on. All the communication on the internet is done using this protocol suite. This makes it very much necessary for an operating system to implement it, for communication with other machine's flawlessly. IP is used to assign logical address to machine's on the network, and TCP is used to transfer IP packets in an acknowledged fashion.

So let me repeat that line once more "Every operating system needs to implement TCP/IP, if it wants to communicate with other machines(which also implement TCP/IP)".

But the main problem is that, some filed's inside the protocol suite, are left to the developer to select the appropriate value for them, and their applications. which makes, operating system's method of responding to ip packets slightly different from each other(because, different operating system's are made by different developer teams).

An IP packet header looks like below. Note the TTL field, which i have marked as red in the pic.

What is TTL in an IP packet?

This value inside an ip packet, indicates the maximum time a packet can be alive on the internet. Confused? . Don't worry i will explain it.

TTL is a value set by the computer or the device that sends an IP packet, every router that comes in between the packet and its destination will reduce the value by 1. So if a packet has traveled too long, overcoming too many hops(router machine's in between), and the TTL value becomes zero(because it got reduced by 1 at all hops in between), then that packet is discarded.

Its a nice thing to have. Because otherwise there will be too many junk packets, traveling from router to router endlessly

TTL is an 8 bit field in an IP packet. the maximum value can be 255. But the people who control's the IP protocol(IETF), have not set an initial value for TTL(which is a very nice thing, because developer's can develop their application according to their required TTL value). As different operating system's are made by different people, most of them have different default initial TTL values.

Got it??? So this TTL information can also tell me, what the remote operating system is..

For doing some practial, we will try to ping one windows 7 machine, and lets see its TTL value. I will try to ping my own windows 7 machine from the machine itself.

C:\Users\sarath>ping 172.16.134.85
Pinging 172.16.134.85 with 32 bytes of data:
Reply from 172.16.134.85: bytes=32 time<1ms TTL=128
Reply from 172.16.134.85: bytes=32 time<1ms TTL=128
Reply from 172.16.134.85: bytes=32 time<1ms TTL=128
Reply from 172.16.134.85: bytes=32 time<1ms TTL=128
Ping statistics for 172.16.134.85:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

From the above shown example of ping you can easily see the TTL value, its 128. That's the default TTL value for XP and Windows 7. In the above example we can see the default 128 because there no hop in between me and the machine i pinged(because i was on that machine and pinged itself).

Now lets ping that same windows 7 machine from another machine, which is one hop away, and see what happens to the TTL value.

[root@myvm1 ~]# tracert 172.16.134.85
traceroute to 172.16.134.85 (172.16.134.85), 30 hops max, 40 byte packets
1  172.16.140.1 (172.16.140.1)  0.306 ms  0.304 ms  0.306 ms
2  172.16.134.85 (172.16.134.85)  0.532 ms  0.533 ms  0.533 ms
[root@myvm1 ~]# ping 172.16.134.85
PING 172.16.134.85 (172.16.134.85) 56(84) bytes of data.
64 bytes from 172.16.134.85: icmp_seq=1 ttl=127 time=0.578 ms
64 bytes from 172.16.134.85: icmp_seq=2 ttl=127 time=0.604 ms
64 bytes from 172.16.134.85: icmp_seq=3 ttl=127 time=0.538 ms
--- 172.16.134.85 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.538/0.573/0.604/0.033 ms

As you can clearly see, i tracerouted the trarget machine, to count the hops in between, and its clear from the TTL value shown in ping, that the hop in between, reduced TTL from 128 to 127.
 

So now you can make a good guess that the target machine is either windows XP or Windows 7
Linux machine's takes 64 as the default TTL value. In the same manner we saw for windows, you can also guess whether the remote machine is a Linux Distro or not.

Fingerprinting using scanners

Scanners or tools that can be used to do fingerprinting comes in two types.

1. Active scanners
2. Passive scanners

Active scanners can be used to probe a remote machine by actively sending packets or requests to it, and then analyzing the reply.

Passive scanners are the ones that analyzes previously captured communication packet between the target hosts and other machines.

nmap is a popular tool that's used for fingerprinting and port scanning large number of hosts at one time. nmap was not primarily built, for os fingerprinting, but later on it included a module which can detect the remote operating systems.

nmap os fingerprinting works on the concept of sending multiple udp and tcp packets to the target hosts, and then analyzing the reply.During the OS scan using nmap tool, the tool will send requests to both open and closed ports to analyze the reply method. However nmap does not show any of these details when a user asks it to probe a remote host.

I will be doing a dedicated post on how nmap works and detects remote operating system, coz explaining that in this post will take us away from the subject, because that includes a lot of tcp concepts like window,initial sequence number, etc.

[root@localhost ~]# nmap -sV -O 172.16.134.85                                  
Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2012-12-30 23:56 IST
Interesting ports on 172.16.134.85:
Not shown: 1674 closed ports
PORT     STATE SERVICE      VERSION
135/tcp  open  msrpc        Microsoft Windows RPC
139/tcp  open  netbios-ssn
445/tcp  open  netbios-ssn
1110/tcp open  nfsd-status?
5800/tcp open  vnc-http?
5900/tcp open  vnc          VNC (protocol 3.8)
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :
:V=4.11%I=7%D=12/30%Time=50E08775%P=i686-redhat-linux-gnu%r
MAC Address: 44:37:E6:72:23:56 (Unknown)
No exact OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=4.11%P=i686-redhat-linux-gnu%D=12/30%Tm=50E087CE%O=135%C=1%M=4437E6)
(Class=TR%IPID=I%TS=100HZ)
Uptime 0.086 days (since Sun Dec 30 21:55:21 2012)
Service Info: OS: Windows
Nmap finished: 1 IP address (1 host up) scanned in 96.270 seconds

Now from the above example shown you can clearly see that nmap detected the remote operating system and is saying that its Windows.As i told we will disucss working of nmap and its uses in a detailed dedicated post.

Operating system detection using xprobe2

You can detect the remote operating system, by also using xprobe2. You can download and install the tool from epel,rpmforge repo.

[root@localhost ~]# xprobe2 172.16.101.12
Xprobe2 v.0.3 Copyright (c) 2002-2005 fyodor@o0o.nu, ofir@sys-security.com, meder@o0o.nu
[+] Target is 172.16.101.12
[+] Loading modules.
[+] Following modules are loaded:
[x] [1] ping:icmp_ping  -  ICMP echo discovery module
[x] [2] ping:tcp_ping  -  TCP-based ping discovery module
[x] [3] ping:udp_ping  -  UDP-based ping discovery module
[x] [4] infogather:ttl_calc  -  TCP and UDP based TTL distance calculation
[x] [5] infogather:portscan  -  TCP and UDP PortScanner
[x] [6] fingerprint:icmp_echo  -  ICMP Echo request fingerprinting module
[x] [7] fingerprint:icmp_tstamp  -  ICMP Timestamp request fingerprinting module
[x] [8] fingerprint:icmp_amask  -  ICMP Address mask request fingerprinting module
[x] [9] fingerprint:icmp_port_unreach  -  ICMP port unreachable fingerprinting module
[x] [10] fingerprint:tcp_hshake  -  TCP Handshake fingerprinting module
[x] [11] fingerprint:tcp_rst  -  TCP RST fingerprinting module
[x] [12] fingerprint:smb  -  SMB fingerprinting module
[x] [13] fingerprint:snmp  -  SNMPv2c fingerprinting module
[+] 13 modules registered
[+] Initializing scan engine
[+] Running scan engine
[-] ping:tcp_ping module: no closed/open TCP ports known on 172.16.101.12. Module test failed
[-] ping:udp_ping module: no closed/open UDP ports known on 172.16.101.12. Module test failed
[-] No distance calculation. 172.16.101.12 appears to be dead or no ports known
[+] Host: 172.16.101.12 is up (Guess probability: 50%)
[+] Target: 172.16.101.12 is alive. Round-Trip Time: 0.00060 sec
[+] Selected safe Round-Trip Time value is: 0.00119 sec
[-] fingerprint:tcp_hshake Module execution aborted (no open TCP ports known)
[-] fingerprint:smb need either TCP port 139 or 445 to run
[-] fingerprint:snmp: need UDP port 161 open
[+] Primary guess:
[+] Host 172.16.101.12 Running OS: "Linux Kernel 2.4.22" (Guess probability: 100%)
[+] Other guesses:
[+] Host 172.16.101.12 Running OS: "Linux Kernel 2.4.23" (Guess probability: 100%)
[+] Host 172.16.101.12 Running OS: "Linux Kernel 2.4.21" (Guess probability: 100%)
[+] Host 172.16.101.12 Running OS: "Linux Kernel 2.4.20" (Guess probability: 100%)
[+] Host 172.16.101.12 Running OS: "Linux Kernel 2.4.19" (Guess probability: 100%)
[+] Host 172.16.101.12 Running OS: "Linux Kernel 2.4.24" (Guess probability: 100%)
[+] Host 172.16.101.12 Running OS: "Linux Kernel 2.4.25" (Guess probability: 100%)
[+] Host 172.16.101.12 Running OS: "Linux Kernel 2.4.26" (Guess probability: 100%)
[+] Host 172.16.101.12 Running OS: "Linux Kernel 2.4.27" (Guess probability: 100%)
[+] Host 172.16.101.12 Running OS: "Linux Kernel 2.4.28" (Guess probability: 100%)
[+] Cleaning up scan engine
[+] Modules deinitialized
[+] Execution completed.

An important thing to note here is that, by default xprobe2 will give you a very high verbose output as shown above, and it will also show the modules it loaded for the probe. xprobe2 was made for icmp protocol scan's for os detections however it does include some tcp checks also.

TCP scan's are pretty easy to detect for IDS system's. Hence using only the icmp modules avaialbe in xprobe2 is pretty nice for remaining stealth.

Lets only use modules 1,4 & 6 because it only uses ICMP, for the probe, which are as shown below(you can cleary see the modules from our previous xprobe scan). Lets see how to mention the module options in xprobe2.

[root@localhost ~]# xprobe2 -M 1 -M 4 -M 6 172.16.140.41

You can also use a passive OS fingerprinting tool called p0f to determine the operating system by simply analyzing the already captured traffic pcap file

You can simply pass the pcap file name as an argument to p0f tool, to process.