Summary and recommendations

QUANTUMINSERT (QI) is actually a relatively old technique. In order to exploit it, you will need a monitoring capabilities to leak information of observed TCP sessions and a host that can send spoofed packets. Your spoofed packet also needs to arrive faster than the original packet to be able to be successful.

Any nation state could perform QUANTUM attacks as long as the traffic passes through their country or possesses other capabilities to get the required TCP session data.

QUANTUMINSERT could be used for lateral movement within internal networks.

Detection is possible by looking for duplicate TCP packets but with different payload and other anomalies in TCP streams.

The usage of HTTPS in combination with HSTS can reduce the effectiveness of QI. Also using a content delivery network (CDN) that offers low latency can make it very difficult for the QI packet to win the race with the real server.

Deep dive into QUANTUM INSERT

The documents leaked by former National Security Agency (NSA) contractor Edward Snowden mention dozens of hard- and software attacks available to the NSA to gain and maintain access to target networks.

There has been some effort at recreating and open sourcing some of the hardware implants. Progress of this effort can be found at the NSA Playset[1]

website. Though various articles and blogs have been focussed on the attacks detailed in the leaked slides, little has actually been done on the detection side of things. We feel that this is important as with the publication of these documents, attacks like these could become more common.

Our focus for this article will be on performing and detecting one specific attack in the QUANTUMTHEORY[2] toolset called QUANTUMINSERT (QI). While this weakness in TCP has been known about for a long time, the NSA has allegedly deployed this attack successfully against targets..We will explain the attack, how it can be performed, and how you can detect it using Intrusion Detection Systems like Bro, Snort and Suricata. The code we used to test this attack is available on our GitHub page.

What is a QUANTUM INSERT attack

QUANTUMINSERT is described as a ‘HTML Redirection’ attack by injecting malicious content into a specific TCP session. A session is selected for injection based on ‘selectors’[3], such as a persistent tracking cookie that identifies a user for a longer period of time.

The injection is done by observing HTTP requests by means of eavesdropping on network traffic. When an interesting target is observed, another device, the shooter, is tipped to send a spoofed TCP packet. In order to craft and spoof this packet into the existing session, information about this session has to be known by the shooter.

All the information required by the shooter is available in the TCP packet containing the HTTP request:

Source & Destination IP address

Source & Destination port

Sequence & Acknowledge numbers

For the attack to succeed the packet injected by the shooter has to arrive at the target before the ‘real’ response of the webserver. By exploiting this speed difference or race condition, one can impersonate the webserver.

A video was posted online by The Intercept that shows the inner workings of QUANTUMHAND, which uses QUANTUMINSERT against targets visiting Facebook: https://vimeo.com/88822483.

We made the following animation showing a more high level overview of this attack:

Who is able to perform these attacks

Anyone who can passively or actively monitor a network and send spoofed packets can perform QUANTUM-like attacks. The NSA is allegedly able to perform this attack on a large scale on the internet and with a high success rate, which of course not everyone can simply do. This is because it requires the capability to listen in on potentially high volumes of internet traffic, which requires substantial resources and a fast infrastructure. This means that internet service providers (ISP) can potentially also perform these attacks.

A nation state could perform QUANTUM-like attacks when traffic passes through their country. An example of this is the recent research on China’s Great Cannon[4] by CitizenLab that confirms this.

What are QUANTUMINSERTS used for

NSA’s QUANTUM attacks are possible against various protocols and for different purposes. For both offensive and defensive capabilities as the following table shows:

Attack Description QUANTUMINSERT A man-on-the-side attack. Brief hijack of connection to redirect target to exploit server. QUANTUMBOT Capable of hijacking idle IRC bots and hijacking c2 communication from bots. QUANTUMBISQUIT Enhances QIs effectiveness against proxies and other hard to reach targets QUANTUMDNS DNS injection/redirection of A records. Targets single hosts or chaching name servers QUANTUMHAND Exploits the computers of Facebook users QUANTUMSKY Denies access to a webpage by injecting/spoofing RST packets. QUANTUMCOPPER File download/upload disruption and corruption. Source: https://firstlook.org/theintercept/document/2014/03/12/one-way-quantum/

All of these programs attempt to race the response packet to the target before the response of the real server arrives.

NSA has QUANTUMINSERT capabilities since 2005. The first QUANTUM tool was QUANTUMSKY, realised in 2004. The most recent development, according to the slides was done in October of 2010.

Man-on-the-Side vs Man-in-the-Middle

