Passive Fingerprinting - By PsychoSpy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So, here's the scenario. You found this sweet server that
you want to get into. Do you just jump right in and start
trying things? I sure hope not! Your first task should be
to gather information about the server. Unfortunately a lot
of the time when we do this the server figures out what
we're doing, and starts to keep tabs on us before we can even
get started, causing some serious misfortune to many a hacker.

Is there a solution? Sure there is! What's the solution you ask?
The solution is Passive Fingerprinting. With passive fingerprinting
you can ID a remote host, without them knowing!

So, now you want to know how to do. Well, I guess that's the whole
point to this text so here we go!

With this method you can determine the operating system and a few
other characteristics of the remote host using nothing more then 
sniffer traces. Although it's not 100% accurate, you can get 
surprisingly good results. A proof of concept tool based on some of
the concepts which I'll talk about in this text, was developed by
Craig Smith. Also, the subterrain crew has developed siphon, a passive 
port mapping and OS fingerprinting tool.


Traditionally, fingerprinting of Operating Systems has been accomplished
by active tools like queso and nmap. These tools work on the principle that
every OS's IP stack has it's own characteristics and idiosyncrasies. i.e. 
different operating system respond differently to a variety of malformed 
packets. All that has to be done it to build a database on how the different
OS's respond to the different malformed packets.  Once this has been done, 
to determine the OS of a remote host/server all one has to do is send it a 
variety of malformed packets, figure out how it responds, and then compare 
the responses to those in the database.

Fyodor's nmap is tool of choice when using this methodology, he has also 
written a highly detailed and interesting paper on this.


Now on to passive fingerprinting. Passive fingerprinting follows the same 
general concept but is implemented differently. Passive fingerprinting is
based on sniffer traces from the remote system. Instead of actively
querying the remote system, all one needs to do is capture packets sent
to and from the remote system. Based on the sniffer traces of these packets,
you can determine the OS of the remote system. 
Exactly as is done in active fingerprinting, passive is based on the idea
that every OS's IP stack has it's own characteristics. By analyzing these
sniffer traces and IDing these differences, you can (fairly accurately)
determine the OS of the remote system.

Now you're asking what the signatures in the packets we look at are. 
So, we'll answer that now. There are four areas that we will look at to
figure out what OS is being used. There are more that can be used, but
these are the most used and basic.

- TTL - This is what the OS sets the Time To Live on the outbound packet
- Windows Size - This is what the OS sets the Window Size at. (duh!)
- DF - Does the OS set the Don't Fragment bit?
- TOS - Does the OS set the Type of Service? If so, to what?

By analyzing these areas of a packet, you might be able to determine the 
remote OS. This method is not 100% accurate, and works better on some
OS's than others. No single signature can reliably tell you the remote OS.
However, by look at several signatures and combining all of them, you can 
significantly increase the accuracy of IDing the remote system.

Just in case you don't completely get it yet, and would like it, I have 
included an example. Below is the sniffer trace of a system sending a packet. 
This system launched a mountd exploit against a, so I want to learn more 
about it. Yeah I know it's not a server we're attacking but it's the best 
example I could find. Let's pretend it's a server we're going to attack though.
Obviously we don't want to finger or nmap the box because that would give
us away immediately. Instead, I want to study the information passively.
This signature was captured using snort (a great sniffer.)


     04/20-21:41:48.129662 129.142.224.3:659 -> 172.16.1.107:604
     TCP TTL:45 TOS:0x0 ID:56257
     ***F**A* Seq: 0x9DD90553   Ack: 0xE3C65D7   Win: 0x7D78
   
   Based on our 4 criteria, we identify the following:
     * TTL: 45
     * Window Size: 0x7D78  (or 32120 in decimal)
     * DF: The Don't Fragment bit is set
     * TOS: 0x0


Since we now have this information, we compare this to a database of 
signatures. First, we take a look at the TTL used by the remote system.
From the trace above, as you can see, the TTL was set to 45. 
This means that it most likely went through 19 hops to reach us, so the
original TL was set to 64. 

Based on this TTL, the box seems to be Linux or FreeBSD. 
The TTL is confirmed by doing a traceroute to the system. Obviously we're
concerned that the remote box will detect us, so we set our traceroute
time-to-live to be one or two hops less then the remote most (-m option).
For example in this case we would do a traceroute to the remote host, 
but using only 18 hops. This gives to the path info, without actually touching
the remote system.

What next? We move on and compare the Window Size. The window size is another
effective tool, more specifically what Windows Size was used and how often the
size changes. In the example signature, we see it set at 0x7D78, which is
a default Window Size used in Linux. As another point, Linux, FreeBSD,
and Solaris tend to keep the same Window Size for a whole session.
However, Cisco Routers and Micro$oft Windows/NT Window Sizes are constantly 
changing. It has been found that Window Size is more accurate if taken into 
effect after the initial three-way handshake. For more info on Window Size, 
grab a copy of "TCP/IP Illustrated Volume 1" (a GREAT book if your interested
in learning more about networking) in Chapter 20.
 
Unfortunately the DF bit has very little value to us. Most systems use the DF 
bit set so we're somewhat FUBAR on that account. But, it does make it somewhat 
easier to ID the few systems that do not use the DF flag (examples are SCO
and OpenBSD).

One thing to remember is that, just like Active Fingerprinting, 
Passive Fingerprinting has a few limitations. The first is that applications 
that build their own packets, will not use the same signatures as the OS.
Another is that it is pretty easy for a remote system to adjust the TTL,
Window Size, DF, and TOS settings on the packets.

As was said earlier, we are not limited to the four signatures which we 
discussed earlier. There are others that can be used, such as TCP or IP
options, initial sequence numbers, and IP Identification numbers. 
As an example, Cisco routers tend to start IP Ident numbers at 0, instead of 
randomly assigning them.

Another idea is that ICMP payloads can be used. Max Vision discusses using
ICMP payload type or TCP options for remote host identification.
Microsoft ICMP Request payloads are alphabetic, but Solaris or Linux ICMP 
Request payloads have alphabetic and symbolic characters. 

Passive fingerprinting is also a tool that servers will use to figure out 
who/what/where you are while making an attack if you aren't so stealthy.

As a conclusion all I can say is that as hackers we need every tool available
to us to keep us in the shadows. Why broadcast what we're trying to do to
the servers we're attacking if we can keep them in the dark, and keep
ourselves in a stealth like manner.


Greet'z go out to The Clone (YOU ROCK!!) and Enoch_Root.

This has been yet another fine production of the Non-Existent Crew (WE'RE
ALL CANADIAN EH!! ;-)

-- PsychoSpy
   PsychoSpy@HushMail.Com
   ICQ#: 5057653

   07.15.00