Apache Log4j Vulnerability Details and Mitigation

Yesterday, we had reported the critical zero-day vulnerability in Apache log4j, where the attacker can easily exploit the bug with a single line of payload and get code execution on the vulnerable system. 

We had mentioned that initially the bug was reported by the Alibaba Cloud Security team and the name of the researcher is, Chen Zhaojun, who discovered this zero-day. Currently, this vulnerability is been tracked as CVE-2021-44228 and there is no doubt that cyber crooks are already started scanning the internet to exploit the nasty bug. 

As the bug resides on the Apache Log4j2, which is a Java-based logging tool that rewrites the Log4j framework and introduces a lot of rich features. Log4j is one of the popular library that is being used on many applications. 

Today, Apache has published the advisory about the Log4j security vulnerability in which they noted -

"Log4j 1.x has reached end of life and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x was not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain security fixes."

Apache says that they never provide the Binary patches. If users need to apply a source code patch, Apache recommends using the building instructions for the Apache Log4j version that users are using. For Log4j 2 read BUILDING.md which can be found in the root subdirectory of a source distributive.

Details and Mitigation of Apache Log4j 

Apache team has given the CVSS score:10/10 to CVE-2021-44228 , and noted that Apache Log4j2 JNDI features do not protect against attacker-controlled LDAP and other JNDI related endpoints.

According to the advisory, Apache Log4j2 <=2.14.1 JNDI features used in the 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. So for the prevention of the issue, the Apache team has disabled this behavior by default from log4j 2.15.0. 

What's going on?

This Apache Log4j RCE vulnerability also known as "log4shell" is very easy to exploit. Just a simple one-line payload can exploit the bug and the attacker achieve the command execution on the vulnerability system. 

In the meantime, many security firms and security experts had identified the bug is exploited in the wild. Attackers are actively exploiting a critical vulnerability that affects a Java logging package. Because of its large attack surface and the innate severity of remote code execution, security researchers are notably calling this a “shellshock” vulnerability. All threat actors need to trigger an attack in one line of text. There’s no obvious target for this vulnerability—hackers are taking a spray-and-pray approach to wreak havoc.

Who is impacted?

Log4j is used in a variety of different popular software by a number of manufacturers, includes —

• Minecraft
• Apple iCloud
• Twitter
• Stem
• Tesla
• Apache applications (e.g. Apache Struts, Solr and Druid)
• Redis
• ElasticSearch
• Tencent
• Baidu
• Cloudflare
• Amazon
• Flume
• Ghidra
• UniFi Network Application

Mitigation or Fix of the bug

For mitigation of the above vulnerability, Apache team guides, in previous releases (>=2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to “true” or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

Furthermore, by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false" will protects against Remote Code Execution attacks in Java 8u121. 

Apart from this, the Apache team has also published the advisory for another two vulnerabilities in Log4j.