The QUANTUM attacks described in the Snowden leaks are all man-on-the-side (MOTS) attacks, while China’s Great Cannon attack uses man-in-the-middle (MITM) capabilities. There is been some misinformation on the matter in write-ups.

The difference between the two can be observed by looking at the network traffic of the attacks[4]. The Great Firewall of China (not to be confused with The Great Cannon), injects additional TCP reset (RST) packets, and the original real responses can be observed after these RST packets. This is a sign of a MOTS attack, rather than a MITM attack. The network traffic related to the Great Cannon showed only modified packets and no original responses. In other words: the original packets were replaced. This is a sign of a MITM attack, rather than a MOTS attack. The CitizenLab report describes this in great detail.

Monitor and shooter locations

The attack can be done against remote networks on the internet, but also inside internal networks for lateral movement purposes. The closer the monitor and shooters are to the target, the higher the success rate.

Similar attacks

There has been work on injecting packet into TCP sessions. Some tools that perform a similar attack to QUANTUMINSERT are:

The attack performed by Kevin Mitnick back in 1994 used the same principles as QUANTUMINSERT, though he predicted TCP sequence numbers rather than observing them [5]

Hunt, a tool released in 1999 was able to spoof and hijack connections.

TCP Session Hijacking by Cheese, an article released in 2009, describes the technique accompanied by source code showing how to do it an article released in 2009, describes the technique accompanied by source code showing how to do it [6]

AirPwn [7] , a framework for 802.11 (wireless) packet injection.

How we performed a QUANTUMINSERT attack

We used three virtual machines (VM) to simulate the monitor, client and shooter, as described in the leaked slides. In this controlled environment it was relatively easy to outrace the server response and inject a HTTP response into the TCP session of the web browser.

The monitoring VM received a copy of all the client traffic and was configured to search for a specific pattern in the HTTP request. When a matching packet was found, the monitor service would notify the shooter about the current IPs, ports, sequence and ACK numbers of the session. The shooter would then send a spoofed TCP packet containing the right values for the session and a not so malicious HTTP response to prove the insert was successful.

The monitor is a simple Python script that can read Tcpdump or Tshark output for the required sequence numbers, ACK numbers, IP addresses, TCP ports and optionally HTTP cookie values.

The shooter is also written in Python using Scapy for crafting and sending the spoofed packets.

We then tested this code over the internet in a controlled environment. One of the harder parts was finding a service provider that permitted source IP spoofing close to our office.

The code to simulate the QI can be found on our GitHub repository: https://github.com/fox-it/quantuminsert/tree/master/poc/

Content of a QUANTUM INSERT payload

QUANTUMINSERT focuses on HTTP traffic and attempts to redirect the target to an exploit server. This means the packet will most likely contain a HTTP redirect or a HTML iframe to perform the redirect to an exploit server.It is also possible to exploit without redirection, using a browser vulnerability or malicious javascript.

While the QI can be done anywhere in a HTTP session, it is likely that the inject happens right after the HTTP GET requests that matches ‘selectors’ such as URL, source IP or Cookie header to identify and target specific users.

According to the slides, a QI is used for redirection to an exploit server but it can contain virtually any payload you want. For example, China’s Great Cannon inserted 3 TCP packets containing a malicious javascript to perform a denial of service (DDoS) attack on GitHub[8].

Detection of QUANTUM INSERT attacks

Among the leaked NSA documents was a slide from the Communications Security Establishment Canada describing how to detect QUANTUMINSERT attacks:

To clarify the above, the first content carrying packet is the first packet containing data received by the client from the server. If there are two packets received with the same sequence numbers but have a different payload, it is a possible QI attack.

Theoretically an insert can be done anywhere in the TCP session, for example in long lived HTTP/1.1 sessions. A redirect could also be performed that would have less than 10% difference with the real payload. For example by doing the QI on a similar domain name on a HTTP 302 redirect.

It is even possible to start ‘shooting’ before the client sends the HTTP request, resulting in a faster response than the real HTTP response. However, by doing so you will lose the ability to identify and target specific users. According to the leaked slides, NSA targeted clients with QUANTUMINSERT using selectors such as HTTP cookies.

So in practice we have to look for duplicate HTTP response packets with significant differences in their content.

In order to detect this using an IDS one would need to observe the network traffic between client and the internet.

Payload inconsistency

