Quantum Injection

Hacking Quantum Key Distribution via Injection Locking

Unconditionally secure communication, being pursued for thousands of years, however, hasn't been reached yet due to continuous competitions between encryption and hacking. Quantum key distribution (QKD), harnessing the quantum mechanical nature of superposition and non-cloning, may promise unconditional security by incorporating the one-time pad algorithm rigorously proved by Claude Shannon. Massive efforts have been made in building practical and commercial QKD systems, in particular, decoy states are employed to detect photon-number splitting attack against single-photon source loophole, and measurement-device-independent (MDI) QKD has further closed all loopholes in detection side, which leads to a seemingly real-life application. Here, we propose and experimentally demonstrate an MDI-QKD hacking strategy on the trusted source assumption by using injection locking technique. Eve injects near off-resonance photons in randomly chosen polarization into sender's laser, where injection locking in a shifted frequency can happen only when Eve's choice matches with sender's state. By setting a shifted window and switching the frequency of photons back afterwards, Eve in principle can obtain all the keys without terminating the real-time QKD. We observe the dynamics of a semiconductor laser with injected photons, and obtain a hacking success rate reaching 60.0% of raw keys. Our results suggest that the spear-and-shield competitions on unconditional security may continue until all potential loopholes are discovered and closed ultimately.

 

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’, such as a persistent tracking cookie that identifies a user for a longer period of time.

 

This project is in a MOSTLY working state. It does all that should be expected EXCEPT that browsers won't display the injected responses from quantum-inject.py. Use at your own risk.

Instructions to install dependencies

scapy - Visit http://secdev.org/projects/scapy/doc/installation.html and follow instructions for scapy 2.x

Usages:

Injector:

python quantum-inject.py -i network_interface -r regex -d filepath filter_expression

filter_expression MUST be surrounded by quotation marks

Detector:

python quantum-detect.py -i network_interface -r filepath filter_expression

filter_expression MUST be surrounded by quotation marks


 

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’, such as a persistent tracking cookie that identifies a user for a longer period of time.


 

Deep dive into QUANTUM INSERT

 

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.
 

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.

 

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. 

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[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).

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.

 

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.

 

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.

 

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.

 

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 describes how to perform QI containing Proof of Concept code to perform the attack.

 

HoneyBadger, 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, 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.

 

How to Detect Sneaky NSA 'Quantum Insert' Attacks

AMONG ALL OF the NSA hacking operations exposed by whistleblower Edward Snowden over the last two years, one in particular has stood out for its sophistication and stealthiness. Known as Quantum Insert, the man-on-the-side hacking technique has been used to great effect since 2005 by the NSA and its partner spy agency, Britain's GCHQ, to hack into high-value, hard-to-reach systems and implant malware.

 

Quantum Insert is useful for getting at machines that can't be reached through phishing attacks. It works by hijacking a browser as it's trying to access web pages and forcing it to visit a malicious web page, rather than the page the target intend to visit. The attackers can then surreptitiously download malware onto the target's machine from the rogue web page.

 

Quantum Insert has been used to hack the machines of terrorist suspects in the Middle East, but it was also used in a controversial GCHQ/NSA operation against employees of the Belgian telecom Belgacom and against workers at OPEC, the Organization of Petroleum Exporting Countries. The "highly successful" technique allowed the NSA to place 300 malicious implants on computers around the world in 2010, according to the spy agency's own internal documents---all while remaining undetected.

 

But now security researchers with Fox-IT in the Netherlands, who helped investigate that hack against Belgacom, have found a way to detect Quantum Insert attacks using common intrusion detection tools such as Snort, Bro and Suricata.

 

The detection focuses on identifying anomalies in the data packets that get sent to a victim's browser client when the browser attempts to access web pages. The researchers, who plan to discuss their findings at the RSA Conference in San Francisco today, have written a blog post describing the technical details and are releasing custom patches for Snort to help detect Quantum Insert attacks.

 

How Quantum Insert Works

According to various documents leaked by Snowden and published by The Intercept and the German newspaper Der Spiegel, Quantum Insert requires the NSA and GCHQ to have fast-acting servers relatively near a target's machine that are capable of intercepting browser traffic swiftly in order to deliver a malicious web page to the target's machine before the legitimate web page can arrive.

 

To achieve this, the spy agencies use rogue systems the NSA has codenamed FoxAcid servers, as well as special high-speed servers known as "shooters," placed at key points around the internet.

 

In the Belgacom hack, GCHQ first identified specific engineers and system administrators who worked for the Belgian telecom and one of its subsidiaries, BICS. The attackers then mapped out the digital footprints of chosen workers, identifying the IP addresses of work and personal computers as well as Skype, Gmail and social networking accounts such as Facebook and LinkedIn. Then they set up rogue pages, hosted on FoxAcid servers, to impersonate, for example, an employee's legitimate LinkedIn profile page.

 

The agencies then used packet-capturing tools that sniffed or sifted through internet traffic---which can occur with the cooperation of telecoms or without it---to spot footprints or other markers that identified the online traffic of these targets. Sometimes the fingerprints involved spotting persistent tracking cookies that web sites assigned to the user.

 

