Showing blog posts from October 2016
time machine? Then your best chance is to install PacketCache, which allows you to read OLD packets with Wireshark.
We recently released a free tool for keeping a cache of recently sent/received network traffic in Windows. The tool, called PacketCache, is actually a Windows service that saves a copy of recent packets in RAM. The cached packets can be read simply by connecting to a named pipe called “PacketCache”, for example by using a PowerShell script as shown on the PacketCache page.
After talking to some Wireshark core developers at
last week we managed to get Wireshark to read packets from PacketCache's named pipe stream.
However, you will need to use Wireshark 2.3 or later to properly read from a named pipe.
Unfortunately version 2.3 isn't scheduled for release until next summer (2017),
so until then you'll have to use one of the automated builds instead.
I usually go for the latest WiresharkPortable build, since it doesn't require installation.
You can download the portable version of Wireshark 2.3 here:
Look for a file called “WiresharkPortable_2.3.[something].paf.exe”.
Follow these steps in order to read packets captured by PacketCache:
- Make sure you have Wireshark 2.3.0 (or later)
- Start Wireshark with admin rights (right-click > “Run as administrator”)
- Press: Capture > Options
- Click “Manage Interfaces...”
- Select the “Pipes” tab
- Press the “+” button to add a named pipe
- Name the pipe “\\.\pipe\PacketCache” and press ENTER to save it
- Press “OK” in the Manage Interface window.
- Press “Start” to read the packets from PacketCache
The status field in Wireshark will say “Live capture in progress”, which is somewhat true. Wireshark will be updating the GUI live as packets are read from PacketCache, but the packets displayed can be several hours or even days old depending on when they were captured by PacketCache. The “live” capture will stop once all packets have been read from the PacketCache.
Posted by Erik Hjelmvik on Friday, 28 October 2016 14:50:00 (UTC/GMT)
NSA's QUANTUM INSERT attack is probably the most well-known TCP packet injection attack due to the Snowden revelations regarding how GCHQ used this method to hack into Belgacom. However, the “Five Eyes” are not the only ones who perform this type of attack on the Internet. We now release a tool to help incident responders to find these types of packet injection attacks.
I had the opportunity to attend and present at SharkFest Europe last week. My presentation, titled “Dissecting Man-on-the-Side Attacks”, showed how TCP packet injection attacks can be analyzed if they have been recorded in a packet capture. In my talk I used a python script called “finject.py”, which reads PCAP files to find TCP packets with duplicate sequence numbers but different content. This script has previously only been shared with vetted parties, but as of my SharkFest presentation findject is now freely available for everyone.
Findject is not the first tool made available to detect TCP content injection attacks.
Other detection methods include Suricata's
python findject.py /nsm/pcap/live/*
opening /nsm/pcap/live/ppp0.150922_192034.pcap - no injections
PACKET INJECTION 220.127.116.11:80-192.168.1.254:59320 SEQ : 402877220
'HTTP/1.1 200 OK\r\nContent-Type: text/html\r\nContent-Length: 87\r\nConnection: close\r\n\r\n<html><head><meta http-equiv="refresh" content="0; url=\'http://id1.cn/\'"></head></html>'
opening /nsm/pcap/live/ppp0.150923_115034.pcap - no injections
opening /nsm/pcap/live/ppp0.150924_071617.pcap - no injections
In the example execution above we can see that findject.py detected an injected TCP packet in the file ppp0.150923_081337.pcap, while the other analyzed files contained no injections. The application layer data of the two conflicting TCP segments are printed to standard output with a header indicating whether the segment was the FIRST or LAST one. To find out which segment is the real one and which was the injected one we need to open the PCAP file in either Wireshark, tshark or CapLoader.
tshark -r /nsm/pcap/live/ppp0.150923_083317.pcap -Y "ip.src eq 18.104.22.168 and tcp.port eq 59320" -T fields -e frame.number -e ip.src -e ip.dst -e tcp.seq -e tcp.len -e ip.id -e ip.ttl -o "tcp.relative_sequence_numbers: false"
14 22.214.171.124 192.168.1.254 402877219 0 0x00002e36 94
25 126.96.36.199 192.168.1.254 402877220 726 0x00000d05 70
27 188.8.131.52 192.168.1.254 402877220 726 0x00000d05 69
28 184.108.40.206 192.168.1.254 402877220 170 0x00002e3e 94
The tshark execution above reveals that three packets sent from the web server's IP (220.127.116.11) are carrying data and have the same sequence number (402877220). Packet 25 and 27 are actually identical, while packet 28 is smaller (170 bytes) and has a different payload. The first displayed frame in the tshark output above is the SYN+ACK packet from the TCP 3-way handshake.
So how can we determine which of packets 25, 27 and 28 are real verses injected? Look at the IP-ID and IP-TTL values! Frame 28 has IP-ID and TTL values in line with what we see in the TCP 3-way handshake (TTL=94, IP-ID=0x00002e3e), which implies that this packet is probably authentic. Frames 25 and 27 on the other hand deviate from what we would expect from the server, which tells us that these packets were likely injected (spoofed) into the TCP session through a “man-on-the-side” attack.
To learn more about findject.py and download the tool, please visit: https://www.netresec.com/?page=findject
Example captures containing TCP content injection attacks can be found on our Publicly Available PCAP Files page under the “Packet Injection Attacks / Man-on-the-Side Attacks” section.
Posted by Erik Hjelmvik on Tuesday, 25 October 2016 08:45:00 (UTC/GMT)