WAF, RASP and Log4Shell – Security Boulevard

0


Log4Shell did an excellent job advocating Runtime Application Self-Protection (RASP). Here is a short summary: Our Contrast Protect customers have been protected against Remote Code Execution (RCE) in this vulnerability for years before we even knew it existed. We want to make our offering even better and stop secret leaks from exfiltration, so be sure to check it out in a few days.

Basically for RASP, Web Application Firewalls (WAFs) are just not good at some things. As a brief overview, RASP helps secure applications by instrumenting the application at runtime and providing deep context and information about how the application is working for superior attack detection and defense. A WAF is generally located at the perimeter of the network and monitors HTTP traffic for attacks based on the provided signatures. Now let’s dive into the case where RASP is fighting Log4Shell.

There are 3 main reasons WAFs are not going to help us much here.

# 1 – WAFs can only sign, and this payload is quite polymorphic

Twitter is to hum With several Encodings of the attack to bypass WAFs. The community realized pretty quickly that it was quite difficult to get a signature. Here is a striking example:

Even if there is a way to sign the attack, it will intercepting hopelessly legitimate traffic and disrupt your system. For this reason, we are of the opinion that WAFs only help low-skilled attackers, but offer no real protection.

# 2 – WAFs fail to see the out-of-band elements of the attack

One of the elements of this attack that is overlooked is the fact that the exploit consists in tricking the application into reaching another service (DNS, LDAP, RMI, CORBA). and none of these outbound transactions go through the WAF, as shown in this diagram from Sophos:

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

Hence the success of the exploit for the WAF. not known the WAF just tells you if script kiddies hit you with vanilla attacks. And you know the answer to that is “yes” even before you even get the WAF. had so … why are we doing this again?

# 3 – The world is no longer just HTTP

An increasing percentage of our code is asynchronous, event-driven, triggered by message queues, serialized with Protobuf, and so on. This error can be triggered by ridiculous detours anywhere in the company.

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 analysis in our agent which was sent to our agent recording server which logged some data that was recorded itself from our log aggregator, which was eventually forwarded to a Slack channel. It is a dizzying thought that all of these places need to be hardened against attack. There is simply no shortage of ways that a small string can make it into your business and then spread to many systems on it.

We cannot set up a surveillance camera near the main gate of a football stadium and explain that we protect all fans inside.

We have been providing protection from the attacks we saw against Log4Shell since 2018 or around. It’s not because we anticipated this particular vulnerability against Log4j. That’s because we’ve built sandboxes that separate exploitable operations (like deserialization and expression language execution) from exploit targets (process creation, dynamic code loading, etc.). I talk about this strategy in detail and use sandboxing OGNL as an example in this talk from Microsoft BlueHat 2018.

The common exploit paths (JNDI -> LDAP -> Deserialisierung / EL -> RCE and JNDI -> RMI -> EL -> RCE) are not possible because these paths contain a sandbox step. This is not to say that anyone will find another route to RCE In fact, our own research is about to find more But today, well, the past few days it has been great to be an existing Contrast Protect customer.

It was also a good day to be a Contrast Protect customer those just when Struts 2 announced an RCE, we protect it from unpacking because we hardened the execution of the OGNL expression language. If you don’t know us, we will of course also help you with any vulnerabilities in your custom code not just your libraries!

Data exfiltration is also possible with these attacks. Although less interesting than RCE, it’s still a very high risk. In the interests of transparency and fairness, I want to emphasize that we are not protecting you (at the time of writing) from using a similar exploit path to return information on the RMI / LDAP DNS / path to yourself without the next one Taking a step would allow the code to run (and thus be blocked by our rules). In the next few days we will be releasing an updated version of the agent that will prevent the attack’s secret exfiltration capabilities. After that, the team will consider for a long time whether this protection can also be generalized and hopefully make the next major vulnerability even more boring.

I know that vendor tracking of ambulances is very sensitive so I would like to conclude by saying that I am proud of the way our team has developed protective measures that have been proven and we hope this shows the world why it is is crazy just crazy to run an application without RASP.



Share.

About Author

Comments are closed.