BlackNurse Denial of Service Attack

Remember the days back in the 90s when you could cripple someones Internet connection simply by issuing a few PING command like “ping -t [target]”? This type of attack was only successful if the victim was on a dial-up modem connection. However, it turns out that a similar form of ICMP flooding can still be used to perform a denial of service attack; even when the victim is on a gigabit network.

The 90's called and wanted their ICMP flood attack back

Analysts at TDC-SOC-CERT (Security Operations Center of the Danish telecom operator TDC) noticed how a certain type of distributed denial-of-service (DDoS) attacks were more effective than others. The analysts found that a special type of ICMP flooding attack could disrupt the network throughput for some customers, even if the attack was just using a modest bandwidth (less than 20Mbit/s). It turned out that Destination Unreachable ICMP messages (ICMP type 3), such as “port unreachable” (code 3) was consuming significantly more resources on some firewalls compared to the more common ICMP Echo messages associated with the Ping command. The TDC team have dubbed this particular ICMP flooding attack method “BlackNurse”.

TDC's own report about BlackNurse says:

“The BlackNurse attack attracted our attention, because in our anti-DDoS solution we experienced that even though traffic speed and packets per second were very low, this attack could keep our customers' operations down. This even applied to customers with large internet uplinks and large enterprise firewalls in place.”

Cisco ASA firewalls is one product line that can be flooded using the BlackNurse attack. Cisco were informed about the BlackNurse attack in June this year, but they decided to not classify this vulnerability as a security issue. Because of this there is no CVE or other vulnerability number associated with BlackNurse.

Evaluation of BlackNurse Denial-of-Service Attacks

Members of the TDC-SOC-CERT set up a lab network to evaluate how effective ICMP type 3 attacks were compared to other ICMP flooding methods. In this setup they used hping3 to send ICMP floods like this:

• ICMP net unreachable (ICMP type 3, code 0):
  hping3 --icmp -C 3 -K 0 --flood [target]
• ICMP port unreachable (ICMP type 3, code 3) a.k.a. “BlackNurse”:
  hping3 --icmp -C 3 -K 3 --flood [target]
• ICMP Echo (Ping):
  hping3 --icmp -C 8 -K 0 --flood [target]
• ICMP Echo with code 3:
  hping3 --icmp -C 8 -K 3 --flood [target]

The tests showed that Cisco ASA devices used more CPU resources to process the destination unreachable flood attacks (type 3) compared to the ICMP Echo traffic. As a result of this the firewalls start dropping packets, which should otherwise have been forwarded by the firewall, when hit by a BlackNurse attack. When the packet drops become significant the customer behind the firewall basically drops off the internet.

The tests also showed that a single attacking machine running hping3 could, on its own, produce enough ICMP type 3 code 3 packets to consume pretty much all the firewall's resources. Members of the TDC-SOC-CERT shared a few PCAP files from their tests with me, so that their results could be verified. One set of these PCAP files contained only the attack traffic, where the first part was generated using the following command:

hping3 --icmp -C 3 -K 3 -i u200 [target]

The “-i u200” in the command above instructs hping3 to send one packet every 200 microseconds. This packet rate can be verified simply by reading the PCAP file with a command like this:

tshark -c 10 -r attack_record_00001.pcapng -T fields -e frame.time_relative -e frame.time_delta -e frame.len -e icmp.type -e icmp.code
0.000000000   0.000000000   72   3   3
0.000207000   0.000207000   72   3   3
0.000415000   0.000208000   72   3   3
0.000623000   0.000208000   72   3   3
0.000830000   0.000207000   72   3   3
0.001038000   0.000208000   72   3   3
0.001246000   0.000208000   72   3   3
0.001454000   0.000208000   72   3   3
0.001661000   0.000207000   72   3   3
0.001869000   0.000208000   72   3   3

The tshark output confirms that hping3 sent an ICMP type 3 code 3 (a.k.a. “port unreachable”) packet every 208 microseconds, which amounts to rougly 5000 packets per second (pps) or 2.7 Mbit/s. We can also use the capinfos tool from the wireshark/tshark suite to confirm the packet rate and bandwidth like this:

capinfos attack_record_00001.pcapng
Number of packets:   48 k
File size:           5000 kB
Data size:           3461 kB
Capture duration:    9.999656 seconds
First packet time:   2016-06-08 12:25:19.811508
Last packet time:    2016-06-08 12:25:29.811164
Data byte rate:      346 kBps
Data bit rate:       2769 kbps
Average packet size: 72.00 bytes
Average packet rate: 4808 packets/s

