Dealing with Log4Shell has become a thorn in the side of every security professional this festive period – novel exploitation attempts seem to appear every day, aiming to harvest sensitive data and remotely execute arbitrary code to set up crypto-miners, botnets, and ransomware.

But how does a vulnerability in a logging package lead the adversary to gain initial access to all software that uses the vulnerable version of Java? The New Year has brought new Log4Shell (or Log4Shell-like) problems, but understanding the differences between the issues is key to properly defending your systems.

To get a clear answer to that question, you need to understand where it came from, how it has been exploited, and how organizations are mitigating the risk today.

Log4Shell: Understanding Where It Came From

Despite the Log4Shell name appearing everywhere in the world of cybersecurity right now, we are not talking about a singular problem. Instead, the Log4Shell vulnerability is a collection of CVEs relating to the Log4j 2 logging package on vulnerable versions of Java.

Much to the surprise of every security researcher battling with new ransomware gangs and zero-days, the humble beginnings of the Log4Shell crisis starts in one of the most popular games on the market right now (and not with a foreign nation-state attack team!)

Origins in an unlikely place – The Minecraft Bug

Who would have thought that Minecraft hackers would have exposed the vulnerability which would set the internet on fire? Not many people, especially when what would become known as Log4Shell was only being used to kick players off their own accounts.

After initial discovery towards the end of 2021, Minecraft players quickly found a way to wrestle control of other players’ accounts by using a string similar to the following:

${jdni:[protocol]://[malformed username or user agent]}

When this was entered into the chatbox during a session, the exploit code would give the attacker control of the target system’s account. As we now know, the chatbox was allowing direct communication with the Minecraft server through the Log4j logging package.

At this stage, no one knew the full extent of the vulnerability and how prevalent it was across a wide range of systems due to its presence in the Java library. Because the Minecraft Java version of Minecraft was a notable example of a vulnerable Java application, Microsoft quickly released patches and mitigating workarounds to stop a remote attacker in their tracks.

The Microsoft Patch

Thanks to Microsoft’s incident response, affected versions of Minecraft were no longer vulnerable to the exploit strings that were previously wreaking havoc on Minecraft servers. The world quickly found that this vulnerability wasn’t going away because Minecraft was patched.

In fact, in the wake of the Minecraft patch, we have seen almost all software and server technology that incorporates Java has needed urgent updating to stop the adversary from directly interacting with the server-side technology.

Microsoft found that a specifically crafted format string attack could exploit the vulnerable Log4j 2 logging package and allow for remote code execution.

Connecting to the server through a malicious LDAP server or another protocol that allowed for malware to be remotely loaded, the remote code execution vulnerability has shown that potentially vulnerable components on a target system can be effected via a wide range of vectors, causing security professionals serious headaches with this critical vulnerability.

At this point, we now had seen many security professionals and researchers start to worry. How common is this flaw and how easy is it to fix? As a large number of exploits started to appear on the internet, people started to describe Log4Shell as the event that “set the internet on fire” and there was a distinct worry if any system that was running Java would be safe over the 2021 Christmas period.

Mitigating Log4Shell in your Organization

Despite Log4Shell’s infamy and potential for exploitation, mitigating the risk present by the Log4j 2 vulnerability has been relatively straightforward for all instances where the faulty logging package has been known to be. But for many organizations, that’s the hard part.

Finding the package has been difficult due to many unexpected instances of the Log4j logging package and its knock-on effects for other critical components (such as the emerging Log4Shell-like H2 critical vulnerability).

If you are still searching for a way to diagnose your own systems, the AppSec Phoenix: Log4Shell – Updates and Latest Recommendations page contains mitigation workflows, testing recommendations, and scanner recommendations.

Patching

After scanning and understanding your organization’s threat level, patching using the official updates for all relevant applications and the official Java update (preferably to version 2.17, especially if you are using certain non-default configurations) is the next essential step.

As our understanding of the Log4Shell vulnerability is still changing, security researchers should be vigilant to keep updating to a newer Java version and patching a vulnerable app as soon as the appropriate updates become available.

Workarounds

Some of the workarounds that were initially published by Microsoft and later the Java team are now ineffective in protecting vulnerable applications. Although some vulnerable systems are stuck using outdated versions of Java (and, in turn, the vulnerable Java Naming Directory Interface), finding a way to update the systems is the best way to protect yourself from malicious code.

If you need a short-term fix for your Log4Shell problem, identifying the weakness through LOG4J_FORMAT_MSG_NO_LOOKUPS and changing the value to TRUE is the best way to stop the adversary from gaining access to your web servers or otherwise compromising your systems.

Although Java versions prior to 2.10 are thought to be safe, you can double-guard your older Java systems by changing all instances of %m to %m{nolooksup}. The official Java support for this can be found here.

Log4Shell: Worth the Worth]]?

If you have any interaction with vulnerable software that contains the Log4j 2 logging package, security researchers are right in saying that there is an immediate need for those responsible for them to update and fully patch the systems as soon as possible. Failing to do so allows the adversary a range of ways into the back-end of your organization’s server and could spell disaster if no action is taken.

Update and patch is always the most basic advice for any critical vulnerability that appears. But due to Java’s presence in a wide range of software, it is now necessary to use scanners to find the faults in your own security posture and address them as soon as possible.

Consult the AppSec Phoenix: Log4Shell – Updates and Latest Recommendations page to find the best workflows, command-line arguments, and successful exploitation information to protect your organization and lockdown your systems.