OS FingerprintingFor Fun and Profit

Christopher Soghoian

JHU Information Security Institute

December 8 2003

What is OS Fingerprinting

OS Fingerprinting is a method of detecting the remote host’s operating system using information leaked by that host’s TCP stack. To do this, we use:

the responses it gives to carefully crafted packets (active mode)

or by observing captured network traffic (passive mode).

These methods are possible because each OS implements their TCP stack differently.

OS Fingerprinting (ab)uses these differences.

Why is this useful?

Learning remote OS versions can be an extremely valuable network reconnaissance tool, since many security holes are dependent on OS version.

Why is this useful – an example

Lets say you are doing a penetration test and find port 53 open. If this is a vulnerable version of Bind, you only have one shot to exploit it since a failed attempt is likely to crash the daemon.

Remember that an attack usually involves a buffer overflow, followed by the execution of OS/architecture dependent shellcode.

With a good TCP/IP fingerprinter, you will quickly find that this machine is running 'Solaris 2.51' or 'Linux 2.0.35' and can adjust your shellcode accordingly.

Uses – another example

Another possible use is for social engineering. Lets say that you are scanning your target company and the scanner reports a 'Datavoice TxPORT PRISM 3000 T1 CSU/DSU 6.22/2.06'. The hacker might now call up the target pretending to be 'Datavoice support' and discuss some issues about their PRISM 3000. "We are going to announce a security hole soon, but first we want all our current customers to install the patch -- I just mailed it to you ..."

Uses – last example

Evil Cable/DSL companies like to charge customers based on the number of hosts in their home, not based on the bandwidth given.

Using passive OS fingerprinting, if they observe two different operating systems, or two different versions of windows sending traffic from the same IP, they can assume you are running NAT, and fine you for violating their Terms of Service.

OS TCP stack implementation differences

Differences between OSes

While many Operating Systems out there base their TCP stack on the old BSD release, there have been so many changes made that there are now pretty significant differences between all of the main Operating Systems.

Differences between OS versions

As critical bugs come out, vendors issue patches to their TCP stacks.

Vendors tweak the stacks between releases, usually to improve them.

A paper by Michal Zalewski in 2001 Studied, and graphed the randomness of

Initial Sequence Numbers of various operating systems.

Graphs the output of 100,000 ISNs for each OS.

Attempts an ISN attack on each OS, and lists the difficulty for each.

Final Verdict: OpenBSD is great, Linux is pretty good.

Others have big problems.

“Strange Attractors and TCP/IP Sequence Number Analysis”

ISN Graph of: Linux 2.2

ISN Graph of: OpenBSD 2.8

ISN Graph of: OpenBSD 2.9rewritten by Niels Provos

ISN Graph of: Solaris, weak mode

ISN Graph of: Solaris,strong mode

ISN Graph of: Windows 95

ISN Graph of: Windows 98SE

ISN Graph of: Windows 2000

OS Fingerprinting….

Active OS Fingerprinting(old school)

babylon~> telnet hpux.u-aizu.ac.jpTrying 163.143.103.12 ... Connected to hpux.u-aizu.ac.jp.Escape character is '^]'.

HP-UX hpux B.10.01 A 9000/715 (ttyp2)

login:

Active OS Fingerprinting(old school, a bit more advanced)

babylon> telnet ftp.netscape.com 21Trying 207.200.74.26 ...Connected to ftp.netscape.com.Escape character is '^]'.220 ftp29 FTP server ready.SYST215 UNIX Type: L8 Version: SUNOS

Active OS Fingerprinting(old school, last example)

babylon> echo 'GET / HTTP/1.0\n' | nc hotbot.com 80 | egrep '^Server:‘

Server: Microsoft-IIS/4.0babylon>

Here, we send a HTTP GET request to a remote server, and observe the webserver software which is identified in the response.

Downsides to the old school method

Sys admins usually turn the login banner OS announce off.

Applications can be configured to lie. What we really need is a solution that

doesn’t depend upon the honesty of the application.

Enter: New School Active OS Fingerprinting

New school active Fingerprinting

Pioneered by Queso, a now defunct tool, and improved upon by the widely popular nmap.

Described by Nmap’s author, Fyodor, in his paper “Remote OS detection via TCP/IP Stack FingerPrinting”, October 18, 1998

http://www.insecure.org/nmap/nmap-fingerprinting-article.html

Fyodor’s fingerprint method His basic idea was to send a specially

crafted packet, usually with an invalid/strange set of options (which is where OS vendors usually differ in implementation), and see what happens.

He uses several methods, none of which individually identify the remote OS, but combined together will give you a good idea.

These methods include:

Methods used by Nmap

The FIN probe -- Send a FIN packet (or any packet without an ACK or SYN flag) to an open port and wait for a response. The correct RFC 793 behavior is to NOT respond, but many broken implementations such as MS Windows, BSDI, CISCO, and IRIX send a RESET back.

