0-Day Detection of Log4j2 Exploit Vulnerability

The world’s most used logging framework was just hit by the Log4j2 exploit, but DevSecOps teams can quickly identify what’s impacted and where they focus their time with Contrast vulnerability detection software.

Log4j, used by any Java application that logs data, was hit with a 0-day exploit today. This 0-day Log4j2 exploit impacts any application using Log4j and allows attackers to run malicious code and commands on other systems. Make no mistake, this is the largest Java vulnerability we have seen in years. 

Although the 0-day detection of the Log4j2 vulnerability was disclosed today, the Log4j2 exploit security risk was present yesterday and has been there for a while. Software vulnerabilities and exploits like Log4j2 can be better found through continuous detection but even then may not always have a patch available. It’s important for software teams to set up tools that continually look for the Log4j vulnerability and similar types of flaws, as well as defenses that let software adapt itself to an evolving threat landscape. Historical defense techniques like Web Application Firewalls (WAFs) are incapable of addressing software vulnerabilities like this because the data doesn’t just come from web input and isn’t visible with signatures.

This is where Contrast Security zero day security software can help test for and detect the Log4j2 vulnerability or other vulnerabilities and exploits. Only Contrast’s embedded approach allows you, at scale to (1) find what apps have vulnerable versions of Log4j, (2) detect which apps have the vulnerability (and others like it) and (3) most importantly stop attacks against it, today, without waiting for a patch or WAF signature.

What can be done to mitigate the 0-day now

The 0-day vulnerability is classified as CVE-2021-44228 and can occur in any application that logs user input. The impact occurs in many locations, such as Minecraft, which logs the name of users who log in to the server. Remote users can change their username to an OGNL expression, causing the code to run on other players’ computers.

There are several ways to handle this 0-day vulnerability.

Recommended Best Approach to Fix the Log4j2 Vulnerability

Upgrade to Log4j2 2.16.0. This will fix the vulnerability by patching the library correctly.

Use JVM Flags - for a handful of applications

JVM flags can control application behavior for fine grained control. The benefit is that they can guide the application (which needs to be restarted) but the downside is that you need to know where and when to apply each flag.
If you select this action, please continue working to upgrade your library.

• Use temporary mitigation while you plan your upgrade (both require application restarts):
• Log4j2 2.10 and up has a system property -Dlog4j2.formatMsgNoLookups=true
• Remove the JNDI class entirely:
  zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
  
  
• Set a JDK system property
• -Dcom.sun.jndi.rmiobject.trustURLCodebase=false
• -Dcom.sun.jndi.cosnaming.object.trustURLCodebase=false
• JDK 8u121 sets both these properties correctly. If you are under 8u121 you must set these properties yourself, and setting them to false no matter what will work and is fine.

Use a temporary detection patch - to scale 

Volker Simonis from the AWS Corretto team has released an intelligent and effective dynamic patch to address the CVE-2021-44228 remote code execution vulnerability in Log4j that does not require a restart. The patch must run on the same machine as the running Java process as the same user. It then dynamically connects to the running Java process through the Attach API and inspects the running JVM to configure the JVM flags and actions described above.

If you select this action, please continue working to upgrade your library.

HOW CONTRAST SECURITY HELPS DETECT AND PROTECT AGAINST ZERO DAYS LIKE LOG4J2

To work against these 0-days, there are three main questions that teams should answer:

1. Where does this log4j2 vulnerability impact me?

2. How can I mitigate the impact of log4j2 right now to prevent exploitation?

3. How can I test for log4j2 vulnerability and similar issues to prevent future exploitation?

All three questions can be answered with the same Contrast agent software.

WHERE DOES THIS LOG4J2 VULNERABILITY IMPACT ME?

Teams can locate where they have the vulnerable log4j2 library or other vulnerable libraries by using the library inventory. As a 0-day vulnerability, this was unknown yesterday so would not have appeared in previous reports that scanned for vulnerable components. The way to locate this retroactively is to look back at an inventory of these libraries, from Contrast Assess or OSS, and identify which applications use these log4j libraries.

This library inventory is automatically produced for all Contrast users to see if and where they are impacted.

These identified applications are where teams should spend effort to resolve the issue.

HOW CAN I PREVENT LOG4J2 EXPLOITATION RIGHT NOW?

Immediate mitigations help teams keep critical applications running safely. The best strategy is to use Runtime Protection, like Contrast Protect, to defend immediately without patching. This provides time to remove the risk (upgrading the library), which is preferred to constantly defending an application that is left vulnerable.

Contrast Protect works inside the application to defend exploitation, to see execution beyond what is visible with network controls. Unlike network-based tools like web application firewalls (WAFs), log frameworks like log4j to record how the application uses this data and occurs in many backend non-web applications that are at risk from the log4j2 vulnerability.

HOW CAN I TEST FOR AND DETECT LOG4J2 AND SIMILAR ISSUES TO PREVENT FUTURE EXPLOITATION

Once the immediate risk is removed, teams should look for similar vulnerabilities. This includes other cases of remote code injection as well as other security flaws that can impact the application. Teams should hook a continuous security detection tool like Contrast Assess to applications as they are tested, to locate vulnerabilities in custom code. In addition to creating the library inventory described above, Contrast Assess can locate new undiscovered vulnerabilities that are unique to the application. Teams can then use code stack traces to see how data moved through the application code to drive remediation, with a minimal false positive rate.

This technique can find vulnerabilities like the log4j2 remote command execution, sql injection, path traversal, and others. Teams can passively locate these vulnerabilities without a dedicated security test plan.

The Contrast advantage

In summary, the advantage of a software security platform like Contrast is that it allows you to respond instantly to a zero day like this one (without waiting for a patch), but also future-proofs your stack against the many to come. Specifically, only Contrast can allow you to (1) find what apps have vulnerable versions of a library, (2) find which applications are exposed to a vulnerability (and others like it) and (3) most importantly stop attacks against it, today, without waiting for a patch or WAF signature.

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