Packet Injection Attacks in the Wild
I have previously blogged about packet injection attacks, such as the Chinese DDoS of GitHub and Covert Man-on-the-Side Attacks. However, this time I've decided to share some intelligence on real-world packet injection attacks that have been running for several months and that are still active today.
Packet Injection by Network Operators
Gabi Nakibly, Jaime Schcolnik and Yossi Rubin recently released a very interesting research paper titled “Website-Targeted False Content Injection by Network Operators”, where they analyzed packet injection attacks in the wild. Here's a snippet from the paper's abstract:
It is known that some network operators inject false content into users’ network traffic. Yet all previous works that investigate this practice focus on edge ISPs (Internet Service Providers), namely, those that provide Internet access to end users. Edge ISPs that inject false content affect their customers only. However, in this work we show that not only edge ISPs may inject false content, but also core network operators. These operators can potentially alter the traffic of all Internet users who visit predetermined websites.
The researchers analyzed 1.4 petabits of HTTP traffic, captured at four different locations; three universities and one corporation.
Some of their findings have been made available as anonymized PCAP files here:
We have attempted to recreate these packet injections by visiting the same URLs again. Unfortunately most of our attempts didn't generate any injected responses, but we did manage to trigger injections for two of the groups listed by Nakibly et al. (“hao” and “GPWA”).
Redirect Race between hao.360.cn and hao123.com
We managed to get very reliable packet injections when visiting the website www.02995.com.
We have decided to share one such PCAP file containing a packet injection attack here:
This is what it looks like when loading that PCAP file into CapLoader and doing a “Flow Transcript” on the first TCP session:
Image: CapLoader Flow Transcript (looks a bit like Wireshark's Follow-TCP-Stream)
We can see in the screenshot above that the client requests http://www.02995.com/ and receives two different responses with the same sequence number (3820080905):
- The first response is a “302 Found”, forwarding the client to:
- The second response is a “302 Moved Temporarily”, that attempts a redirect to:
Judging from the IP Time-To-Live (TTL) values we assume that the first response (hao123.com) was an injected packet, while the second response (hao.360.cn) was coming from the real webserver for www.02995.com.
If you have an eye for details, then you might notice that the injected packet doesn't use the standard CR-LF (0x0d 0x0a) line breaks in the HTTP response. The injected packet only uses LF (0x0a) as line feed in the HTTP header.
Since the injected response arrived before the real response the client followed the injected redirect to www.hao123.com. This is what the browser showed after trying to load www.02995.com:
SSL encryption is an effective protection against packet injection attacks. So if the user instead enters https://www.02995.com then the browser follows the real redirect to hao.360.cn
id1.cn redirected to batit.aliyun.com
Prior to the release of Gabi's packet injection paper, the only publicly available PCAP file showing a real-world packet injection was this one:
That PCAP file was released after Yun Zheng Hu (of Fox-IT) gave a presentation titled “Detecting Quantum Insert” at BroCon 2015. A video recording of Yun Zheng's talk is available online, including a live demo of the packet injection.
We have managed to re-trigger this packet injection attack as well, simply by visiting http://id1.cn. Doing so triggers two injected HTTP responses that attempts to do a redirect to http://batit.aliyun.com/alww.html. The target page of the injected responses has a message from the Alibaba Group (aliyun.com) saying that the page has been blocked.
We have decided to also share a PCAP file containing a packet injection attack for id1.cn here:
This is what it looks like when that PCAP file is loaded into NetworkMiner Professional, and the Browsers tab is opened in order to analyze the various HTTP redirections:
Image: Browsers tab in NetworkMiner Professional 2.0
Here's a short recap of what is happening in our shared PCAP file for id1.cn:
- Frame 13 : http://id1.cn is opened
- Frame 18 : Real server responds with an HTML refresh leading to http://id1.cn/rd.s/Btc5n4unOP4UrIfE?url=http://id1.cn/
- Frame 20 : The client also receives two injected packets trying to do a “403 Forbidden” that redirects to http://batit.aliyun.com/alww.html. However, these injected packets arrived too late.
- Frame 24 : The client proceeds by loading http://id1.cn/rd.s/Btc5n4unOP4UrIfE?url=http://id1.cn/
- Frame 25 : Two new injected responses are sent, this time successfully redirecting the client to the Alibaba page.
- Frame 28 : The real response arrives too late.
- Frame 43 : The client opens the Alibaba page with message about the site being blocked
Protecting against Packet Injection Attacks
The best way to protect against TCP packet injection attacks is to use SSL encryption. Relying on HTTP websites to do a redirect to an HTTPS url isn't enough, since that redirect could be targeted by packet injection. So make sure to actually type “https://” (or use a browser plug-in) in order to avoid being affected by injected TCP packets.
Referenced Capture Files
The following PCAP files have been referenced in this blog post:
For more PCAP files, please visit our list of publicly available PCAP files here: https://www.netresec.com/?page=PcapFiles
Posted by Erik Hjelmvik on Tuesday, 01 March 2016 13:37:00 (UTC/GMT)
Tags: #NetworkMiner #HTTP #browser #CapLoader #MOTS #HTTPS #TCP #PCAP