上QQ阅读APP看书，第一时间看更新

Passive Operating system Fingerprinter

Anyone who has dissected a packet off a network should be familiar with the concept of operating system fingerprinting. Essentially, operating systems have little nuances in how they construct packets to send over the network. These nuances are useful as signatures, giving us a good idea of the operating system that sent the packet. We're preparing to spoof the stack of a chosen OS as previously explained, so let's cover a tool in Kali that will come in handy for a variety of recon situations: Passive Operating system Fingerprinter (p0f).

Its power is in its simplicity: it watches for packets, matches signatures according to a signature database of known systems, and gives you the results. Of course, your network card has to be able to see the packets that are to be analyzed. We saw with our example that the restricted network is switched, so we can't see other traffic in a purely passive manner; we had to trick the network into routing traffic through our Kali machine. So, we'll do that again, except on a larger scale as we want to fingerprint a handful of clients on the network. Let's ARP spoof with Ettercap, a tool that should easily be in your handiest tools Top 10. Once Ettercap is running and doing its job, we'll fire up p0f and see what we find.

We're going to bring up Ettercap with the graphical interface featuring a very scary-looking network-sniffing spider:

# ettercap -G

Let's start sniffing, and then we'll configure our man-in-the-middle attack. Click Sniff in the menu at the top and choose Unified Sniffing. Unified sniffing means we're just sniffing from one network card; we aren't forwarding anything to another interface right now.

We will cover the beauty of bridged sniffing in the next chapter.

Now we tell Ettercap to find out who's on the network. Click Hosts | Scan for hosts. When the scan is complete, you can click Hosts again to bring up the host list. This tells us what Ettercap knows about who's on the network.

Now, we're doing something rather naughty; I've selected the gateway as Target 1 (by selecting it and then clicking Add to Target 1) and a handful of clients as Target 2. This means Ettercap is going to poison the network with ARP announcements for all of those hosts, and we'll soon be managing the traffic for all of those hosts.

Be very careful when playing man-in-the-middle with more than a few hosts at a time. Your machine can quickly bottleneck the network. I've been known to kill a client's network doing this.

Select Mitm | ARP poisoning. I like to select Sniff remote connections, though you don't have to for this particular scenario.

That's it. Click OK and now Ettercap will work its magic. Click View | Connections to see all the details on connections that Ettercap has seen so far.

Those of you who are familiar with Ettercap may know that the Profiles option in the View menu will allow us to fingerprint the OS of the targets, but, in keeping with presenting the tried-and-true, quick-and-dirty tool for our work, let's fire up p0f. The -o flag allows us to output to a file – trust me, you'll want to do this, especially for a spoofing attack of this magnitude:

# p0f -o poflog

p0f likes to show you some live data as it's collecting the juicy gossip. Here we can see that 192.168.108.22 is already fingerprinted as a Windows NT host by looking at a single SYN packet:

Ctrl + C closes p0f. Now, let's open up our (greppable) log file with nano:

Beautiful, isn't it? The interesting stuff is the raw signature at the end of each packet detail line, which is made up of colon-delimited fields in the following order:

Internet protocol version (for instance, 4 means IPv4).
Initial time-to-live (TTL). It would be weird if you saw anything other than 64, 128, or 255, but some OSes use different values; for example, you may see AIX hosts using 60, and legacy Windows (95 and 98) using 32.
IPv4 options length, which will usually be 0.
Maximum Segment Size (MSS), which is not to be confused with MTU. It's the maximum size in bytes of a single TCP segment that the device can handle. The difference from MTU is that the TCP or IP header is not included in the MSS.

TCP receive window size, usually specified as a multiple of the MTU or MSS. p0f is nice enough to let us know; in this case, the value is the MSS multiplied by 44.
Window scaling factor, if specified.
A comma-delimited ordering of the TCP options (if any are defined).
A field that the readme calls quirks: weird stuff in the TCP or IP headers that can help us narrow down the stack creating it. Check out the readme file to see what kind of options are displayed here; an example is df for the don't fragment flag set.

Why are we concerned with these options anyway? That's what the fingerprint database is for, isn't it? Of course, but part of the wild and wacky fun of this tool is the ability to customize your own signatures. You might see some funky stuff out there and it may be up to you playing with a quirky toy in your lab to make it easier to identify in the wild. However, of particular concern to the pen tester is the ability to craft packets that have these signatures to fool these NAC validation mechanisms. We'll be doing that in the next section, but for now, you have the information needed to research the stack you want to spoof.