Video Screencast Help
Security Response

Tricks of the Semi-Passive Adversary

Created: 29 Oct 2007 07:00:00 GMT • Updated: 23 Jan 2014 18:45:14 GMT
Erik Kamerling's picture
0 0 Votes
Login to vote

Kohno, Broido, and Clafy introduced theseminal paper "Remote physical device fingerprinting" at the IEEESymposium on Security and Privacy held May 8-11, 2005. In this paperthey outlined for the first time how TCP timestamp values can be usedto physically differentiate one Internet-connected host from another.Their work is based on the concept of “clockskew,” which is the amountand rate at which a computer's clock uniquely deviates from a baseline.Every physical machine's internal clock components deviate from truetime in a measurable and unique way. By measuring this drift patternusing linear regression/curve fitting (using the TCP timestamps option(Tsopt) value in normal TCP traffic) they were able to passively andsemi-passively perform clockskew calculations on remote hosts thatallowed them to accurately fingerprint individual computers. Thiscutting-edge methodology has subsequently enabled them to perform amyriad of brand new de-anonymization attacks.

Using TCP timestamp as a central metric they noted consistentmeasurements over unknown and unpredictable network infrastructure, theability to detect individual hosts behind a network address translation(NAT) device, and the ability to reliably de-anonymize cloaked andfirewalled systems. Their techniques are reportedly accurateirrespective of the fact that target hosts were time synchronized usingthe network time protocol (NTP). The fact that their methods can beused against NTP-synchronized machines demonstrates that their driftmeasurement technique detects microscopic hardware deviations thatexhibit in system clock components even when NTP synchronization is atmicrosecond precision.

A good portion of their paper is based on purely passive TCPtimestamp analysis. In an adversarial environment this is somethingthat we can only partially control. Only by forcibly deactivating TCPtimestamping in all egress network traffic from our organizations couldwe thwart the ability of a purely passive adversary to useclockskew-based analysis to gather sensitive data on our operations.This is an unreasonable requirement to impose in most systemconfigurations and I want to focus this blog series on the detection ofone of the paper’s most interesting and detectable semi-passivemaneuvers instead. On page five of "Remote physical devicefingerprinting," a chapter entitled "A Trick for Measuring Windows 2000and XP Machines" is introduced, where the authors outline anexploitable peculiarity of Windows-based systems using the TCPprotocol. When establishing a connection, Windows systems do not setthe TCP timestamp option on outgoing synchronization (SYN) packets bydefault. This is an automatic default mitigation against theadversarial use of timestamp data originating from our organizations.However, the paper outlines a way in which a semi-passive party (onethat is willing to actively perturb a certain portion of returningtraffic) can force Windows systems to begin timestamping their packetsin violation of the guidelines set forth in RFC 1323 "TCP Extensionsfor High Performance." This is the “Request for Comments” (RFC)document where timestamping is outlined in the greatest detail.

Naturally, we should be concerned if our systems can be forced totimestamp outgoing traffic against their default configurations, sincea semi-active attacker can potentially manipulate client/server trafficunder their purview to de-anonymize our internal users, enumerate hostsbehind our firewalls, and generally obtain more network andconfiguration information than we intend to allow. (Please see the“Remote physical device fingerprinting” paper for more detail.) Beforewe move on to the attack and how to detect it, we need to know what isoutlined in RFC 1323 and how Windows systems behave regarding TCPtimestamping.

The TCP timestamp option is outlined in detail in RFC 1323. The TCPtimestamp is a performance enhancement used for both round trip timemeasurement (RTT) and protection against wrapped sequence numbers(PAWS). When TCP timestamps are used, each node in a TCP conversationwill include a relative time delta in outgoing packets. An adversarywith access to timestamp tagged TCP flows can then use this informationto plot a single systems clock drift and uniquely identify a physicaldevice.

The guidance for the TCP Timestamps Option Clock in RFC 1323specifies the TCP timestamps option (Tsopt) will be utilized when theTCPs on both ends of a conversation implement the Tsopt option and whenthe initiator of TCP communications includes this option in its initialsynchronization (SYN) packet. The Tsopt option is a single TCP optionmade up of both a timestamp and timestamp reply field. Timestampingtraffic between nodes is supposed to be bi-directional and composed ofa timestamp value field (TSval) and a timestamp echo reply field(TSecr).

RFC 1323 Timestamp details:

TCP Timestamps Option (TSopt):

Kind: 8

Length: 10 bytes

|Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)|
1 1 4 4

The Timestamps option carries two four-byte timestamp fields.
The Timestamp Value field (TSval) contains the current value of
the timestamp clock of the TCP sending the option.

The Timestamp Echo Reply field (TSecr) is only valid if the ACK
bit is set in the TCP header; if it is valid, it echoes a times-
tamp value that was sent by the remote TCP in the TSval field
of a Timestamps option. When TSecr is not valid, its value
must be zero. The TSecr value will generally be from the most
recent Timestamp option that was received; however, there are
exceptions that are explained below.

A TCP may send the Timestamps option (TSopt) in an initial
segment (i.e., segment containing a SYN bit and no ACK
bit), and may send a TSopt in other segments only if it re-
ceived a TSopt in the initial segment for the connection.

Figure 1. RFC 1323 (

Specifically I’d like to draw your attention to the last paragraphin Figure 1 above. The RFC specifies that a node may set Tsopt in othersegments (anything other than initial SYN packets) only if it receivesa Tsopt in an initial SYN packet. What this means is that a given hostis not supposed to begin timestamping in the middle of a conversation,unless the opposing host in the conversation specified its desire totimestamp when it established the initial TCP handshake. It is alsoimportant to note that Windows XP, 2000, and Vista systems areconfigured by default to not specify Tsopt on outgoing SYN packets.This is an important point to remember.

The following registry settings control Windows TCP timestamp behavior when initiating new connections.

Windows 2000/2003/XPTcp1323OptsKey: Tcpip\ParametersValue Type: REG_DWORD—number (flags)Valid Range: 0, 1, 2, 30 (disable RFC 1323 options)1 (window scaling enabled only) 2 (timestamps enabled only)3 (both options enabled)Default: No value. The default behavior is as follows: do not use theTimestamp and Window Scale options when initiating TCP connections butuse them if the TCP peer that is initiating communication includes themin the SYN segment.

Windows Vista and Longhorn
Key: Tcpip\Parameters
Value Type: REG_DWORD—number (flags)
Valid Range: 0 or 2
0 (disable the use of the TCP timestamps option)
2 (enable the use of the TCP timestamps option)
Default: No value.

This allows us to conclude that egress connections initiated byWindows client systems in most configurations will almost never carrytimestamp data. If Windows systems never specify Tsopt in outgoingpackets, and they are also not supposed to begin timestamping if aremote host surreptitiously timestamps in-flow packets (because theyare expected to comply with RFC 1323), then we have effectively stymieda purely passive adversary’s ability to glean timestamp-related datafrom our internal Windows clients. Whether or not Windows systemsultimately comply with the specifications set forth in RFC 1323 isanother story. In fact, Kohno, Broido, and Clafy hinted at a simple andtantalizing trick to force Windows systems to begin timestampingmid-flow in direct violation of RFC 1323 guidelines.

With the next blog in this series I’ll explore what they discovered. Stay tuned – I’ll be back in a couple of days.