Apache released a patch to address the critical zero-day vulnerability in log4j

Threat Level – Red | Vulnerability Report

For a detailed advisory, download the pdf file here.

A zero-day remote code execution vulnerability, CVE-2021-44228 was discovered in Apache log4j affecting versions 2.0 to 2.14.1. Apache log4j is a java logging package used by millions of applications. Cloud services such as Steam, Apple iCloud and apps such as Apache Struts, Minecraft, VMware, Twitter, Cisco, Google, Amazon, LinkedIn, NetApp, Elasticsearch and many others are found to be vulnerable from this flaw.

The vulnerability tracked as CVE-2021-44228, could allow a remote unauthenticated attacker to execute code on vulnerable system. The attack is possible due to the failure of the system to protect against attacker-controlled LDAP and other JNDI related endpoints by the Java logging library.

In order to exploit this issue attacker should have an accessible endpoint from any of the protocol (HTTP, TCP etc.) which helps in sending the arbitrary code. Also, a log statement which logs the string at the endpoint from the request.

Users can check if their system is affected from this vulnerability, if they can find any of the hashes from the repository in their software inventory. For checking the exploitation attempt use the following command on your Linux systems: “sudo egrep -i -r ‘${jndi:(ldap[s]?|rmi|dns):/[^n]+’ /var/log/”.

We recommend users to take the following actions :

For identifying the servers vulnerable to Log4j use the detection tool given by TrendMicro. For a list of hashes to help determine if a Java application is running a vulnerable version of Log4j check the NCC Group’s GitHub page. For Java 8+: upgrade to 2.17.1 and for Java 7: upgrade to 2.12.4 from the patch link and migration guide available in the references. Users can remove the LDAP class from log4j by using the command: “zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”. Set “com.sun.jndi.rmi.object.trustURLCodebase” and “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false” if acceptable on JVM versions to mitigate the vulnerability. In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC). Deploy the log4j specific rules in your WAF. Block specific outbound Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) network traffic. Implement log4jail – “A fast firewall reverse proxy with TLS (HTTPS) and swarm support for preventing Log4J attacks“. Check for the affected software and their fixes available from the link.

The incomplete patch of CVE-2021-44228 resulted in a new issue being tracked as CVE-2021-45056, which affects the versions 2.0 to 2.12.1 , 2.13.0 to 2.15.0 and has been resolved in 2.16.0. An attacker with control over Threat Context map can craft a malicious code using JNDI lookup pattern which can result in a denial-of-service attack.

Apache Log4j2 is affected by another flaw tracked as CVE-2021-45105 and affects the versions 2.0-alpha1 through 2.16.0, resolved in 2.17.0 and 2.12.3. An attacker with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup which result in a StackOverflowError that will terminate the process.

Another vulnerability CVE-2021-4104 in Log4j 1.2 could allow a remote attacker to execute arbitrary code only if the system is configured to use JMSAppender. An attacker with write access to the Log4j configuration can exploit this flaw by causing the untrusted deserialization of untrusted data.

Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (CVE-2021-44832) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.

State-sponsored actors such as Apt35 and Hafnium are actively targeting this vulnerability. Currently, the attackers are using the payloads such as crypto miner Kinsing, Mirai botnet, Tsunami, Khonsari, Dridex malware and post-exploitation frameworks such as Cobalt Strike and Mimikatz. Some ransomware such as Conti and TellYouThePass are also targeting the vulnerability.

The Techniques currently used in the attack are:

T1190 – Exploit Public-Facing Application

T1203 – Exploitation for Client Execution

T1059 – Command and Scripting Interpreter

T1496 – Resource Hijacking

T1498 – Network Denial of Service

T1505 – Server Software Component

T1140 – Deobfuscate/Decode Files or Information

T1553 – Subvert Trust Controls

T1059.001 – PowerShell

T1486 – Data Encrypted for Impact

T1090.004 – Domain Fronting