Is your WAF as good as Tubbs and Crockette as stopping Smugglers?

Queue the 80s background music; I can hear "In the Air Tonight" playing as your WAF races across town for a showdown with a hacker.

OK, enough with the corny intro. Request Smuggling: it's a real problem out there. Recently, there was a CVE posted for Tomcat where it was vulnerable to this type of attack, CVE-2023-46589 (https://nvd.nist.gov/vuln/detail/CVE-2023-46589) 

Request Smuggling is where an attacker sneaks instructions into a seemingly benign request, to be processed by web servers behind the web server accepting the initial request. Most web applications today are built using complex systems of web servers, not a single device that processes all of the requests. The initial server takes the request and possibly rewrites the first line for an API call to another web server to process.

This is how Smuggling works. The attacker adds instructions to the initial request, which is then sent downstream and potentially processed and handled with lower protections.

Portswigger has a great explanation of it here: https://portswigger.net/web-security/request-smuggling 

Many of my conversations with customers over the years have concerned the need to protect ALL of their web applications with a Web Application Firewall, both internet-facing and internal. Sadly, with resources being what they are, this isn't always possible, and many East <-> West application calls are not passed through a security appliance of any sort other than possibly a Layer 4 firewall.

This is why Request Smuggling is so popular today. It isn't new; it was raised as an issue nearly 20 years ago.

But how do you stop this? The CVE for Tomcat noted above was announced on December 12th, 2023: that's day zero. When it was released, there was no POC available, and there were concerns about using an exposed version of Tomcat and what that might lead to. F5's security team noted this and researched the vulnerability to see if we needed to update our signatures.

F5's signatures are helpful in these initial exposure situations. The signature sets include many commands that attackers use to determine your applications' exposure. They'll send commands like "whoami," "ls -ls," or other simple, small commands to see if there are responses. These commands are all included in the basic signature sets and are easily blocked by the default settings for our Web Application Firewalls on BIG-IP, F5 Distributed Cloud and NGINX. So, even if the vulnerability is unknown, we can be confident these commands would be blocked.

But, if a signature can block the vulnerability, the F5 Threat Research Team will investigate and create one specifically for the vector.

For this vulnerability, it was determined that a signature was not needed. However, the HTTP Protocol Compliance settings in the Default Policy configurations were able to block these attacks. From the Portswigger article, the method used to smuggle the traffic through is by manipulating the Content-Length header or adding data after the chunked content delimiter (\r\n). This does not follow the HTTP protocol standards, and all F5 WAFs will flag this using our default settings.

Each of these items is selected in a default security profile, ensuring that any attempts by a malicious actor to hide data in the request outside of the reported size of the request are blocked.

And this works for F5 Distributed Cloud (XC) and NGINX App Protect as well.

Request smuggling is tricky to capture; only a security service that correctly assesses the request for validity to the HTTP protocol will ensure it's mitigated. Smuggling isn't new, and neither is Request Smuggling, but hopefully, you have Crockett and Tubbs working on your side to address any attacks that might be sneaking into your network.

Hopefully, that's a computer network and not a cartel network.

OK, now I have to go and stream some of Miami Vice episodes.