Apache Log4j2 Vulnerability in Time for Christmas

With the public release of information regarding vulnerability CVE-2021-4428, also known as Log4j2 or Log4Shell, on December 10, 2021, many can be forgiven just letting the news pass by. For players of videogames in the 90s, Log4j2 resembles a save code or even worse a cheat code for a pixel-defined game.

Here is the National Vulnerability Database’s (NVD) description of the vulnerability,

“Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to “true” or it can be mitigated in prior releases (<2.10) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).”

This description is not much help to the public and the millions of devices estimated to be vulnerable to attack if the most recent patches are not installed.

It is perhaps wise then to use plain English to describe the vulnerability that is already seeing attackers making thousands of attempts to compromise networks using the flaw, some even believed to have started before public disclosure.

Staring at the beginning, on December 9, 2021, Apache, a popular open-source HTTP web server, discovered a vulnerability in its Apache Logging Service and in particular in the Log4j library written in java. The Log4j library is widely used by other frameworks, such as Elasticsearch, Kafka, and Flink, which are the foundation for many popular websites and services.

This also means that due to the wide array of applications that use the library be they are based on Windows, Linux, or Mac are vulnerable to potential attacks. Given the wide use of the library, the impact of the discovery will be hard to predict, but it is important to note that the vulnerability was given a rating of 10 in terms of severity, the highest possible rating. Security firm Bitdefender advised customers on the following,

“As a result, this vulnerability has a very significant ripple effect on the software supply chain, and it is hard to predict the total scope and long-term impact of the vulnerability. What we can say already is that mitigation will be a marathon, not a sprint. We expect to see more application-specific exploits soon and the situation is still very dynamic.”

Vulnerability Description

Logging applications are mistakenly believed to be passive in that they simply have to write messages to a log file or database. This view ignores the processing done before the message is logged. Further, any logging application that will be used by the masses requires functionality to be able to look up log data remotely.

This will often mean that the lookup call needs to be logged in a directory and stored in memory. It is this process that is abused by a potential attacker. In a very simplified way, the attacker is able to abuse this process to load untrusted code.

The attack chain will begin with the attacker logging code that is intended to expand and start the attack. This is followed by the Log4j attempting to resolve what it perceives to be an incomplete variable by the logger, namely the attacker, and then connects to a malicious server controlled by the attacker. The malicious server will then send data, in the form of an object, designed to compromise the victim’s machine.

As to what the attacker can achieve once the victim’s server with Log4j on it is compromised, Sophos Labs noted the following,

“Depending on what sort of access rights your server has on your internal network, an RCE like this could help cyber criminals to perform a wide range of nefarious tasks. As you can imagine, attackers could, in theory: leak data from the server itself; learn details about the internal network it’s connected to; modify data on the server; exfiltrate data from other servers on the network; open additional backdoors on the server or the network for future attacks; implant additional malware such as network snoopers, memory scrapers, data stealers, cryptominers…”

What is worrying about attackers who successfully exploit the vulnerability is that it is all done without credentials like a password. Access to the server using this method is does not require a username-password combination. Further, no access token is needed but rather the attacker just needs to send an innocent-looking request to a webserver to begin attempting to exploit the flaw.

Real-World Attempts at Compromise

Since the flaw became public knowledge, security researchers from several security firms have seen a drastic uptick in attempts to compromise servers using the vulnerability. Once initial access is gained researchers have seen several malware families being dropped onto compromised servers and networks.

Several botnets have been seen with perhaps the most prominent malware seen being Muhstik. The botnet will attempt to contact the logging application using a specific command. If successful a number of executables are sent to the compromised web server.

These executables will drop several payloads including the botnet and a crypto miner. Muhstik has been seen in the past to drop an encryption module to be used as part of a ransomware attack. It will be of little surprise if successfully compromised servers and machines later have all their data encrypted.

Researchers have also seen other miners being deployed after compromise, including XMRIG. The miner initially began life as a legitimate open-source program to allow users to mine the cryptocurrency Monero using the user’s CPU.

The program was quickly weaponized by hackers and installed on the victim’s machine to mine Monero for the hacker. In this instance a command is also sent as request which will then attempt to download and install XMRIG directly from GitHub.

At the time of writing two ransomware families have also been seen attempting to exploit the vulnerability. The first is Khonsari,  a new ransomware, which when encryption begins will encrypt all files in the following folders "Desktop", "Documents", "Downloads", "Videos", and "Pictures" typically found on the C:\ drive of a machine.

In an article published by ZDNet researchers based at Crowd Strike also observed the Nemesis Kitten ransomware being dropped onto already compromised machines.

The Orcus remote access trojan (RAT) has also been seen being dropped following a successful compromise. Which allows attackers a backdoor onto a compromised system to be used as they see fit. Later attacks can involve the stealing of data or the dropping of other malware strains.

In concluding Bitdefender advises the following course of action to mitigate future exploitation of the vulnerability:

• Conduct an extensive infrastructure and software application audit to identify all systems that implement the Apache Log4j2 logging framework. Then, either immediately upgrade these deployments to Log4j version 2.16.0 (Updated recommendation December 14th, 2021 as 2.15 has now been reported by Apache as susceptible to a Denial of Service attack) and deploy the configuration mitigations recommended by Apache
• Review your software supply chain and software bill of materials. Seek mitigation countermeasures or patches from either open-source software project maintainers or commercial software manufacturers for all affected systems. This is especially true for software you are running on internet-facing systems but should not be limited to such systems due to the lateral attack threat posed by the severity of this vulnerability.

▼ Show Discussion