LNCS 2820 - Ambiguity Resolution via Passive OS Fingerprinting

More documents

Recommendations

Info

Ambiguity Resolution via Passive OS Fingerprinting 195 3.2 Passive Fingerprinting Passive fingerprinting attempts to determine the host type by passively monitoring a network link, and not sending any traffic onto the wire. Existing passive OS fingerprinting tools examine the values of fields in the IP and TCP headers of initial TCP SYN segments sent from clients. Common fields used are: – Initial Window Size (WS) – Time To Live (TTL) – Maximum Segment Size (MSS) – Don’t Fragment (DF) Bit – Window Scale Value – SackOK option presence – Nop option presence This technique also relies on requiring an exact match of all the fields used in the fingerprint 1 . Other techniques[20] look at how to detect network stack implementations by examining TCP segments throughout the connection, or by examining the timing of TCP segments traveling back and forth[24]. 3.3 Defeating OS Fingerprinting As accurate as both active and passive OS fingerprinting may be, there are methods to prevent a potential attacker from guessing a host’s operating system[9]. For example, a host can fool p0f, in the simplest case, by changing any one of the values enumerated above. Fooling nmap or queso requires a little more effort, since these tools send multiple tests. In order to avoid detection, one must ensure that a majority of the tests sent fail to provide enough intelligence to make a guess. 3.4 Exploitation of the TCP Three-Way Handshake Existing passive fingerprinting tools work by looking at the first SYN segment of a TCP connection. However, the replying SYNACK from the server can also yield pertinent information that can be used to identify the host. Since the servers are typically within the same network as the deployed IDS, this information is much more important. Most attacks are initiated by the client side of the connection. Additionally, if a person or program were to try to evade an IDS, they would do so in order to push an attack through without the IDS detecting it. Since the server side that will be accepting the ambiguous traffic, it is this side we are more interested in fingerprinting. During the three-way handshake to initialize the TCP connection, a client connects to a server within the network by sending a TCP SYN segment, and 1 Exceptions to this are the p0f tool, which will incrementally alter the TTL field to obtain a match since a packet in flight can have a variable TTL value depending on the network path taken, and Xprobe, which can use a best-match algorithm.
196 G. Taleck IDS Client Server SYN SYNACK fragment 1 (24 bytes at offset 0) AAAABBBBCCCC_attack_code fragment 2 (20 bytes at offset 12) DDDDEEEEFFFFGGGGHHHH ? 2 possible resolutions of ambiguity by the IDS: AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH (Last Policy) AAAABBBBCCCC_attack_codeGGGGHHHH (First Policy) Fig. 1. Network packets from a potential attacker and its victim as seen by an IDS. the server replies with a SYNACK segment. Consider the example shown in Figure 1, where packets are sent between a client (potential attacker) and server (potential victim) as seen by an IDS sensor. In this scenario, the only information seen on the wire that can be used to identify the server is the SYN from the client and the corresponding SYNACK reply from the server to open the connection. However, depending on the values within the TCP header and the options present within the SYN from the attacker and how the server negotiates those options, it is possible to make a guess at the operating system of both the client and the server. If an accurate guess is made for the operating system type of the server, then we can attempt to resolve the ambiguity in the subsequent fragmented packets sent by the client to the server and have a better chance of determining whether an attack occurred. Another example can be an attack from a server to a client, where we can lookup the client via its TCP SYN segment and possibly determine the operating system type. Consider the case where a web browser within the network connects to a malicious server outside of the network in an attempt to gain control of the client.
Page 1 and 2: Ambiguity Resolution via Passive OS
Page 3: 194 G. Taleck 2.2 Traffic Normaliza
Page 7 and 8: 198 G. Taleck Minimal FTP Client FT
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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?