A few minutes later they upped the packet rate, by using the “--flood” argument, instead of the 200 microsecond inter-packet delay, like this:

hping3 --icmp -C 3 -K 3 --flood [target]

capinfos attack_record_00007.pcapng
Number of packets:   3037 k
File size:           315 MB
Data size:           218 MB
Capture duration:    9.999996 seconds
First packet time:   2016-06-08 12:26:19.811324
Last packet time:    2016-06-08 12:26:29.811320
Data byte rate:      21 MBps
Data bit rate:       174 Mbps
Average packet size: 72.00 bytes
Average packet rate: 303 kpackets/s

The capinfos output reveals that hping3 was able to push a whopping 303.000 packets per second (174 Mbit/s), which is way more than what is needed to overload a network device vulnerable to the BlackNurse attack. Unfortunately the PCAP files I got did not contain enough normal Internet background traffic to reliably measure the degradation of the throughput during the denial of service attack, so I had to resort to alternative methods. The approach I found most useful for detecting disruptions in the network traffic was to look at the roundtrip times of TCP packets over time.

The graph above measures the time between a TCP data packet and the ACK response of that data segment (called “tcp.analysis.ack_rtt” in Wireshark). The graph shows that the round trip time only rippled a little due to the 5000 pps BlackNurse attack, but then skyrocketed as a result of the 303 kpps flood. This essentially means that “normal” traffic was was prevented from getting though the firewall until the 303 kpps ICMP flood was stopped. However, also notice that even a sustained attack of just 37 kpps (21 Mbit/s or 27 μs inter-packet delay) can be enough to take a gigabit firewall offline.

Detecting BlackNurse Attacks

TDC-SOC-CERT have released the following SNORT IDS rules for detecting the BlackNurse attack:

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"TDC-SOC - Possible BlackNurse attack from external source "; itype:3; icode:3; detection_filter:track by_dst, count 250, seconds 1; reference:url, soc.tdc.dk/blacknurse/blacknurse.pdf; metadata:TDC-SOC-CERT,18032016; priority:3; sid:88000012; rev:1;)

alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg:"TDC-SOC - Possible BlackNurse attack from internal source"; itype:3; icode:3; detection_filter:track by_dst, count 250, seconds 1; reference:url, soc.tdc.dk/blacknurse/blacknurse.pdf; metadata:TDC-SOC-CERT,18032016; priority:3; sid:88000013; rev:1;)

Protecting against BlackNurse Attacks

The recommendation from TDC is to deny ICMP type 3 messages sent to the WAN interface of Cisco ASA firewalls in order to prevent the BlackNurse attack. However, before doing so, please read the following excerpt from the Cisco ASA 5500 Series Command Reference:

“We recommend that you grant permission for the ICMP unreachable message type (type 3). Denying ICMP unreachable messages disables ICMP Path MTU discovery, which can halt IPSec and PPTP traffic. See RFC 1195 and RFC 1435 for details about Path MTU Discovery.”

In order to allow Path MTU discovery to function you will need to allow at least ICMP type 3 code 4 packets (fragmentation needed) to be received by the firewall. Unfortunately filtering or rate-limiting on a Cisco ASA does not seem to have an affect against the BlackNurse attack, the CPU max out anyway. Our best recommendation for protecting a Cisco ASA firewall against the BlackNurse attack is therefore to rate-limit incoming ICMP traffic on an upstream router.

Another alternative is to upgrade the Cisco ASA to a more high-end one with multiple CPU cores, since the BlackNurse attack seems to not be as effective on muti-core ASA's. A third mitigation option is to use a firewall from a different vendor than Cisco. However, please note that it's likely that other vendors also have products that are vulnerable to the BlackNurse attack.

To learn more about the BlackNurse attack, visit blacknurse.dk or download the full BlackNurse report from TDC.

Update November 12, 2016

Devices verified by TDC to be vulnerable to the BlackNurse attack:

• Cisco ASA 5505, 5506, 5515, 5525 and 5540 (default settings)
• Cisco ASA 5550 (Legacy) and 5515-X (latest generation)
• Cisco 897 router
• Cisco 6500 router (with SUP2T and Netflow v9 on the inbound interface)
• Fortigate 60c and 100D (even with drop ICMP on). See response from Fortinet.
• Fortinet v5.4.1 (one CPU consumed)
• Palo Alto (unless ICMP Flood DoS protection is activated). See advisory from Palo Alto.
• SonicWall (if misconfigured)
• Zyxel NWA3560-N (wireless attack from LAN Side)
• Zyxel Zywall USG50

