Since December 10th, 2021, days after industry experts discovered a critical vulnerability known as Log4Shell in servers supporting the game Minecraft, bad actors have made millions of exploit attempts of the Log4j 2 Java library, according to one team tracking the impact. The vulnerability is a potential threat to millions more applications and devices across the globe.
In this article, we’ll answer some frequently asked questions about the Log4j vulnerability. We will continue to add more answers as new questions come up.
What is Log4Shell?
Log4Shell is a software vulnerability in Apache Log4j 2, a popular Java library for logging error messages in applications. The vulnerability, published as CVE-2021-44228, enables a remote attacker to take control of a device on the internet if the device is running certain versions of Log4j 2.
Apache issued a patch for CVE-2021-44228, version 2.15, on December 6, 2021. However, this patch left part of the vulnerability unfixed, resulting in CVE-2021-45046 and a second patch, version 2.16, released on December 13. Apache released a third patch, version 2.17, on December 17 to fix another related vulnerability, CVE-2021-45105. They released a fourth patch, 2.17.1, on December 28 to address another vulnerability, CVE-2021-44832.
Attackers can exploit the vulnerability using text messages to control a computer remotely. The Apache Software Foundation, which publishes the Log4j 2 library, gave the vulnerability a CVSS score of 10 out of 10, the highest-level severity score, because of its potential for widespread exploitation and the ease with which malicious attackers can exploit it. While mitigation evolves and the damage unfolds, the fundamentals of the Log4j vulnerability won’t change.
Check out this session from Perform 2023 conference “Does your CISO know the organizational exposure to the next Log4Shell?”
When did experts discover the original vulnerability in the Log4j 2 library?
Security researcher Chen Zhaojun of Alibaba, China’s largest e-commerce company, first reported the vulnerability to the Apache Foundation (an open-source project) on November 24. They discovered the attack December 9 on servers that host the game Minecraft. After further forensic analysis, they realized cybercriminals discovered the gap earlier, and have exploited it since at least December 1, 2021.
What’s the risk from the Log4Shell vulnerability in the Log4j 2 library?
Log4Shell is considered a zero-day vulnerability because malicious actors likely knew about and exploited it before experts did.
What makes the log4j vulnerability so dangerous is how ubiquitous the Log4j 2 library is. It’s present in major platforms from Amazon Web Services to VMware, and services large and small. The web of dependencies among affected platforms and services means patching can be a complex and possibly time-consuming process.
In particular, it’s the ease of exploiting the vulnerability that compounds its impact. The Log4j 2 library controls how applications log strings of code and information. The vulnerability enables an attacker to gain control over a string and trick the application into requesting and executing malicious code under the attacker’s control. As a result, attackers can remotely take over any internet-connected service that uses certain versions of the Log4j library anywhere in the software stack.
What is Log4j 2, and what does it do?
As the most widely used logging framework on the internet, organizations across the industry have integrated Apache Log4j 2 into myriad applications. This includes major cloud services such as Apple, Google, Microsoft, and Cloudflare, as well as platforms like Twitter and Stream.
Log4j 2 logs messages from software and searches for errors afterward. The data range is broad, from basic browser and web page information to technical details about the system Log4j 2 runs on.
Not only can the Log4j 2 library create simple logs, but it can also execute commands to generate advanced logging information. In doing so, it can also communicate with other sources, such as internal directory services.
How does the Log4Shell vulnerability cause damage?
Because the Log4j 2 library can communicate with other sources and internal directory services, attackers can easily feed Log4j 2 with malicious commands from the outside and make it download and execute dangerous code from malicious sources.
How attackers can exploit Log4j 2 depends on the specifics of the affected system. So far, the vast majority of malicious activity has been mass scanning to fingerprint vulnerable systems. Attackers have been exploiting the vulnerability to compromise virtualization infrastructure, install and execute ransomware, steal system credentials, take broad control of compromised networks, and exfiltrate data, according to a Microsoft report.
As reports continue to mount regarding the exploitability of Log4Shell, the possibilities for malicious activity seem exponential. Malicious actors can execute any code on the attacked system, for example, to access sensitive configuration data. In capturing this data, attackers could gain full control of a system — and all its data and applications. This is like a burglar who has keys to the front door and the combination to the safe inside.
What are the vulnerabilities published so far?
CVE has published four vulnerabilities related to Log4Shell:
Vulnerability | What’s vulnerable | Log4j 2 patch |
CVE-2021-44832 (latest) | An attacker with control of the target LDAP server could launch a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI. | Log4j 2.17.1 for Java 8 and up.
This is the latest patch. |
CVE-2021-45105 (third) | Left the door open for an attacker to initiate a denial-of-service attack by causing an infinite recursion loop on self-referential lookups. | Log4j 2.17.0 for Java 8 and up. |
CVE-2021-45046 (second) | Made it possible for attackers to craft malicious input data that could cause an information leak or remote code execution. | Log4j 2.12.2 for Java 7 and 2.16.0 for Java 8 and up |
CVE-2021-44228 (original) | Possible for an attacker to execute random code using the message lookup functionality. | Log4j 2.12.2 and Log4j 2.16.0 |
To ensure systems that use Log4j 2 are protected against these vulnerabilities, IT teams should apply the latest patch, Log4j 2.17.0 for Java 8 and up.
How does Log4Shell affect consumers?
Many companies and organizations use the Log4j library in numerous applications and infrastructure, either directly, or through third-party use. In the consumer sector, much network-enabled storage and smart home equipment also use the Log4j 2 library. Users should disconnect them from the Internet until their manufacturers make updates available.
Most companies have placed a corresponding security message on their websites describing what they are doing about the Log4j vulnerability.
Consumers should install software updates provided by the vendors they use. They should also try to find out whether Log4Shell affects the organizations that host the sites and services they use. If so, they should find out what measures the organizations are taking to safeguard their personal information.
What should IT security teams do about the Log4Shell vulnerability?
Organizations that use Log4j 2 in their own applications and infrastructure should update them immediately. The same applies to third-party applications. The version 2.17.0 release fully secures the library against the Log4Shell vulnerability.
Because Log4Shell affects so many systems and is so easy to exploit, organizations must act swiftly to protect their systems. To quickly identify affected systems, organizations need a solution like Dynatrace Application Security that can immediately and automatically identify vulnerable systems and their dependencies, and help you prioritize the most critical systems to update first, especially on code running in production.
As Log4Shell continues to threaten companies’ applications and sensitive data, Dynatrace Application Security enables organizations to gain real-time insight into which assets the vulnerability affects at run-time, and which are the highest priority, while also monitoring the whole multicloud environment. This helps you maintain real-time awareness of malicious activity as you address the impact of the Log4Shell vulnerability.
To learn more about how the Log4Shell vulnerability works and how to mitigate it, check out the following resources:
- Log4Shell: Identifying and minimizing production risk blog
- Log4j vulnerability (Log4Shell) Dynatrace security alert
- Log4Shell vulnerability: Identifying and minimizing production risk webinar
- Log4Shell vulnerability discovery and mitigation require automatic and intelligent observability blog
- Dynatrace Log4Shell resource center webpage
Also, check back on this FAQ blog for frequent updates.
Looking for answers?
Start a new discussion or ask for help in our Q&A forum.
Go to forum