When the sniffers spotted a "GET request" from a target's browser---messages sent by the browser to call up a specific URL or web page such as the user's LinkedIn profile page---it would notify the NSA's high-speed shooter server, which would then kick into action and send a redirect or "shot" to the browser. That shot was essentially a spoofed Transmission Control Protocol (TCP) packet that would redirect the user's browser to a malicious LinkedIn page hosted on a FoxAcid server. The FoxAcid server would then download and install malware on the victim's machine.

 

Quantum Insert attacks require precise positioning and action on the part of the rogue servers to ensure that they "win" the race to redirect and serve up a malicious page faster than the legitimate servers can deliver a page to the browser. The closer the traffic-sniffing and shooter machines are to the target, the more likely the rogue servers will "win" the race to the victim's machine. According to one NSA document from 2012, the success rate per shot for LinkedIn pages was "greater than 50 percent."

 

 

How to Catch a Quantum Insert

But hidden within another document leaked by Snowden was a slide that provided a few hints about detecting Quantum Insert attacks, which prompted the Fox-IT researchers to test a method that ultimately proved to be successful. They set up a controlled environment and launched a number of Quantum Insert attacks against their own machines to analyze the packets and devise a detection method.

 

According to the Snowden document, the secret lies in analyzing the first content-carrying packets that come back to a browser in response to its GET request. One of the packets will contain content for the rogue page; the other will be content for the legitimate site sent from a legitimate server. Both packets, however, will have the same sequence number. That, it turns out, is a dead giveaway.

 

Here's why: When your browser sends a GET request to pull up a web page, it sends out a packet containing a variety of information, including the source and destination IP address of the browser as well as so-called sequence and acknowledge numbers, or ACK numbers. The responding server sends back a response in the form of a series of packets, each with the same ACK number as well as a sequential number so that the series of packets can be reconstructed by the browser as each packet arrives to render the web page.

 

But when the NSA or another attacker launches a Quantum Insert attack, the victim's machine receives duplicate TCP packets with the same sequence number but with a different payload. "The first TCP packet will be the 'inserted' one while the other is from the real server, but will be ignored by the [browser]," the researchers note in their blog post. "Of course it could also be the other way around; if the QI failed because it lost the race with the real server response."

 

Although it's possible that in some cases a browser will receive two packets with the same sequence number from a legitimate server, they will still contain the same general content; a Quantum Insert packet, however, will have content with significant differences. The researchers have detailed in their blog post other anomalies that can help detect a Quantum Insert attack. And in addition to making patches available for Snort to detect Quantum Insert attacks, they have also posted packet captures to their GitHub repository to show how they performed Quantum Insert attacks.

 

QI Tools

Proof of concept tools to perform a QUANTUMINSERT. Our Lab setup consisted of the following VMs:

qi-shooter (VM that will run shooter.py)

qi-router (VM that will run monitor.py)

qi-target (VM that will be attacked)

 

This script is intended to leak the TCP sequence and ACK numbers to the shooter.py. It has a dependency on tcpdump or tshark as it receives the sequence and ack numbers from the output of these programs. It's possible to implement packet capture in monitor.py itself, making it probably even faster to leak the required information.

The information is sent to the shooter using a single UDP packet. However, one could use other ways to do this.

 

Example usage for tcpdump

stdbuf --output=0 | tcpdump -nn -i eth0 "host jsonip.com and tcp[tcpflags]=(tcp-syn|tcp-ack)" | python monitor.py -s 10.0.0.2 -p 12345

stdbuf is needed as tcpdump will buffer it's output by default. The bpf filter ensures that we only see the SYN+ACK of jsonip.com, which will be printed to stdout and parsed by monitor.py. The shooter is then notified at 10.0.0.2 running on port 12345.

 

Example usage for tshark

By using tshark one could specifically target a client, for example by identifying a client by it's unique Cookie headers.

 

Example command:

stdbuf --output=0 tshark -ni eth0 -Tfields \ -e tcp.seq -e tcp.ack \ -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport \ -e tcp.analysis.bytes_in_flight -e http.host -e 'http.cookie' \ -o tcp.relative_sequence_numbers:0 -R http.request \ 'host jsonip.com and port 80' | python monitor.py -s 10.0.0.2 -p 12345 --tshark

 

This command will output the required fields when someone makes a HTTP request to jsonip.com. The outputted cookie and host fields could be used as selectors in the monitor script.

The -o tcp.relative_sequence_numbers:0 option is needed to output non relative sequence numbers.

shooter.py

 

This script is responsible for receiving the sequence+ack data from monitor.py using UDP. It has a dependency on Scapy for crafting and sending the spoofed packet.

 

Example usage:

python shooter.py -l 10.0.0.2 -p 12345

 

This will make the shooter script listen on 10.0.0.2 and on port 12345.

 

Effective Date.

This Privacy Policy is effective as of November 25th, 2020

 

Contact E-Mail.

You may contact us concerning this Privacy Policy by using any of the contact options shown on this site.

 

info@cissco.se