WAFs and the Log4j Vulnerability

Understanding the OSI model and how WAFs work

One of my posts on Application Security and Data Breaches.

Free Content on Jobs in Cybersecurity | Sign up for the Email List

This is a brief hiatus from my series of blog posts on software security. My mind tends to wander and I write whatever appeals to me on a particular day. I’ll get back to that other series of blog posts shortly.

I was inspired to write this post in response to a tweet someone made about the log4j vulnerability. He stated something to the effect of people don’t understand that the log4j vulnerability isn’t a network issue because they were finding the vulnerability all over the place, such as in the user agent string and headers. Then he claimed a WAF (Web Application Firewall) wouldn’t help.

That statement caught my eye for a couple of reasons. First of all, pretty much every attack that would leverage the log4j vulnerability involves networking. The requests and responses go over a network. An attacker would have to insert an attack via a network unless they had already compromised your system and inserted it on the host itself. In that case, they likely don’t need the log4j attack vector anymore, though they might use it to try to be stealthy.

Additionally, zero trust networking might be able to thwart this attack in some cases. The initial attack might make it to the webserver, but the outbound traffic to the C2 server after the attack string gets processed by log4j could be blocked if you’re using a stateful firewall that understands which host initiated the network connection. I wrote stateful firewalls in my book, Cybersecurity for Executives in the Age of Cloud.

You can inspect the network traffic going back and forth between the attacker and systems on your network that may be susceptible to a log4j attack. If you see something coming from or going to a malicious endpoint known to be dishing out log4j attacks, then you can stop it on the network. It is possible to inspect packets reassembled into full messages on the network before they get to your WAF or your web application and block unwanted attack strings using tools like Snort, Zeek, and Suricata.

Next, consider how a WAF works. I get questions about WAFs and how they can help with web applications and APIs on IANS consulting calls and find that they are sometimes misunderstood. I wondered if the person was thinking a WAF inspects IP addresses, ports, and protocols like a stateless firewall. I don’t know what type of WAF that person was using, but the WAF I wrote after my first data breach operated at Layer 7 of the OSI model, and that’s pretty much the definition for a WAF. It can provide protection at other layers, but the primary purpose of a WAF is layer 7 traffic inspection.

The OSI model defines different layers of networking that a network packet travels through to get your data from the source to a destination on the network. At some layers, packets are handled individually. If you inspect a single packet it will likely only have a portion of your web page request or response. If you inspect those packets individually you might miss something due to the context and also when the packets are reassembled by different types of hosts.

At layer 7, the application layer, network devices reassemble the packets to the full requests or responses for a particular application. At that point, you may not have the details about attacks that occur at lower layers in the stack where an attack messes with metadata in the packet bits. However, at this higher layer, you can inspect the data in a more complete form. In a reassembled web request you can inspect the data elements it contains such as the user-agent, headers and the HTML body. In a single packet, you might only get half the user-agent string, for example.

A web application firewall can inspect an entire request and response, similar to the proxy tools I use during penetration testing. I use those tools to view and manipulate requests and responses I send to attack your web application (with permission only, of course!) When you have the entire request you can inspect things like the user-agent string, the referrer, headers, HTTP codes, redirects, and the body of the request in a more complete form.

To protect my website after I faced a data breach many years ago, I wrote some code to capture every HTTP request and inspect it prior to allowing the web server to further process it. I would look for any anomalies and drop the request if something was off. This approach becomes much more challenging with some of the new web architectures, frameworks, and protocols that exist today, but it is still possible. You would need to understand if your WAF correctly handles the protocols and webserver configuration you are using.

So is a WAF helpful when it comes to the log4j vulnerability? Absolutely! It will help in cases where the attack is sent to a webserver protected by a WAF that can view all the information in requests and responses. Attackers are inserting the attack into any value that may be written to your logs by the log4j library, as I explained in a prior post. A WAF can evaluate the content before allowing it to pass and reject requests or responses containing malicious values.

A good WAF will understand how an attacker might obfuscate the attack to hide it from security appliances. Spotting all the potential formats for an attack string is challenging for so many reasons I can’t explain in one blog post, so you cannot count on a WAF exclusively. When performing a web application penetration test, I use a process called fuzzing to see if I can bypass protections provided by tools and software packages that try to block malicious values. I have both commercial tools and custom code that I use to inject numerous variations of attacks at a web application or application programming interface (API). Attackers will do the same.

A WAF should not be your only line of defense, but yes, a WAF can definitely help some log4j attacks against web applications.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2021

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab