Beware, your logs - how blocked log4shell, Spring4Shell etc requests can still lead to compromise

We've had quite a flurry of look-alike vulnerabilities recently - log4shell, Spring4Shell, Apache Commons Configuration CVE-2022-33980 - all of which center around how various frameworks parse input and allow the input to be considered executable code.

In the case of log4shell the impact was quickly felt across the Internet because log4j (an extremely popular logging framework) would parse the entire input looking for the sequence of characters in question and then happily execute whatever it found. Because, on modern systems, we tend to log everything this meant that people were able to exploit internal systems via all sorts of unexpected routes like real-time chat systems, support ticketing systems, message boards and so on.

So why, a year on, am I writing this short article, you ask?

Be careful what you log

I'm writing this because (as we've recently updated our Security Advisories and supporting documentation to note), even if you have mitigating controls in place on the inbound traffic - like a BIG-IP Advanced WAF policy, AFM Protocol Inspection, IPI or IDS etc - if you are logging what the Advanced WAF sees, for example, and those logs are sent to a vulnerable log server you can still be vulnerable to exploitation.

The exploitation won't come in the form of a request that a web server or API sees but rather in the form of the Advanced WAF forwarding (if configured to do so) the request contents to your logging system to say "I blocked this!"

If you aren't sure whether or not your log sinks are patched and up to date then the best advice is to make sure you log only packet headers (IP, port etc) where the data-type is known and the exploits can't be inserted.

Beware, your logs - how blocked log4shell, Spring4Shell etc requests can still lead to compromise

Be careful what you log

Further reading

2 Comments