Expert Corner - A Comprehensive Guide to Log4j Vulnerability & Combat Techniques

What is Log4j?

Apache Log4j is a Java-based logging utility and several Java logging frameworks. Log4j is a popular logging package written in Java. log4j has been ported to the C, C++, C#, Perl, Python, Ruby, and Eiffel languages. On Dec 9th, 2021, a Zero-day vulnerability named “Log4Shell” (tracked as CVE–2021-44228) was detected and rated 10 under CVSS by Apache Foundation. It is of Remote Code Execution (RCE) type vulnerability, allowing attackers to remotely run malicious code within the target system without requiring physical access to the system. Proof of Concept and investigations revealed that the exploitation was easy to perform. Based on the system’s configuration, the attacker will craft a request from Log4j LDAP and JNDI servers, as the responses are not checked. This will allow the attacker to execute arbitrary Java code on a server or computer or leak sensitive information.

Where is it used?

Log4j is used by millions of web applications, including Minecraft, Apple iCloud, Twitter and Steam. It is a login utility used in enterprise software applications, including those custom applications developed in-house by businesses, and forms part of many clouds computing services. Logging is used by developers and soc members to check out the activity of an application. It can be seen in the smartwatches, smartphones and other smart devices we use in our daily life.

Complications

As this framework is very widely used across the globe and more often seen in the wild as a logging service, the attack surface is huge. International security company ESET released a map showing where Log4j exploitation attempts have been made, with the highest volume occurring in the US, UK, Turkey, Germany, and the Netherlands.

Root Cause

A logger writes down everything that is set to log on to the hard drive or store it on the server. In the case of log4j few actions are performed before writing. It looks for patterns like ${date} and will try to fetch the relative information. When we use something like ${jdni: resource} it triggers a mechanism where it loads a resource from another computer. This resource can be a malicious piece of code that will be executed by the victim who is parsing our payload (it is a simple script that will let hackers/adversaries perform unauthorized or malicious actions on one’s computer).

How to detect whether the client is running a vulnerable version of log4j?

To check whether your application is likely affected you must verify:

• Log4j version – all 2.x versions before 2.15.0 are affected.
• JVM version – if lower than:

• • Java 6 – 6u212
  • Java 7 – 7u202
  • Java 8 – 8u192
  • Java 11 – 11.0.2

If both are true, your Log4j version is older than 2.15.0 and your Java version patch level is older than listed above, you’re almost certainly affected.

How to detect whether the web server has been compromised using log4j?

You can use these commands to search for exploitation attempts against log4j RCE vulnerability.

Grep / Zgrep

This command searches for exploitation attempts in uncompressed files in folder /var/log and all sub folders.

• sudo egrep -I -i -r ‘\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+’ /var/log

This command searches for exploitation attempts in compressed files in folder /var/log and all sub folders.

• sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i ‘\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+’

Grep / Zgrep – Obfuscated Variants

These commands cover even the obfuscated variants but lack the file name in a match.

This command searches for exploitation attempts in uncompressed files in folder /var/log and all sub folders.

