Log4Shell has done an excellent job of making the case for Runtime Application Self-Protection (RASP). Here’s the quick summary: our Contrast Protect customers have been secure against the remote code execution (RCE) in this vulnerability for years — even before we even knew it existed. We want to make our offering even better and stop secret leaks via exfiltration, so look for that in a few days.

The case for RASP is fundamentally that Web Application Firewalls (WAFs) are just not good at some things. 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 3 main reasons why WAFs are not going to 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 has 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 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, as this diagram from Sophos shows:

[Diagram Source: https://news.sophos.com/en-us/2021/12/12/log4shell-hell-anatomy-of-an-exploit-outbreak/]

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.

What We Protect, And How

Since 2018, or thereabouts, we’ve offered protection against the attacks we’ve seen against Log4Shell. It’s not because we foresaw this particular vulnerability against Log4j coming. It’s because we built sandboxes that separate exploitable operations (like deserialization and expression language execution) from exploit targets (process building, dynamic code loading, etc.). I talk about this strategy in depth and use sandboxing OGNL as an example in this talk from Microsoft BlueHat 2018. 

The popular exploit paths (JNDI -> LDAP -> deserialization/EL -> RCE and  JNDI -> RMI -> EL -> RCE) are not possible because those paths have a step in them that are sandboxed. This isn’t to say that someone won't find another path to RCE — in fact our own research is close to finding more — but today, well, for the past few days it’s been great to be an existing Contrast Protect customer. 

It was also a good day to be a Contrast Protect customer those times when Struts 2 announced an RCE we protect against out of the box because we hardened the execution of OGNL expression language. Of course, if you’re not familiar with us, we also help you with all the vulnerabilities in your custom code — not just your libraries!

Data exfiltration is also possible using these attacks. Even though it is less interesting than RCE, it’s still a super high risk. In the interest of transparency and fairness I want to highlight that we don’t protect you (as of writing) from using a similar exploit path to leak information back to yourself in the RMI / LDAP DNS / path, without taking the next step that would allow code execution (and thus, get blocked by our rules.) In the next few days we will release an updated version of the agent that prevents the secret exfiltration capabilities of the attack. The team is going to have a long think after this in order to discover if this protection can be generalized as well, and hopefully make the next big vulnerability even more boring.

I know there is sensitivity around ambulance chasing by vendors, so I’ll end by saying that I’m proud of how our team has built protections that are standing the test of time and we hope this shows the world why it’s crazy — just crazy — to run an application without a RASP.

Connect with us now to learn how Contrast scan protect your Java applications against exploits like Log4j and how you can get started at no charge today.