Methods used by Nmap

IPID sampling -- Most operating systems increment a system-wide IPID value for each packet they send. Others, such as OpenBSD, use a random IPID and some systems (like Linux) use an IPID of 0 in many cases where the "Don't Fragment" bit is not set. Windows does not put the IPID in network byte order, so it increments by 256 for each packet.

Remember that it was the predictability of the IPID field which Bellovin used in his paper “A technique for counting NATted hosts”.

Methods used by Nmap

TCP Initial Window -- This simply involves checking the window size on returned packets. This test actually gives us a lot of information, since some operating systems can be uniquely identified by the window alone

AIX is the only OS which uses 0x3F25 In their "completely rewritten" TCP stack for

NT5, Microsoft uses 0x402E. Interestingly, that is exactly the number used

by OpenBSD and FreeBSD.

Methods used by nmap TCP Options -- These are truly a gold mine in terms

of leaking information. The beauty of these options is that:

1. You know if a host implements them by: sending a query with a bunch of options set. For all of the options which the server sets in its reply, it is fair to assume that they are supported.

2. You can stuff a whole bunch of options on one packet to test everything at once.

Nmap sends these options along with almost every probe packet: Window Scale=10; NOP; Max Segment Size = 265; Timestamp; End of Ops;

Nmap – TCP options (continued)

Even if several operating systems support the same set of options, you can sometimes distinguish them by the values of the options. For example, if you send a small MSS value to a Linux box, it will generally echo that MSS back to you. Other hosts will give you different values.

Nmap – TCP options (continued)

And even if you get the same set of supported options AND the same values, you can still differentiate via the order that the options are given, and where padding is applied.

For example Solaris returns 'NNTNWME' which means: <no op><no op><timestamp><no op><window scale><echoed MSS>

While Linux 2.1.122 returns MENNTNW, which means: <echoed MSS><no op><no op><timestamp><no op><window scale>

Same options, same values, but different order!

Nmap – difficulties guessing specific windows versions.

Even with all the tests above, nmap is still unable to distinguish between the TCP stacks of Win95, WinNT, or Win98. This is rather surprising, especially since Win98 came out about 4 years after Win95.

Fyodor’s solution to guessing Windows software version #

Fyodor proposes: “You can simply start with early Windows DOS

attacks (Ping of Death, Winnuke, etc) and move up a little further to attacks such as Teardrop and Land.

After each attack, ping them to see whether they have crashed. When you finally crash them, you will likely have narrowed what they are running down to one service pack or hotfix.”

This is not implemented in nmap, although it would be fun.

Defeating Nmap’s active scan

Essentially, you want to be able to modify various aspects of your TCP stack, to cause invalid (or even better, false) conclusions by nmap.

A number of methods for doing this are explained in “A practical approach for defeating Nmap OS-Fingerprinting” by David Barroso Berrueta, 2003

http://voodoo.somoslopeor.com/papers/nmap.html

Defeating nmap (ctd) The best method he describes is the IP Personality

project. This is a Linux kernel module that allows you to

change the IP stack behavior and 'personality‘ of your system.

It allows you to have multiple network personalities depending on parameters that you can specify as an iptables rule.

Thus, with this project, not only can you protect your own machine, but with a Linux NAT firewall, you can mask the OS fingerprint of all hosts on your network.

IP Personality

IP Personality allows you to modify the followingoptions: TCP Initial Sequence Number (ISN) TCP initial window size TCP options (their types, values and order in the

packet) IP ID numbers answers to some pathological TCP packets answers to some UDP packets

IP Personality (ctd)

IP Personality ships with a few bogus OS profiles out of the box, but it is pretty simple to write a new one based on nmap’s OS fingerprint database.

IP Personality - before

# nmap scan initiated Wed Feb 19 20:26:52 2003Interesting ports on 192.168.0.19:Port State Service22/tcp open ssh25/tcp open smtp80/tcp open http

Remote operating system guess:Linux Kernel 2.4.0 - 2.5.20Uptime 106.832 days (since Tue Nov 5 00:29:33

2002)

IP Personality - After

# nmap scan initiated Wed Feb 19 21:49:03 2003

Interesting ports on 192.168.0.19:Port State Service22/tcp open ssh25/tcp open smtp80/tcp open http

Remote operating system guess:Sega Dreamcast

IP Personality - problems Some characteristics of OS are related to the host

architecture (for instance, page sizes on different kinds of CPU) which could lead to performance issues.

Some of these changes are more "political" aspects of the IP stack (initial sequence numbers, window sizes, TCP options available...). Tweaking those will allow you to fool a scanner but might break regular connectivity by changing network parameters.

It could also make the system weaker if the emulated IP stack is not as strong as the initial one

Other methods

He also mentions honeyd, written by Niels Provos

Honeyd is part of the honeynet project, and allows the user to create virtual/fake hosts.

