blog

The Ultimate Guide to Log4Shell: Where Did It Come From and How Do I Stop It?

log4j how to fix

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.

<Microsoft’s CVE-2021-44228 and CVE-2021-45046 exploit vectors> Source: Microsoft

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.

Francesco is an internationally renowned public speaker, with multiple interviews in high-profile publications (eg. Forbes), and an author of numerous books and articles, who utilises his platform to evangelize the importance of Cloud security and cutting-edge technologies on a global scale.

Discuss this blog with our community on Slack

Join our AppSec Phoenix community on Slack to discuss this blog and other news with our professional security team

From our Blog

Explore ASPM’s role in modern application security, offering a panoramic view that extends beyond code vulnerabilities. This guide demystifies concepts like traceability, reachability analysis, and asset lineage, pivotal for securing digital assets. Learn how ASPM empowers organizations with actionable insights for precise vulnerability management. #Cybersecurity #ASPM #ApplicationSecurity
Francesco Cipollone
Explore the transformative role of ASPM in cybersecurity. Uncover how Application Security Posture Management aligns business and security objectives for effective vulnerability management and risk reduction. Discover Phoenix Security’s innovative approach to tackling the staggering challenge of CVEs with a strategic focus on prioritization. #ASPM #Cybersecurity #VulnerabilityManagement
Francesco Cipollone
Explore the critical insights into the latest container security vulnerabilities named leaky vessels, including CVE-2024-21626, CVE-2024-23651, CVE-2024-23653, and CVE-2024-23652, BuildKit flaws, with our comprehensive guide on mitigation strategies, best practices for application security, and tips for robust vulnerability management in Docker and Kubernetes environments. Stay ahead in securing your container deployments against potential threats with ASPM help
Francesco Cipollone

Jeevan Singh

Founder of Manicode Security

Jeevan Singh is the Director of Security Engineering at Rippling, with a background spanning various Engineering and Security leadership roles over the course of his career. He’s dedicated to the integration of security practices into software development, working to create a security-aware culture within organizations and imparting security best practices to the team.
In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

James Berthoty

Founder of Latio Tech

James Berthoty has over ten years of experience across product and security domains. He founded Latio Tech to help companies find the right security tools for their needs without vendor bias.

Christophe Parisel

Senior Cloud Security Architect

Senior Cloud Security Architect

Chris Romeo

Co-Founder
Security Journey

Chris Romeo is a leading voice and thinker in application security, threat modeling, and security champions and the CEO of Devici and General Partner at Kerr Ventures. Chris hosts the award-winning “Application Security Podcast,” “The Security Table,” and “The Threat Modeling Podcast” and is a highly rated industry speaker and trainer, featured at the RSA Conference, the AppSec Village @ DefCon, OWASP Global AppSec, ISC2 Security Congress, InfoSec World and All Day DevOps. Chris founded Security Journey, a security education company, leading to an exit in 2022. Chris was the Chief Security Advocate at Cisco, spreading security knowledge through education and champion programs. Chris has twenty-six years of security experience, holding positions across the gamut, including application security, security engineering, incident response, and various Executive roles. Chris holds the CISSP and CSSLP certifications.

Jim Manico

Founder of Manicode Security

Jim Manico is the founder of Manicode Security, where he trains software developers on secure coding and security engineering. Jim is also the founder of Brakeman Security, Inc. and an investor/advisor for Signal Sciences. He is the author of Iron-Clad Java: Building Secure Web Applications (McGraw-Hill), a frequent speaker on secure software practices, and a member of the JavaOne Rockstar speaker community. Jim is also a volunteer for and former board member of the OWASP foundation.

Join our Mailing list!

Get all the latest news, exclusive deals, and feature updates.