Update November 17, 2016

There seems to be some confusion/amusement/discussion going on regarding why this attack is called the “BlackNurse”. Also, googling “black nurse” might not be 100 percent safe-for-work, since you risk getting search results with inappropriate videos that have nothing to do with this attack.

The term “BlackNurse”, which has been used within the TDC SOC for some time to denote the “ICMP 3,3” attack, is actually referring to the two guys at the SOC who noticed how surprisingly effective this attack was. One of these guys is a former blacksmith and the other a nurse, which was why a college of theirs jokingly came up with the name “BlackNurse”. However, although it was first intended as a joke, the team decided to call the attack “BlackNurse” even when going public about it.

Posted by Erik Hjelmvik on Thursday, 10 November 2016 07:40:00 (UTC/GMT)

Tags: #tshark​

Reading cached 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 SharkFest Europe 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:
https://www.wireshark.org/download/automated/win32/

Look for a file called “WiresharkPortable_2.3.[something].paf.exe”.

Follow these steps in order to read packets captured by PacketCache:

1. Make sure you have Wireshark 2.3.0 (or later)
2. Start Wireshark with admin rights (right-click > “Run as administrator”)

3. Press: Capture > Options
4. Click “Manage Interfaces...”
5. Select the “Pipes” tab
6. Press the “+” button to add a named pipe
7. Name the pipe “\\.\pipe\PacketCache” and press ENTER to save it

8. Press “OK” in the Manage Interface window.

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

Tags: #Netresec​ #PCAP​ #PacketCache​ #Wireshark​ #named pipe​ #SharkFest​

Detect TCP content injection attacks with findject

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 reassembly_overlap_different_data alert, Fox-IT's Bro policy to check for inconsistencies in the first packet with payload, David Stainton's HoneyBadger and Martin Bruse's qisniff. Even though these are all great solutions we found that some of them didn't detect all TCP content injection attacks while others gave too many false positives. We also wanted to have a tool that was fast, portable and simple to use. This led us to create our own TCP injection detection tool.

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.

The tshark execution above reveals that three packets sent from the web server's IP (42.96.141.35) 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.

You can also read our blog posts Covert Man-on-the-Side Attacks and Packet Injection Attacks in the Wild to learn more about TCP packet injection attacks.

Posted by Erik Hjelmvik on Tuesday, 25 October 2016 08:45:00 (UTC/GMT)

Tags: #Netresec​ #PCAP​ #packet injection​ #find​ #python​ #SharkFest​

PacketCache lets you Go Back in Time

Have you ever wanted to go back in time to get a PCAP of something strange that just happened on a PC?
I sure have, many times, which is why we are now releasing a new tool called PacketCache. PacketCache maintains a hive of the most important and recent packets, so that they can be retrieved later on, if there is a need.

Network forensics and incident response is performed post-event, but requires that packet have already been captured during the event to be analyzed. Starting a network sniffer after a suspected intrusion might provide useful insight on what the intruders are up to, but it is much better to be able to go back in time to observe how they gained access to the network and what they did prior to being detected. Many companies and organizations combat this problem by setting up one or several solutions for centralized network packet capturing. These sniffers are typically installed at choke-points on the network, such as in-line with a firewall. However, this prevents the sniffers from capturing network traffic going between hosts on the same local network. Intruders can therefore often perform lateral movement on a compromised network without risk getting their steps captured by a packet sniffer.

Image by Game Gavel

By default PacketCache reserves 1% of a computer's total physical memory for storing packets. A computer with 4 GB of RAM will thereby allow up to 40 MB of packets to be kept in memory. This might not seem like much, but PacketCache relies on a clever technique that allows it to store only the most important packets. With this technique just 40 MB of storage can be enough to store several days worth of “important” packets.

The “clever technique” we refer to is actually a simple way of removing packets from TCP and UDP sessions as they get older. This way recent communication can be retained in full, while older data us truncated at the end (i.e. only the last packets are removed from a session).

To download PacketCache or learn more about this new tool, please visit the official PacketCache page:
https://www.netresec.com/?page=PacketCache

PCAP or it didn't happen!

Posted by Erik Hjelmvik on Wednesday, 28 September 2016 11:45:00 (UTC/GMT)

Tags: #PacketCache​ #PCAP​ #NSM​ #forensics​ #Windows​ #sniffer​ #memory​ #DFIR​

Bug Bounty PCAP T-shirts

As of today we officially launch the 'Netresec Bug Bounty Program'. Unfortunately we don't have the financial muscles of Microsoft, Facebook or Google, so instead of money we'll be giving away t-shirts.