Honeyd hosts take an nmap database file as part of their config file, and can thus completely emulate a given OS.

However, honeyd is for making virtual hosts, and cannot help you disguise a real host.

Defeating TCP/IP Stack Fingerprinting

There is also a paper on “Defeating TCP/IP Stack Fingerprinting” by Smart, Malan and Jahanian, Usenix Security 2000.

They describe a traffic normalizer which defeats nmap’s active scans. They aim to confuse nmap, and do not attempt to lie about their OS.

They also seem to hard code everything, rather than supporting nice config files.

It is for this reason that IP Personality is IMHO a lot cooler. By lying about your OS, you add an additional layer of security to your network.

Passive OS Fingerprinting….

Passive OS Fingerprinting

The term for fingerprinting techniques that rely solely upon snooped traffic. This has the added benefit of allowing you to fingerprint hosts which you cannot reach directly (i.e. behind a corporate firewall).

This method is also a lot more covert. Methods using ICMP were previously known,

but given the lack of ICMP traffic flowing from most hosts, that method is not so reliable.

Passive OS Fingerprinting (ctd)

TCP based passive fingerprinting was first described by Toby Miller in a SANS white paper in 2001.

He noticed that by watching TCP packets flow between hosts, there were enough implementation differences to allow you to tell the host OS versions apart.

Some of these include:

Linux 2.2/2.4 specifics…

The following things stand out as Linux specific: TTL:64 Windows: 5840 TCP Options: Sets MSS, Timestamps,

sackOK, wscale and 1 nop Packet Length:60

OpenBSD…

The following things stick out: TCP Options: Uses the same options as Linux BUT

instead of setting one nop, OpenBSD uses 5 nops IP ID: Totally random. Will need more than one

packet to use effectively. Total Packet Length: 64 Bytes. This is a key

indicator.

Solaris 7…

TTL: 255 Window Size: 8760 TCP Options: MSS IP ID: Increments by one ALL of the time. Total Packet Length: 44 bytesBy combining the TTL of 255, and the packet length of 44

bytes, you can be sure this came from a Solaris box

Passive Fingerprinting tools

p0f is the best of the breed of this category. Created by Michael Zalewski in 2001. Works with 3 types of traffic: - Incoming connection fingerprinting –

whenever you want to know what the guy who connects to you runs.

- Outgoing connection fingerprinting – to fingerprint systems you or your users connect to.

- Outgoing connection refused fingerprinting – to fingerprint systems that reject your traffic.

p0f continued.

p0f employs the techniques described in the SANS paper, as well as a few additional techniques.

Just like nmap, it depends upon a database of OS profiles.

It also supports a mode to detect NAT/Masquerade hosts, based on seeing two different OS types sending traffic from the same IP.

p0f info at: http://lcamtuf.coredump.cx/p0f.shtml

p0f/OpenBSD integration

Mike Frantzen ported p0f’s detection code to the OpenBSD firewall subsystem, thus allowing OpenBSD hosts to detect the OS of any machine it connects to, or which connects to it.

Uses the same database as p0f. Is now included in openBSD releases. More info at: http://www.w4g.org/fingerprinting.html

Defeating Passive fingerprinting

Rob Beck, a security guy at @stake wrote an article for Linux Journal in 2002 describing a proof of concept linux iptables module which would allow you to lie about your OS, and fool passive OS scans.

However, this was his first ever C program, and thus the code is not so great.

Your first C program should not involve icky network code. Start with Hello World.

Also, all values were hard coded and did not support config files.

Defeating passive fingerprinting

IP Personality has all the infrastructure in place to do this, and their codebase is a lot nicer.

As it was written before Passive OS Fingerprinting had become widespread, the authors didn’t tackle this subject. However, it would be pretty trivial to modify their scripts to do so.

Conclusion

OS Fingerprinting is a very valuable technique for attackers.

By probing a wide variety of hosts ahead of time, it is possible for attackers to prepare hit-lists to use as soon as the next application/OS exploit is released.

This allows attackers to not waste their time trying IIS exploits against Linux hosts.

Conclusion Considering how much attackers can

gain through using OS fingerprinting, it is important that we be able to defend against their probes.

By being able to trick their probes, you are essentially adding yourself to a hacker do-not-call list (somewhat).

They will only try to attack you with exploits for the OS type which you advertise.

Conclusion Users can protect themselves against

active scans by installing a NAT/firewall box (either an embedded solution, or a linux box)

They can fool active scans by using IP personality, or other tools.

They cannot defend against passive OS fingerprinting by installing a $50 d-link router. Which means that the majority of users will not do it.

Conclusion (ctd)

It is quite realistic to expect evil ISPS to start deploying passive OS scanners on their networks in the future.

Given the technical skills needed to configure IP Personality and a Linux router, many users will be exposed to information leakage, and thus could be subject to future targeted attacks by hackers.

Questions?