What is the Apache Log4j Vulnerability?
The Apache Log4j project, one of the most widely distributed open source software, provides logging capabilities for Java applications. Log4j is part of the Apache Log Service Project, an open source project within the Apache Software Foundation.
Log4j didn’t get much attention until December 2021, when a series of critical vulnerabilities were disclosed. The Log4j exploit started as a bug, but has since evolved into a series of security issues, which allowed attackers to run arbitrary malicious code on any system running the Log4j library. The root cause of the exploit was Log4j’s insecure implementation of Java Naming and Directory Interface (JNDI) interfaces.
This is part of a series of articles about supply chain security.
In this article:
- Log4j Exploit Explained: Technical Details and Impact
- Open Source Security in the Wake of the Log4j Vulnerability
- What Can Organizations Do To Protect Themselves?
Log4j Exploit Explained: Technical Details and Impact
On December 9, 2021, a critical zero-day vulnerability was identified in Log4j. Formally called CVE-2021-44228, the vulnerability could allow an attacker to remotely execute code on any system running the Log4j library. Several new vulnerabilities of varying severity were discovered in the weeks after the patch was released and released. In response to each of them, Log4j contributors released new fixes.
Given the widespread use of Log4j in modern applications, the impact on organizations around the world will be enormous and full recovery will take years. The original Log4j issue is estimated to exist in over 100 million server instances worldwide, and affects many popular services and providers such as Apple, Twitter, Steam, and Tesla.
This vulnerability not only affects millions of applications, it is also easy to exploit. An attacker only needs to submit a string of malicious code to be logged by Log4j. This allows an attacker to take full control of the vulnerable server and conduct remote code execution (RCE) attacks.
Since its disclosure, the Log4j vulnerability has been known to be exploited on a large scale in the wild. This vulnerability enables RCE and is easily exploitable, with numerous weaponized exploits readily available on GitHub and other open sources.
The Log4j vulnerability is a great example of how attackers can exploit vulnerabilities in common open source packages, and the dramatic impact these vulnerabilities can have. As organizations rush to patch systems, attackers can exploit this vulnerability, actively searching for vulnerable systems and launching attacks.
For more information, read these blogs from Aqua Nautilus security researchers:
- CVE-2021-44832: New Arbitrary Code Execution Vulnerability in Log4j
- CVE-2021-45046: Second Log4j Security Vulnerability Discovered
- The Nightmare Before Christmas: Looking Back at Log4j Vulnerabilities
Open Source Security in the Wake of the Log4j Vulnerability
Major vulnerabilities like Log4j represent a serious security concern for open source software. However, commercial software is equally vulnerable to vulnerabilities, and commercial software also uses open source components. This vulnerability management is an important part of modern information security.
Security fixes are voluntary
The main difference between traditional application security and open source security is that anyone can identify an open source security issue—because the source code is publicly available. In some cases, the vulnerability is not in the code itself, but in the implementation or configuration. The problem is that there is no one clearly responsible for handling security issues in open source software, and organizations must rely on the open source community to find and address vulnerabilities.
Anyone who discovers an open source security issue can and should modify the open source code to fix security issues or improve its functionality, and share the fix with others. In the open source world, everything depends on voluntary contributions. If your business wants to benefit from the work of the open source community for free, you must also contribute actively. Active participation is essential to stay current and ensure security fixes are available.
Open source may not have stringent security standards
Another problem with open source software is that many organizations implicitly trust it, so developers can download the code and use it without modification. They do not have the same stringent security standards and scrutiny that open source applications do, as do proprietary software.
Specifically with regard to the Log4j vulnerability, the Apache team responsible for Log4j took security very seriously and responded quickly to the needs of its users. Contributors showed a high level of commitment to the project. However, these reactions only occur after the damage has occurred, and there is no guarantee that the open source contributors responsible for the next security disaster will be so vigilant.
What Can Organizations Do To Protect Themselves?
Log4j vulnerabilities expose organizations to the type of risk found in other open source and proprietary code components embedded in applications. The key challenge is to understand what is at risk and how to mitigate it. Organizations can take several steps to mitigate Log4j vulnerabilities:
- Implement a DevSecOps strategy—some industry commentators are optimistic that the Log4j incident will sound the alarm for DevSecOps. It will encourage organizations to put processes in place to rapidly identify issues and deploy fixes throughout the application development lifecycle.
- Use web-based filtering—the main problem many organizations face when using Log4j is that they do not realize they are at risk. Another problem is that vendors that included Log4j didn’t patch their applications, putting users at risk. One way to address the unknown risks of Log4j is to use a web-based filtering or web application firewall (WAF). These solutions block potential vulnerabilities by detecting malicious traffic, even if the underlying vulnerability has not been remediated.
- Scan applications to identify risks—for applications that organizations manage themselves, it is critical to scan for vulnerable Log4j libraries. Vendors and organizations offer a variety of tools to find Log4j. The most popular are open source scanning tools from CERT-CC and CISA.
- Patch and repeat—if your organization becomes aware of a vulnerable application that is using Log4j, the best course of action is to patch it to the latest version of Log4j. This fixes all currently known public vulnerabilities in Log4j.
- Monitor malicious traffic—organizations that use Log4j or believe it might be present in their environment should use threat tracking technologies. This can help detect suspicious traffic, determine if an attack has occurred, and immediately respond to it.
