LNCS 2820 - Ambiguity Resolution via Passive OS Fingerprinting

More documents

Recommendations

Info

Ambiguity Resolution via Passive OS Fingerprinting 197 It should be noted the the ettercap tool mentioned in Section 2 does have an entry for the ACK bit in its signature database. However, it does not correlate the formation of the SYNACK response to the SYN request. The next section describes how we can build a collection of fingerprints and their corresponding ambiguity resolution policies. 4 Building TCP SYN/SYNACK Fingerprint Tables In order to passively map hosts on a network to a particular operating system, we need to deploy IDS sensors with a pre-built table containing mappings of TCP SYN/SYNACK fingerprints to ambiguity resolution policies. Two tables are necessary: one table for identifying TCP SYN segments and another, more important, table for identifying TCP SYNACK segments. We use the existing active fingerprinting techniques, as well as some new ones, to build these policy tables. 4.1 Eliciting TCP SYNs The p0f tool contains a reasonably robust table of fingerprints to map TCP SYN segments, but it requires human intervention to keep it up-to-date. To automate this task, one simply needs to be able to automatically elicit TCP SYN segments from a variety of hosts, keep track of the values set in the SYN segment, and then use an active OS fingerprinting tool, such as nmap, to identify the operating system. We do this with a tool that scans the Internet at large for hosts running FTP servers that accept anonymous connections 2 . Luckily, there are many of these. The tool connects to the FTP server, attempts to negotiate and verify active transfer mode (since most FTP servers default to passive), and invokes the LIST command to obtain a directory file listing. This results in a TCP SYN segment sent from the FTP server to the listening port sent by the FTP client, as shown in Figure 2. The tool uses libpcap[23] to catch all initial SYN segments with a TCP destination port equal to the port number sent in the FTP LIST command, and gathers the fields and values present in the SYN segment. It then detects its fragment reassembly policy and overlapping TCP segment policy using the same methods described in [1]. This is done by sending specially crafted IP fragments and TCP segments across the same TCP connection and observing how the host responds. The tool then attempts to identify the host OS type by forking off an nmap process. If nmap fails to identify the host operating system, we will still know how that stack resolves network protocol ambiguities. Having knowledge of the host operating system is really only useful as eye candy to an administrator. 2 It is also possible to exploit the gnutella protocol by creating a lightweight client to connect to the network and both accept connections and send PUSH descriptors to elicit TCP SYN segments. This would nicely complement the set of SYNs from FTP servers, which are primarily high-end OS’s.
198 G. Taleck Minimal FTP Client FTP Server TCP Connect USER anonymous PASS pass@word.org PORT ip,ip,ip,ip,port,port LIST FTP Banner sent Anonymous access ok Login successful PORT command successful LIST data sent to port PORT Look for TCP SYN Segment with destination port PORT QUIT Connection closed Fig. 2. Sample network dialogue between a minimal FTP client and an FTP server to elicit a TCP SYN segment from the server. By polling many hosts, we can also weed out bogus entries where administrators have set up the host to fool nmap by using methods described in Section 3.3. Since this tool really requires no human interaction, it can continuously poll new IP’s and re-poll old ones. 4.2 Eliciting TCP SYNACKs The process of eliciting TCP SYNACK segments from a host is much simpler. This only requires that the host have at least one unfiltered port open. Existing active OS fingerprinting tools, such as nmap and queso, utilize a number of TCP tests against open ports to evaluate the network stack behavior. We also utilize these tests, and additionally, make more extensive use of TCP options. The most prevalent TCP options used in common, modern operating systems are the Maximum Segment Size (mss), Selective Acknowledgment (sackok), Timestamping (timestamp), and the Window Scaling (wscale) options. nmap first exploited the use of these options as the default set to actively examine stack implementations in nmap. Fyodor mentions that TCP options are “truly a gold mine in terms of leaking information”[7]. However, nmap fails to fully mine the information available via these options. TCP Options Tests. Using these four most common TCP options, 16 new nmap-like tests are created. Once a host is found with at least one open port, 16
Page 1 and 2: Ambiguity Resolution via Passive OS
Page 3 and 4: 194 G. Taleck 2.2 Traffic Normaliza
Page 5: 196 G. Taleck IDS Client Server SYN
Page 9 and 10: 200 G. Taleck Table 2. Encoding of
Page 11 and 12: 202 G. Taleck that failed (either t
Page 13 and 14: 204 G. Taleck The “freshness” o
Page 15: 206 G. Taleck 7. Fyodor: Remote OS

LNCS 2820 - Ambiguity Resolution via Passive OS Fingerprinting

Create successful ePaper yourself

Delete template?

Save as template?