OS Fingerprinting For Fun and Profit

bubblesradiographerServers

Dec 4, 2013 (3 years and 6 months ago)

74 views

OS Fingerprinting

For 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.9

rewritten 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.jp

Trying 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 21

Trying 207.200.74.26 ...

Connected to
ftp.netscape.com
.

Escape character is '^]'.

220 ftp29 FTP server ready.

SYST

215 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.0

babylon>




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.ht
ml

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 following

options:


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 2003

Interesting ports on 192.168.0.19:

Port


State


Service

22/tcp


open


ssh

25/tcp

open


smtp

80/tcp

open


http


Remote operating system guess:

Linux Kernel 2.4.0
-

2.5.20

Uptime 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


Service

22/tcp


open


ssh

25/tcp

open


smtp

80/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 bytes

By 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?