To be awarded with one of our 'PCAP or it didn't happen' t-shirts you will have to:

• Be able to reliably crash the latest version of NetworkMiner or CapLoader, or at least make the tool misbehave in some exceptional way.
• Send a PCAP file that can be used to trigger the bug to info[at]netresec.com.

Those who find bugs will also receive an honorable mention in our blog post covering the release of the new version containing the bug fix.

Additionally, submissions that play a key-role in mitigating high-severity security vulnerabilities or addressing very important bugs will be awarded with a free license of either NetworkMiner Professional or the full commercial version of CapLoader.

Happy BugBounty Hunting!

Posted by Erik Hjelmvik on Tuesday, 27 September 2016 09:27:00 (UTC/GMT)

Tags: #NetworkMiner​ #CapLoader​ #PCAP​ #Netresec​

Detecting Periodic Flows with CapLoader 1.4

I am happy to announce a new release of our super-fast PCAP handling tool CapLoader! One of the new features in CapLoader makes it even easier to detect malicious network traffic without having to rely on blacklists, such as IDS signatures.

The new version of CapLoader includes new features such as:

• Services Tab (more details below)
• Input filter to limit number of parsed frames
• Flow Transcript in Hosts and Services tabs
• Keyword filtering
• Full filtering capability for all tabs
• Wireshark style coloring of flows, services and hosts

Services Tab

The biggest addition to version 1.4 of CapLoader is the Services tab, which presents a somewhat new way of aggregating the flows found in a PCAP file. Each row (or “service”) in the services tab represents a unique combination of <Client-IP, Server-IP, Server-port and Transport-protocol>. This means that if a single host makes multiple DNS requests to 8.8.8.8, then all those flows will be merged together as one row in the services tab.

This view makes it easy to see if a host is frequently accessing a particular network service. CapLoader even shows if the requests are made with regular intervals, in which case we measure the regularity and determine the most likely period between connections. The idea for measuring regularity comes from Sebastian Garcia's Stratosphere IPS, which can identify botnets by analyzing the periodicity of flows going to a C2 server.

Malware Example: Kovter.B

Here's what the Services tab looks like when loading 500 MB of PCAP files from a network where one of the hosts has been infected with malware (Win32/Kovter.B).

The services in the screenshot are sorted on the “Regularity” column, so that the most periodic ones are shown at the top. Services with a regularity value greater than 20 can be treated as periodic. In our case we see the top two services having a regularity of 36.9 with an estimated period of roughly 6h 2min. We can visualize the periodic behavior by opening the flows for those two services in a new instance if CapLoader. To do this, simply select the two services' rows, right-click the PCAP icon (in the top-right corner) and select “Open With > CapLoader 1.4.0.0”

As you can see in the flows tab, these services are accessed by the client on a regular interval of about 6h 2min. Doing a flow transcript of one such flow additionally reveals that the payload seems suspicious (not HTTP on TCP 80).

Image: Kovter.B malware trying to communicate with a C2 server

The Kovter malware failed to reach the C2 server in the attempt above, but there is a successful connection going to a C2 server at 12.25.99.131 every 3'rd hour (see service number 8 in the list of the most periodically accessed services). Here's a flow transcript of one such beacon:

Image: Kovter.B malware talking to C2 server at 12.25.99.131

Legitimate Periodic Services

Seven out of the 10 most periodically accessed services are actually caused by the Kovter malware trying to reach various C2 servers. The three most periodically accessed services that aren't malicious are:

• Service #3 is a legitimate Microsoft service (SeaPort connecting to toolbar.search.msn.com.akadns.net)
• Service #5 is a mail client connecting to the local POP3 server every 30 minutes.
• Service #6 is Microsoft-CryptoAPI updating its Certificate Revocation List from crl.microsoft.com every 5 hours.

Signature-Free Intrusion Detection

As shown in this blog post, analyzing the regularity of services is an efficient way of detecting C2 beacons without having to rely on IDS signatures. This method goes hand-in-hand with our Rinse-Repeat Intrusion Detection approach, which can be used to find malicous network traffic simply by ignoring traffic that seems “normal”.

Credits

Several bugs have been fixed in CapLoader 1.4, such as:

• Support for frames with Captured Length > Real Lenght (Thanks to Dietrich Hasselhorn for finding this bug)
• Delete key is no longer hijacked by the “Hide Selected Flows” button (Thanks to Dominik Andreansky for finding this bug).
• CapLoader GUI now looks okay even with graphics are scaled through "custom sizing". Thanks to Roland Wagner for finding this.

