NETRESEC Network Security Blog - Tag : TCP


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://www.netresec.com/files/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:

CapLoader Flow Transcript of race between hao.360.cn and hao123.com
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:
    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:

Browser showing www.hao123.com when trying to visit 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

Browser showing hao.360.cn when using SSL to visit www.02995.com


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.

Website blocked message from Alibaba Group

We have decided to also share a PCAP file containing a packet injection attack for id1.cn here:
https://www.netresec.com/files/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:

Browsers tab in NeworkMiner Professional 2.0
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

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=163E02B


Covert Man-on-the-Side Attacks

Man-on-the-Side

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.

Man-on-the-Side Explained A Man-on-the-Side (MOTS) attack has the following two characteristics:
  • The attacker can read the traffic and insert new messages, but not to modify or delete messages sent by other participants.
  • The attacker relies on a timing advantage to make sure that the response he sends to the request of a victim arrives before the legitimate response.

In practice this means that the attacker relies on packet injection to insert a TCP packet with a payload to be executed by the victim, such as an HTTP redirect to a malicious web site (source The Intercept). The TCP sequence number of this injected packet will typically be the same as that in the real HTTP response coming from the legitimate web server. Thus, the end node will see two overlapping TCP segments with different application layer data.

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

Frame number 5 is the injected “302 Found” packet spoofed by the attacker. The TCP flag value 0x19 translates to FIN+PUSH+ACK, which is the attackers attempt to tear-down the TCP connection. The client responds with a FIN+ACK (0x11) in frame 8. The final frame is the real HTTP response coming from the legitimate web server.


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.

HoneyBadger detecting an injected TCP packet with FIN flag Image: HoneyBadger detecting injected packet in the mots-with-fin.pcap file we released.

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".

findject logo

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

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

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=1598A63


CapLoader Video Tutorial

CapLoader Logo

Below is a short video tutorial showing some of the cool features in CapLoader 1.0.

The functionality showed in the video includes:

  • Loading multiple pcap files into a single flow view
  • Port Independent Protocol Identification (PIPI)
  • Fast extraction of packets related to one or several flows
  • Exporting packets to Wireshark and NetworkMiner
  • Drag-and-dropping packets to Wireshark
  • Selecting a flow based on an IDS alert from Snort
  • Extracting packets from a selected flow to a new pcap file

The video can also be seen on YouTube at the following URI:
http://youtu.be/n1Ir9Hedca4?hd=1

The three pcap files loaded in the video tutorial are from the DFRWS 2009 Challenge.

Enjoy!

Posted by Erik Hjelmvik on Monday, 30 April 2012 14:35:00 (UTC/GMT)

Tags: #CapLoader #Video #Pcap #Wireshark #NetworkMiner #Flow #TCP #Extract #Fast

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=124DA49


Pcap-over-IP in NetworkMiner

Pcap over IP network protocol stack

Version 1.1 of NetworkMiner is soon to be released by us at Netresec. I would therefore like to give you a sneak preview of a simple yet very useful feature that we've added. We call this new feature “Pcap-over-IP”, which is a name originally coined by Packet Forensics.

With Pcap-over-IP you can have NetworkMiner read a pcap file (or libpcap formatted data in general) or over a TCP socket instead of getting it via the file system. The easiest way to send a pcap file over a TCP socket is to pipe a pcap file to netcat like this:

# cat sniffed.pcap | nc 192.168.1.20 57012

In this example I'd be running NetworkMiner on a PC with IP 192.168.1.20 and have Pcap‑over‑IP listening to TCP port 57012. NetworkMiner will save the received packets to disk as well as parse and display the contents of the packets in the GUI when receiving the Pcap‑over‑IP stream.

NetworkMiner receiving Pcap-over-IP data

Pcap-over-IP also allows me to do live network sniffing with dumpcap from my local Windows machine and pipe the captured packets to NetworkMiner via a TCP socket, using Netcat for Windows like this:

C:\Program Files\Wireshark>dumpcap -i 4 -P -w - | C:\Tools\Netcat\nc.exe 127.0.0.1 57012

Note that the “-w -” switch tells dumpcap to push the raw libpcap formated data to standard output (stdout) rather than saving it to a pcap file.

The reason for using dumcap to perform the live sniffing rather than using the built in packet capturing functionality of NetworkMiner is that dumpcap is an extremely reliably tool when it comes to capturing packets. So by sniffing with dumpcap instead of NetworkMiner you minimize the risk of dropping some packets.

I can also use Pcap-over-IP to capture network traffic from a remote PC or device. I can, for example use tcpdump to sniff traffic on the external interface of my Linux-based firewall and push it to an analyst station like this:

# tcpdump -i eth1 -s 0 -U -w - | nc 192.168.1.20 57012

I can also perform remote WiFi sniffing with dumpcap or tcpdump from a Linux machine and send the sniffed packets to NetworkMiner with netcat like this:

# iwconfig wlan0 mode monitor
# iwconfig wlan0 channel 4
# dumpcap -i wlan0 -P -w - | nc 192.168.1.20 57012

It is even possible to receive multiple PCAP streams simultaneously with NetworkMiner. This way I could have 14 dumpcap or tcpdump processes sniffing each individual IEEE 802.11 channel, while monitoring all the captured traffic in real-time with a single instance of NetworkMiner. However, note that this would require 14 sniffer computers or a single sniffer machine with 14 WiFi cards.

SSL encryption

Don't like sending your pcap files in cleartext over the network? That's just fine, we've also implemented support for SSL/TLS encryption in NetworkMiner. You can use the great multipurpose relay tool socat to read your pcap file and have it encrypted with SSL while transiting the network like this:

# socat GOPEN:sniffed.pcap SSL:192.168.1.20:57013,verify=0

You can also use socat when doing live sniffing like this:

# tcpdump -i br0 -s 0 -U -w - | socat - SSL:192.168.1.20:57013,verify=0

Warning: Always make sure you don't sniff your own Pcap-over-IP stream when sending packets to NetworkMiner. You will otherwise construct a feedback loop, which will fill up the tubes. If you need to sniff the same interface as you are using to perform the Pcap‑over‑IP transfer, then make sure to use BPF to filter out the port number used for your Pcap‑over‑IP transfer like this:

# tcpdump -i ppp0 -U -w - not port 57012 | nc 192.168.1.20 57012

UPDATE June 16, 2014

With the release of NetworkMiner 1.6 we've made the PCAP‑over‑IP functionality available in the free open source edition of NetworkMiner. We have also integrated PCAP‑over‑IP into NetworkMinerCLI, i.e. the command line version of NetworkMiner Professional.

Posted by Erik Hjelmvik on Wednesday, 07 September 2011 09:22:00 (UTC/GMT)

Tags: #Netresec #Pcap-over-IP #Pcap #tcpdump #dumpcap #TCP #SSL #TLS

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=119B126

twitter

NETRESEC on Twitter

Follow @netresec on twitter:
» twitter.com/netresec


book

Recommended Books

» The Practice of Network Security Monitoring, Richard Bejtlich (2013)

» Applied Network Security Monitoring, Chris Sanders and Jason Smith (2013)

» Network Forensics, Sherri Davidoff and Jonathan Ham (2012)

» The Tao of Network Security Monitoring, Richard Bejtlich (2004)

» Practical Packet Analysis, Chris Sanders (2017)

» Windows Forensic Analysis, Harlan Carvey (2009)

» TCP/IP Illustrated, Volume 1, Kevin Fall and Richard Stevens (2011)

» Industrial Network Security, Eric D. Knapp and Joel Langill (2014)