Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.
Security Response

Tricks of the Semi-Passive Adversary – Conclusion

Created: 02 Nov 2007 07:00:00 GMT • Updated: 23 Jan 2014 18:44:56 GMT
Erik Kamerling's picture
0 0 Votes
Login to vote

In the previous entries in this series (part 1, part 2)I discussed the different tricks and indicators of issues involvingtimestamping anomalies, specifically with Windows-based computers. Now,from a defense and detection standpoint it is relatively easy to detectsuch activities on the network using a tool like Wireshark or its command-line equivalent tshark.

In the example below we make two assumptions: 1) Windows clients onour network should not be using the timestamp option on outgoing SYNpackets (this violates default configurations), and 2) a host on theoutside of our network that receives a SYN with no timestamp set shouldnot respond in turn with a timestamped SYN/ACK packet.

The SYN/ACK flag filter we will use is simple. We’ve used Wiresharkto catch and distill packets with the TCP SYN and ACK Flags using thissyntax: “tcp.flags.syn==1” and “tcp.flags.ack==1.” Combined, this would appear as one filter of “tcp.flags.syn==1&&tcp.flags.ack==1.”When run against a dump of traffic from our networks this will filtereverything except packets with the SYN/ACK flags set. Additionally, wecan use a simpler filter of “tcp.flags==18.” The binary value of the TCP flags field in a packet with SYN and ACK set is binary 000100010, or decimal 18.

Continuing, the Wireshark filter for TCP Timestamp is “tcp.options.time_stamp.”To apply the completed filter to catch anomalous SYN/ACK responses withthe timestamp option set we would apply the complete filter of “tcp.flags.syn==1&&tcp.flags.ack==1&&tcp.options.time_stamp,” or more simply:

tcp.flags==18&&tcp.options.time_stamp

As we can see in the screen capture below, this filter does in factcatch SYN/ACK packets with anomalistic timestamp options on SYN/ACK.Note: this filter will also catch legitimate SYN/ACK packets withtimestamp set.


Such a packet would warrant further investigation

Correspondingly, the tshark command to filter a pre-captured packet dump of network traffic would be:

:/$/tshark -r .pcap -w .pcap "tcp.flags==18&&tcp.options.time_stamp"

The objective when investigating packets that are caught by suchfilters is to correlate anomalous return SYN/ACK packets containingtimestamp with an egress Windows SYN that carried no original Tsopt,option. If we catch such a return SYN/ACK we would know that we aredealing with potentially malicious or covert activity.

By intentionally violating RFC 1323 standards a semi-passiveadversary is able to essentially de-cloak our NATed hosts, de-anonymizeour internal users as they browse, and purportedly physicallyfingerprint individual nodes by their clockskew. Divergence from RFCstandards in individual vendor platform implementations is aninteresting area of study and regularly leads to the discovery ofsignificant vulnerabilities and design flaws. This one in particular(the Windows clients’ propensity to answer mid-handshake TCPtimestamping) is of particular interest and could lead to a myriad ofproblematic issues for more security conscious organizations. Ifsystems within your protected enclaves are used for sensitive purposesand accurate attribution and fingerprinting would be a breach of yourdefenses; if your internal users simply can not afford to beidentified; or if an accurate source or location attribution tied toyour systems would be a serious loss of confidentiality, then you maywant to consider implementing outbound TCP timestamp controls thatcould help mitigate this threat.

References

RFC 1323
http://www.ietf.org/rfc/rfc1323.txt

Remote physical device fingerprinting
http://www.caida.org/publications/papers/2005/fingerprinting/

The prisoner's problem and the subliminal channel.
http://dsns.csie.nctu.edu.tw/research/crypto/HTML/PDF/C83/51.PDF

Covert Messaging Through TCP Timestamps
http://web.mit.edu/greenie/Public/CovertMessaginginTCP.ps

Embedding Covert Channels into TCP/IP
http://www.cl.cam.ac.uk/~sjm217/papers/ih05coverttcp.pdf

Hping Homepage
http://www.hping.org

TCP/IP Registry Values for Microsoft Windows Vista and Windows Server "Longhorn"
http://download.microsoft.com/download/c/2/6/c26893a6-46c7-4b5c-b287-830216597340/TCPIP_Reg.doc

Windows 2000 TCP/IP Implementation Details
http://download.microsoft.com/download/7/7/1/7716a332-d3af-4ad5-b249-38ca97db023e/tcpip2000.doc

Microsoft Windows Server 2003 TCP/IP Implementation Details
http://download.microsoft.com/download/f/0/f/f0f28365-bd9a-4ff8-a5d4-fc0f94ae7371/TCPIP_2003.doc

Postscript: The concept of the semi-passiveadversary is drawn primarily from Gustavuis J. Simmons' paper "ThePrisoners' Problem and the Subliminal Channel' Advances inCryptography: Proceedings of Crypto-83, Aug. 1983, pp. 51–67. where athreat model outlining passive message interception in an adversarialenvironment was first introduced. The concepts of passive analysis asthey will be dealt with in this article are further clarified innumerous industry papers; most notably in outlining issues ofactive-wardens to defeat covert TCP communications in "EliminatingSteganography in Internet Traffic with Active Wardens" by Fisk, Fisk,Papadopoulos, and Neil of Los Alamos National Laboratory, and detailinga passive-warden model in "Embedding Covert Channels into TCP/IP" byMurdoch and Lewis of the University of Cambridge, Computer Laboratory.