The Log4j vulnerability, also known as Log4Shell, is a critical vulnerability discovered in the Apache Log4j logging library in November 2021. Log4Shell essentially grants hackers total control of devices running unpatched versions of Log4j.
Malicious actors can use the Log4j flaw to run almost any code they want on vulnerable systems.
Researchers consider Log4Shell a “catastrophic” security vulnerability because it is so widespread—Log4J is one of the most widely deployed open source programs in the world—and so easy to use. Jen Easterly, director of the US Cybersecurity and infrastructure Security Agency (CISA), called it “one of the most serious I've seen in my entire career, if not the most serious.”
Log4Shell fueled a surge of cyberattacks in December 2021. IBM's X-Force Threat Intelligence Index recorded a 34% increase in vulnerability exploitation between 2020 and 2021, attributed mainly to Log4Shell.
Log4Shell was patched shortly after discovery but will pose a risk for years, because Log4J is deeply embedded in the software supply chain. The US Department of Homeland Security (link resides outside ibm.com) estimates it takes at least a decade to find and fix every vulnerable instance.
Gain insights to prepare and respond to cyberattacks with greater speed and effectiveness with the IBM Security X-Force Threat Intelligence Index.
Register for the Cost of a Data Breach report
Log4j is a logging framework developed by the Apache Software Foundation. As the name suggests, Log4J is a logger. It records important information like error messages and user inputs in a program.
Log4J is an open source software library, a package of prewritten code that developers can freely use. Instead of writing their own loggers, developers can plug the Log4J library into their apps. This convenience is why Log4J is so widespread, built into products from major organizations like Microsoft and Amazon, to name a few.
Log4Shell—Common Vulnerability and Exposure (CVE) identifier, CVE-2021-44228—is a remote code execution (RCE) vulnerability present in some versions of Log4J. The flaw affects Apache Log4J 2, versions 2.14.1 and earlier. Log4J 2.15 and later, and all versions of Apache Log4J 1, are unaffected.
Log4Shell arises from how older versions of Log4J 2 handle Java Naming and Directory Interface (JNDI) lookups. JNDI is an application programming interface (API) that Java applications use to access resources hosted on external servers. A JNDI lookup is a command that tells the app to go to a server and download a specific object, like a piece of data or a script. Older versions of Log4J 2 automatically run any code downloaded this way.
Users can send JNDI lookups to vulnerable versions of Log4J by including them in log messages. Doing so is simple. For example, in older versions of Minecraft Java Edition, which use Log4J to record user messages, a user can type the JNDI lookup into the public chat window.
Hackers can use this JNDI functionality to run malicious, arbitrary code remotely. First, the hacker sets up a server that uses a common protocol, like Lightweight Directory Access Protocol (LDAP) to avoid drawing attention. Next, they store a malicious payload on that server, such as a malware file. Finally, they send a JNDI lookup to a program, telling it to go to the attacker's LDAP server, download the payload, and run the code.
Security researchers at tech giant Alibaba discovered Log4Shell on 24 November 2021. It immediately received the highest possible Common Vulnerability Scoring System (CVSS) score: 10 out of 10. A few factors contributed to this rating.
- Log4Shell was a zero-day vulnerability, meaning no patch was available when it was discovered. Threat actors might use Log4Shell while Apache was working on a fix.
- Log4J is also one of the most widely used logging libraries, built into consumer endpoints, web applications and enterprise cloud services. According to Wiz and EY, 93% of all cloud environments were at risk (link resides outside ibm.com) when Log4Shell was discovered.
- Companies can't always tell right away if they're vulnerable. Log4J is often present in networks as an indirect dependency, meaning the company's assets might not use Log4J, but they rely on other apps and services that do.
- Finally, Log4Shell is straightforward to use. Hackers need no special permissions or authentication. They can wreak havoc by typing malicious commands into public forms like chat boxes and login pages. And because Log4J can communicate with other services on the same system, hackers can use Log4J to pass payloads to other parts of the system.
By 9 December 2021, proof-of-concept code on how to use Log4Shell was posted on GitHub, and hackers were mounting attacks. Major companies and services like Minecraft, Twitter and Cisco were exposed. At the peak of Log4Shell activity, Check Point observed more than 100 attacks every minute, affecting more than 40% of all business networks globally (link resides outside ibm.com).
The earliest attacks spread botnet and cryptomining malware. Some hackers used the flaw to start fileless attacks, sending malicious scripts to Windows and Linux computers to make them divulge passwords and other sensitive information.
Multiple ransomware gangs seized on Log4Shell. Notably, hackers spread the Khonsari ransomware strain through Minecraft. The Night Sky ransomware targeted systems running VMware Horizon.
Even nation-state actors joined in. Hackers associated with China, Iran, North Korea and Turkiye were seen using the vulnerability.
Apache rolled out the first patch (Log4J version 2.15.0) on 10 December 2021. However, that patch left another vulnerability exposed—CVE-2021-45046—which allowed hackers to send malicious commands to logs with certain nondefault settings.
Apache released a second patch (Log4J version 2.16.0) on 14 December 2021. It too had a flaw—CVE-2021-45105—which allowed hackers to start denial of service (DoS) attacks.
The third patch, Log4J version 2.17, fixed the DoS flaw but left one final vulnerability—CVE-2021-44832—that allowed hackers to seize control of a Log4J component called an "appender" to run remote code. Apache addressed this with a fourth and final patch, Log4J version 2.17.1.
While Log4J 2.17.1 closed Log4Shell and all its related vulnerabilities on Apache's end, cyberthreats still use the flaw. As recently as May 2023, Log4Shell remained one of the most commonly used vulnerabilities (link resides outside ibm.com).
Log4Shell persists for several reasons.
The first is that Log4J is buried deep in many companies' software supply chains. Today, many apps are built by assembling preexisting open source software libraries. This process is convenient, but it also means that organizations have limited visibility into all the components that make up their apps. Old versions of Log4J can be easily overlooked.
When a vulnerable version of Log4J is patched, it doesn't always stay patched. In November 2022, Tenable reported (link resides outside ibm.com) that 29% of the assets still vulnerable to Log4Shell were “recurrences.” They were patched in the past, but the flaw reappeared. This scenario happens because when people build or update apps, they sometimes accidentally use software libraries that still contain unpatched versions of Log4J.
Finally, hackers developed a savvy way to cover their tracks. According to CISA (link resides outside ibm.com), some hackers use Log4Shell to break into a network, and then they patch the asset. The company thinks it is safe, but the hackers are already ‘in.’
The latest versions of Log4J are free of Log4Shell. Cybersecurity experts recommend that security teams focus on ensuring all instances of Log4J in their systems are current.
Updating Log4J can be a slow-going process, as companies often need to dig deep into their assets to find it. In the meantime, security teams can use continuous vulnerability scanning and threat detection tools like attack surface management (ASM) and endpoint detection and response (EDR) platforms to monitor internet-facing assets. Experts recommend that incident response teams thoroughly investigate any hint of Log4Shell activity.
After Log4Shell went public, many firewalls, intrusion detection systems (IDSs) and intrusion prevention systems (IPSs) added rules to spot Log4Shell exploitation. These tools can help security teams detect and block traffic from attacker-controlled servers.
18 July 2013: Apache releases Log4J 2.0-beta9, the first version to support the JNDI plug-in. Although the vulnerability will not be discovered until years later, Log4Shell is present from this moment forward.
24 November 2021: Security researchers from Alibaba discover Log4Shell and report it to Apache. Apache begins work on a patch but does not release a public security advisory.
9 December 2021: Security researchers from Alibaba find evidence of Log4Shell being discussed in the wild, and proof-of-concept exploit code is posted to GitHub.
10 December 2021: Apache issues the first patch, and Minecraft developers discover Log4Shell in Minecraft Java Edition. The cybersecurity community quickly realizes the severity of the situation, and organizations begin scrambling the lock down their systems.
11 December 2021: Cloudflare finds evidence that threat actors began exploiting Log4Shell earlier than first thought — as early as December 1.
14 December 2021: CVE-2021-45046 is discovered, and Apache releases a patch to address it.
17 December 2021: CVE-2021-45105 is discovered, and Apache releases a patch to address it.
28 December 2021: CVE-2021-44832 is discovered, and Apache releases a final patch. From Log4J version 2.17.1 onward, Log4Shell is fully remediated.
4 January 2022: The US Federal Trade Commission (FTC) (link resides outside ibm.com) announces it intends to pursue any companies that expose consumer data to hackers because they failed to address Log4Shell.
May 2023: Check Point finds that Log4Shell is still the second-most commonly exploited vulnerability.
Outsmart attacks with a connected, modernized security suite. The QRadar portfolio is embedded with enterprise-grade AI and offers integrated products for endpoint security, log management, SIEM and SOAR—all with a common user interface, shared insights and connected workflows.
Implemented on premises or in a hybrid cloud, IBM data security solutions help you gain greater visibility and insights to investigate and remediate cyberthreats, enforce real-time controls and manage regulatory compliance.
Proactive threat hunting, continuous monitoring and a deep investigation of threats are just a few of the priorities facing an already busy IT department. Having a trusted incident response team on standby can reduce your response time, minimize the impact of a cyberattack, and help you recover faster.