Shooting Rubber Bands At Firewalls

Shooting rubber bands at firewalls is what I call a denial of service attack which can be used to deactivate firewalls from a number of vendors for less than five dollars. This attack is basic, cheap and hovers somewhere around script kiddy level 2, but that's the point! This attack has been known to vendors for a couple of years now, the vendors have been notified and done nothing to remediate the vulnerability.

Which Vendors Firewalls Are Affected?

A number of vendors that you would recognize, each of these has been notified.

• Cisco
• A10 (Issue with their load balancers, where you can reboot a product line)
• CheckPoint
• Sonicwall
• Sophos
• Fortigate
• Secunet
• Genua

Introduction

I crush infrastructure for a living, working for a company that performs DDoS-Assessments, training and stress tests. During 2016, before Mirai, we were able to simulate a botnet with ~ 2000 bots, and it was around that time we saw a strange behavior while running training for a network-security-team shooting on a firewall-cluster that we have seen doing 2 GB/s on average on a good day and which protected a well-known German Ecommerce-site. The cluster was advertised with 5 GB/s throughput by the vendor, no anti-DDoS appliances were involved.

The test was conducted against a fallback-location that had the same setup as PROD. The normal traffic during test time was generated by a cloud based load-testing platform, simulating usual user traffic with a little less than 500 MB/s. The attacking traffic should not be more than max 500 MB/s. It was not a performance test, but a test for sensor tuning, monitoring and workflows, so no one expected a failure.

• Stage 1: 10 Bots, 10 Locations, pure TCP-Garbage, 10MB/s each, 100 MB/s in total; beacons easily detected by monitoring, easily mitigated by the team.
• Stage 2: 50 Bots, 10 Locations, pure TCP-Garbage, 10MB/s each, 500 MB/s in total; beacons easily detected by monitoring, easily mitigated by the team
• Stage 3: 500 Bots, 20 Locations, pure TCP-Garbage, 1 MB/s each, 500 MB/s in total -> BOOM, Headshot. Firewall went into Guru-Meditation with 100%CPU-load on each core. Shortly after, the 2nd Firewall took over -> BOOM, Headshot again.  We had to restart the FW-Cluster, and since we thought it happened by chance, we repeated the test and went BOOM immediately again. We throttled the total amount of traffic to see where the problems start and realized that with roughly 100MB/s from 500 bots the cpu-load jumps into overload, 10% less and the packets were dropped like expected without any significant CPU-load.

Long story short: we were able to DDoS a FW-Cluster with 2% of the traffic needed, that this Cluster should be able to take on, just by simulating a little botnet and throwing garbage onto an open port.  The point with TCP-Garbage is: it is not a full TCP-Session, it is just packets shot onto an open port as part of a normal technical "proof of performance", so usually this traffic should simply get dropped.

Shooting Rubber Bands At Firewalls

Fast-forward to mid-2018, based on the experience with the above cluster we tested a lot of different firewalls in many setups, we saw some more firewalls failing and recognized a pattern. When one firewall from one vendor was vulnerable to the attack, all firewalls we tested from that vendor could easily be shot down with 2-5% of the advertised throughput when the attack is distributed over 500-1000 attacking IPs by simulating a little botnet. This task could be performed by a script kiddy.

Fast-Forward early 2019: we started to play with TCP-Spoofing and stumbled upon "Hell of a Handshake: Abusing TCP for Reflective Amplification DDoS Attacks", a very fine paper on how to perform Reflection/Amplification-Attacks through TCP.  We wanted to play with this option and found a nice VPS-provider over in Asia that accidentally allowed IP-Spoofing; and by the next DDoS-Test we used a host there to perform a very simple attack with 1.5MB/s traffic:

hping3 -p 443 -S -d 123 -i u1000 --rand-source Target.IP

And BOOM goes the dynamite.  

We asked some of our clients if we could conduct a short test against non-productive firewalls and we found that you need as little as 1-2% of advertised throughput with spoofed random IPs. We tested different FW-models from each vendor, and the result stays the same. It seems like an architectural problem, maybe some state-tables are flooded or filter rules are processed early, I don't know for sure.

If you want to test your own firewall you can do so from your internal network:

hping3 -p [OPEN_PORT] -S/-A/-F -d 123 --flood --rand-source FW_IP

So here we are: being able to shut down half of our clients with  fifty grand firewalls for as less than 5$ a month; don't even have to spend 9.99$ for a booter service.

PoC

In the video below you will see the attack performed against a firewall; Target-IP obfuscated for obvious reasons. The firewall is connected to a 1GB-Port, the usual traffic is between 10-200MB/s. On the left side is curl running in loop against the target, from a 3rd host. On the right side, lower panel is vnstat from the attacking machine to display the output-traffic. In the upper panel the attack-command itself.

At the beginning you'll see the connection-time, varying around 0.8s. At around 1.30 the first stage of the attack is performed, you can watch the outgoing traffic in the lower right panel,, 1.3MB/s. You see that after some seconds the FW starts to drop some connections, but you still can come through every then and there. At 3.00 the attack is started with 2 MB/s and you see the firewall going immediately into Guru-Meditation.

Why is this scenario a problem?

Security and protection is always about rising the bar, making an attack so costly for the attacker that you no longer become low-hanging fruit. When you protect a multi-million-dollar business, you want to force the attacker to spend a lot of dollars to be able to successfully perform an attack. If your multi-million dollar cash cow can be taken down with a 5$ water pistol, you are in serious trouble.

When your vendor can be brought down by a script kiddie, change the vendor.

Mitigation

• Use a device or solution from my non-affected vendor list below.
• TEST your firewall solution, you don't want to stop testing when it's working, you want to stop testing when it's broken

Non-Affected Vendor List

I will not tell you "to attack The DarkCyber NG-HyperWall from Nyan Industries you need to do $ACTION", because I do not know the in-depth root-cause for going into, maybe its insane defaults, maybe misconfiguration. I can tell you which vendors have never been affected though, I have tested these in various setups:

• PaloAlto
• Netscaler
• Juniper
• pfSense
• Any Anti-DDoS-Appliance
• Any Anti-DDoS Cloudprovider
• Vanilla Linux IPTables With Some Ports Open