Log4Shell Makes the Case for Runtime Application Self-Protection

The case for runtime application self-protection (RASP) is that while Web application firewalls (WAFs) are a good solution for some use-cases, they're not great for attacks like the type we're seeing with Log4Shell. As a quick review, RASP helps secure applications by instrumenting the application at runtime, enabling deep context and intelligence about how the application works for superior attack detection and blocking. A WAF generally lives at the perimeter of the network and monitors HTTP traffic looking for attacks based on supplied signatures. Now, let's dive into the case for RASP to combat Log4Shell.

Why WAFs Are Not a Solution
There are three main reasons why WAFs won't help us a lot here. 

#1. WAFs can only signature, and this payload is quite polymorphic.
Twitter is abuzz with several encodings of the attack to bypass WAFs. The community realized pretty instantly it's quite tough to signature. Here's an eye-popping example: 

Even if there's a way to signature the attack, it will hopelessly catch legitimate traffic and disrupt your system. This is why we believe that, at most, WAFs help with visibility with low-skilled attackers but are poor at providing actual protection.

#2.WAFs don't see the attack's out-of-band elements.
One of the elements of this attack that is overlooked is the fact that the exploit involves tricking the application to reach out to another service (DNS, LDAP, RMI, CORBA) — and none of these egress transactions will go through the WAF.

Thus, the success of the exploit is not knowable to the WAF — the WAF just tells you if script kiddies are hitting you with vanilla attacks. And you know the answer to that is "yes" even before you had the WAF — so ... what are we doing this for again?

#3. The world isn't just HTTP anymore.
An increasingly large percentage of our code is asynchronous, event-driven, triggered by message queues, serialized with protobuf, etc. This bug can be triggered arbitrarily deep within the enterprise through ridiculously circuitous paths. 

Internally, we saw a chain where a customer's app was attacked with a simple Log4Shell payload, and then that payload data was captured as an analytic in our agent, which was sent to our agent ingestion server, which logged some data, which was itself ingested by our log aggregator, which ended up piped to a Slack channel. It's a dizzying thought that all of these places have to be hardened against attack. There's just no shortage of ways a little string can make it into your enterprise, and then propagate to many systems thereon. 

We can't put one security camera near the main gate of a football stadium and declare we're protecting all the fans inside.

Protect Your Apps
Instrumenting your applications with protection on the inside will help protect against Log4Shell now and inevitable similar attacks in the future. Learn more from Contrast Security.

About the Author

Arshan Dabirsiaghi is an accomplished security researcher with 10+ years of experience advising large organizations about application security. Arshan has released popular application security tools, including AntiSamy and JavaSnoop.