• sudo find /var/log/ -type f -exec sh -c “cat {} | sed -e ‘s/\${lower://’g | tr -d ‘}’ | egrep -I -i ‘jndi:(ldap[s]?|rmi|dns):'” \;

This command searches for exploitation attempts in compressed files in folder /var/log and all sub folders.

• sudo find /var/log/ -name “*.log.gz” -type f -exec sh -c “zcat {} | sed -e ‘s/\${lower://’g | tr -d ‘}’ | egrep -i ‘jndi:(ldap[s]?|rmi|dns):'” \;

Find Vulnerable Software (Windows)

• gci ‘C:\’ -rec -force -include *.jar -ea 0 | foreach {select-string “JndiLookup.class” $_} | select -exp Path

How to confirm whether the client has configured the log4j, for not to be exploited?

• If you are using Java 1.8 or higher, download the latest Log4j mitigated version 2.15.0 from its download page.
• If you can’t upgrade immediately and are using Java 8u121 or later
• If the Java version is >= 8u121 it is possible to mitigate the issue by setting
  com.sun.jndi.rmi.object.trustURLCodebase to false
  and
  com.sun.jndi.cosnaming.object.trustURLCodebase to false
• Using Java version less than 1.8
  1. In earlier versions of log4j >= 2.10 it is possible to mitigate this issue by
  2. Setting the system property: formatMsgNoLookups: true
  3. Set the JVM parameter: -Dlog4j2.formatMsgNoLookups=true
  4. Removing JndiLookup class from the classpath
  Example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup /JndiLookup.class

File Hashes

• https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes/blob/main/md5sum.txt
• https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes/blob/main/sha1sum.txt
• https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes/blob/main/sha256sums.txt

Impact

This vulnerability should be considered seriously as it is extravagantly exploitable that could allow hacker’s/adversaries to control java-based web servers and get RCE (remote code execution). In layman’s language, it would help a hacker to gain full control of the system. This library is used almost everywhere and the exploit gives full server control and it is easy to conduct. It is why the rating of this vulnerability is quite severe. Firstly, this vulnerability was seen in Microsoft’s owned Minecraft, NetApp products, Cisco’s Webex meeting server, and many others joining the list. The biggest problem is where the hackers/adversaries are using for illegal crypto mining where hackers steal one’s resources and perform cryptocurrency transactions and gain benefit for completing the transactions.

Proof of Concept

• To demonstrate the proof of concept we initially set up a Spring Boot web application with vulnerable log4j service on the localhost.
• Setting up a web application with vulnerable log4j service
• To check if the application is vulnerable to log4j we will make use of canarytokens to generate a payload that will trigger a reminder to our specified email or webhook url.
• Generating a payload
• Next, we will have to copy the payload which canarytokens has generated.
• Copying the payload
• As we are dealing with a vulnerability that is based on logging we will have to paste the payload in locations where our request might get logged. We will have to target the locations where our data is logged such as HTTP headers like user-agent, x-api-version, referer, origin and then we have username and password fields which the server might log to check and prevent attacks like brute-forcing, password guessing and DDoS attacks. In our case, we will make use of curl (command-line tool that is used to transfer data to and from a server) to send an http request with header x-api-version and we will place our payload in the header value.
• Sending the payload
• If the web application is vulnerable to log4j vulnerability we will get a mail over the email we specified as shown below or a hit on the webhook url.
• Obtaining an alert.

Solution

Any Log4J version prior to v2.15.0 is affected by this issue. we will have to upgrade to v2.16.0 as it is considered the safe version. For version greater than or equal to 2.10 we can set log4j2.formatMsgNoLookups to true and for releases from 2.0 to 2.10.0 we will have to remove the ldap class from the log4j by running the command zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class and then set the system property log4j2.formatMsgNoLookups to true. If upgrading is not possible then we have to confirm the system property -Dlog4j2.formatMsgNoLookups is set to true on both client and server-side components. Also, many organizations don’t sanitize the logs before storing assuming nothing could go wrong. To mitigate this issue, we need to make sure that the logs are being sanitized before storing them on the server.

Mitigation

Log4j 2.15.0-rc1 has been released. The fix included restricting the servers and protocols that may be used for lookups, which can be configured using several system properties. This replaced the system property {log4j2.formatMsgNoLookups}, which is recommended to be used to mitigate the vulnerability in previous versions since 2.10.0 by setting it to ‘true’. For versions before 2.10.0, the class {org.apache.logging.log4j.core.lookup.JndiLookup} needs to be removed from the class path.

Additionally, all features using JNDI will be disabled by default, and support for message lookups removed from version 2.16.0 onwards.

Newer versions of the Java Runtime Environment (JRE) also mitigate this vulnerability by blocking remote code from being loaded by default, although other attack vectors still exist in certain applications. Several methods and tools have been published to help detect the usage of vulnerable log4j versions in built Java packages.