A client will receive duplicate TCP packets with the same sequence number but with a different payload. The first TCP packet will be the “inserted” one while the second is from the real server, but will be ignored by the client. Of course it could also be the other way around; if the QI failed because it lost the race with the real server response.

Checking the first content carrying packet is probably the easiest way to detect a QI, but offers no guarantees, as an inject can be present later in the TCP session. Checking only the first content carry packet reduces the amount of false positives.

A retransmission with a different payload size will sometimes look like a QUANTUMINSERT, this can happen when a retransmission is cut short, for example during TCP window size changes.

TTL anomalies

The injected packets also show a difference in their Time To Live[9] (TTL) values. Because the QI packets are usually inserted closer to the target client, the TTL is relatively higher than that of the real responses, because they come from further away. While the initial TTL can be modified, it is difficult to exactly predict the correct TTL value.

Slight variations in TTL values are not unusual, due to route changes on the internet.

Other anomalies

Other anomalies can be seen if the spoofed packets are not carefully crafted. For example, the TCP Timestamp value is usually set if it was also set in the TCP SYN packet. However this could vary between operating systems.

Other values such as the Differentiated Services Code Point (DSCP) in the IP header can also be observed for anomalies.

Detection using IDS

We created a number of packet captures (pcaps) when performing the Quantum Insert attack, which can be found here: https://github.com/fox-it/quantuminsert/tree/master/pcaps

This helped us with developing detection for a number of Intrusion Detection Systems and we hope others find these pcaps useful for further analysis and research.

While we have released Snort signatures in the past, we realised that this was not going to be enough to detect Quantum Insert. The Fox-IT Security Research Team successfully made detection for Quantum Insert and released this proof of concept code into the public domain on our GitHub: https://github.com/fox-it/quantuminsert/tree/master/detection

Snort

We made custom patches to the Snort Stream pre-processor to be able to detect possible Quantum Inserts. We found this to be the most efficient way rather than creating our own pre-processor. When a possible QI is detected it will trigger an event and also try to log the payload of the other TCP packet that was inconsistent as extra data.

See the README.md for more technical details: https://github.com/fox-it/quantuminsert/tree/master/detection/snort

We hope these patches will eventually find its way upstream.

Bro

We made a Bro policy to check for inconsistencies in the first content carrying packet. Keeping track of multiple packets would be better, if this could be done in the core functionality of Bro. We attempted to use the rexmit_inconsistency event, but this did not seem to work. Others have also reported this on the mailing lists[10], however it never got much attention. It should be feasible to improve Bro so that it can also keep track of older TCP segments, in order to detect QI like attacks. There’s even an official Bro ticket for this: BIT-1314[11].

See the README.md for additional technical details:https://github.com/fox-it/quantuminsert/tree/master/detection/bro

Suricata

We asked the lead developer of Suricata, Victor Julien, if he could verify Suricata’s coverage for QI by supplying him a pcap. Victor explained that Suricata has an event called ‘stream-event:reassembly_overlap_different_data’ that can be alerted on when triggered using a default signature. We received an additional signature that detects HTTP 302 responses in possible QI payloads.

https://github.com/fox-it/quantuminsert/tree/master/detection/suricata

Evasion

Note that these detection methods are possibly not evasion proof, one could also easily spoof a FIN packet after the QI packet to close the session. This would stop tracking the TCP segments in most IDS systems. Later packets in this stream will not be matched with previous packets.

Other possibilities is to try to create a partial overlap of data, thus avoiding detection of duplicate sequence numbers.

Other work

The following blog post[12] describes how to perform QI containing Proof of Concept code to perform the attack: https://github.com/stealth/QI

HoneyBadger[13], is a comprehensive TCP stream analysis tool for detecting and recording TCP attacks written by David Stainton can most likely also detect this attack.

While writing this article a DoS attack on GitHub was going on and a analysis was posted by NETRESEC[8], we did not see duplicate packets in the screenshots that could indicate a QUANTUM (man on the side) attack. However, the difference in TTL values was noticeable.

The detection for this attack has been included in our Cyber Threat Management platform.

References

1. Nsaplayset website

2. Overview of QUATUMTHEORY

3. Selectors used by the NSA

4. Chinas Great Cannon

5. How Mitnick hacked Tsutomu Shimomura

6. TCP session hijacking by Cheese

7. Airpwn

8. Man on the side attack on GitHub.

9. Time To Live

10. Bro Mailing list

11. QI Bro ticket

12. Killing Schrodingers cat

13. HoneyBadger TCP stream analysis tool