Downloading CapLoader 1.4

The regularity and period detection is available in our free trial version of CapLoader. To try it out simply grab a copy here:
https://www.netresec.com/?page=CapLoader#trial (no registration needed)

All paying customers with an older version of CapLoader can grab a free update to version 1.4 at our customer portal.

UPDATE June 2, 2016

We're happy to announce that it is now possible to detect Kovter's C2 communication with help of an IDS signature thanks to Edward Fjellskål. Edward shared his IDS signature "NT TROJAN Downloader/Malware/ClickFraud.Win32.Kovter Client CnC Traffic" on the Emerging-Sigs mailing list yesterday. We have worked with Edward on this and the signature has been verified on our Kovter C2 dataset.

UPDATE June 8, 2016

Edward Fjellskål's IDS signature "ET TROJAN Win32.Kovter Client CnC Traffic" has now been published as an Emerging Threats open rule with SID 2022861.

#alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Win32.Kovter Client CnC? Traffic"; flow:established,to_server; dsize:4<>256; content:!"HTTP"; content:"|00 00 00|"; offset:1; depth:3; pcre:"/^[\x11\x21-\x26\x41\x45\x70-\x79]/R"; content:!"|00 00|"; distance:0; byte_jump:1,0,from_beginning,post_offset 3; isdataat:!2,relative; pcre:!"/\x00$/"; reference:url,symantec.com/connect/blogs/kovter-malware-learns-poweliks-persistent-fileless-registry-update; classtype:trojan-activity; sid:2022861; rev:1;)

Posted by Erik Hjelmvik on Monday, 23 May 2016 11:55:00 (UTC/GMT)

Tags: #CapLoader​ #PCAP​ #Periodicity​ #C2​ #beacon​ #Intrusion Detection​

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​

Analyzing Web Browsing Activity

One of the features included in the newly released version 2.0 of NetworkMiner Professional is a new tab called “Browsers”. This tab shows web browsing requests and reponses in a hierarchical tree view, with the identified web browsers as root nodes.

The idea of tracking browser activity this way was suggested to me by Steffen Thorkildsen way back in 2009. I'm therefore happy to finally have this feature implemented in NetworkMiner!

At first glance, the Browser tab looks somewhat like the Hosts tab. One difference is that there can be multiple browsers per host, since each unique HTTP User-Agent is considered a separate browser.

The web pages (URLs) visited by a browser can be analyzed by expanding the node of that browser. The URLs are organized in a hierarchical structure, so that all URLs visited by clicking a link on a web page are placed under the node of that web page. This enables the analyst to see how a user ended up at a particular URL. NetworkMiner primarily uses the HTTP referer header (the misspelling of referrer stems back to RFC1945) to backtrack the pages visited before landing at a particular page.

The browser tree view also shows HTTP redirects, such as “302 Found” and “301 moved permanently”. These redirects can be used in order to see encrypted HTTPS URLs that a user is redirected to, for example when logging in at a website.

Image: Microsoft responding with a “302 Moved Temporarily" redirect

The icons that show up at some web servers are favicon images that have been passively extracted from the analyzed PCAP file.

We hope the Browser tab can be of help in criminal investigations in order to show whether or not a suspect visited a particular website intentionally. This feature can also be used to track the activity of malware that uses HTTP for command-and-control (C2) as well as to analyze redirect chains used for malware downloads.

The PCAP file loaded in the screenshot above originally comes from malware-traffic-analysis.net. Note that our analysis was done by running NetworkMiner in Linux to prevent accidental malware infection. The events shown in NetworkMiner's browser tab matches the description of the redirect chain provided at malware-traffic-analysis.net:

162.144.66.10 port 80 - www.crowdfundingformybusiness.com - Compromised website
185.14.30.37 port 80 - goog1eanalitics.pw - First redirect
178.32.173.105 port 80 - 178.32.173.105 - Second redirect
46.101.59.201 port 80 - osooraudie.co.vu - Nuclear EK

The redirect chain leads to a Nuclear Exploit Kit (SWF file with MD5 695a07cbcac3ca64010e168fe495ff4a, VirusTotal). Later on the Nuclear EK retrieves the file “kernel1.exe”, which seems to be related to the Kelihos botnet.

Posted by Erik Hjelmvik on Thursday, 18 February 2016 13:37:00 (UTC/GMT)

Tags: #NetworkMiner​ #HTTP​ #browser​ #favicon​ #redirect​ #malware​ #NSM​ #PCAP​