Apache Log4j Vulnerabilities: The Basics
A series of exploits leveraging vulnerabilities in the popular Apache Log4j Java library were uncovered recently, prompting tremendous cybersecurity activity in response to the threats. The Log4j module allows Java-based applications to better handle internal event logging and is used by many popular applications, cloud-based services, and even operating systems. Because of Log4j's ubiquity, the threat these vulnerabilities represent is significant.
Attackers can manipulate the contents of Log4j log files to include a malicious payload granting remote code execution (RCE). In the common vulnerability scoring system (CVSS), this vulnerability is rated at a 10 out of 10 severity level. Multiple security researchers have identified the vulnerability being actively exploited in the wild. It is anticipated that a self-propagating worm is being developed to leverage this vulnerability to spread malware even further afield.
Log4j Attack Chain
Summaries of Associated CVEs
Affects all Log4j versions from 2.0-beta9 to 2.16.0 for Java 8 and 2.12.2 for Java 7.
Attackers capable of manipulating the Thread Context Map can force a recursive lookup within the targeted application. This recursion results in a StackOverflowError crashing the process and causing a denial of service (DoS).
Affects all Log4j versions from 2.0-beta9 to 2.15.0 for Java 8, excluding 2.12.2 for Java 7.
CVE-2021-45046 leverages an incomplete fix for CVE-2021-44228 in Log4j version 2.16.0. Certain non-default configurations were found to create an opening for attackers to perform RCE in some circumstances as well as local code execution in all other environments.
Affects all Log4j versions < 2.12.2 for Java 7 and < 2.16.0 for Java 8.
CVE-2021-44228 was the first released in the recent chain of Log4j vulnerabilities. By leveraging unsafe lookups with certain protocols handled by the Log4j Java Naming and Directory Interface (JNDI), attackers may create payloads that grant unauthenticated RCE. This provides attackers with an easily exploitable means to exfiltrate data or install malware on targeted systems.
Timeline of Events
The initial Log4j vulnerability is disclosed to Apache by Chen Zhaojun of Alibaba Cloud Security Team.
The CVE-2021-44228 vulnerability is recorded into the CVE list by MITRE.
Apache developers commit a fix to the codebase addressing the issue.
Security researchers announce a 0-day exploit, nicknamed "Log4shell", and publish a proof of concept (PoC).
First massive waves of exploit attempts of CVE-2021-44228 are seen in the wild. Researchers with Greynoise.io cite a 5x increase in traffic per sensor related solely to Log4Shell exploits by mid-day EST.
Apache Releases Log4j 2.15.0 for Java 8. Unfortunately, this patch does not fully remediate the vulnerabilities. Researchers determine that specially crafted payloads could still gain RCE in certain non-default configurations.
Cybersecurity and Infrastructure Security Agency (CISA) Director Jen Easterly releases a public statement. The statement highlights the severity of the exploit and the enormous number of machines that are vulnerable. The CISA director calls on software vendors to communicate software dependencies with customers to better prioritize their software update and patching efforts.
Apache Releases Log4j 2.12.2 for Java 7 users and Log4j 2.16.0 for Java 8. Security researchers soon discover a means to induce a DoS attack against affected targets through a JNDI lookup recursion.
While most Log4j attacks target Linux servers, researchers identify a new strain of ransomware, named "Khonsari", that attacks Windows systems. Bitdefender reports in a blog post that the malicious payload was downloaded as a .NET binary written in C#.
Security researchers record over 800,000 instances of Log4j attacks traversing the internet within 72 hours of release of PoC.
Cybersecurity companies CrowdStrike and Mandiant confirmed that Chinese and Iranian state actors are leveraging the Log4j vulnerability.
CISA issues Emergency Directive 22-02: Mitigate Apache Log4j Vulnerability, directing federal civilian executive branch agencies to address Log4j vulnerabilities.
Detecting Vulnerable Versions on Systems with CATO
There are currently two principal methods of detecting whether systems are using vulnerable Log4j libraries. The first scans the local file systems of servers for packages containing the vulnerable library. The second uses network-based scanners to attempt to trigger the exploit in a benign manner. Many network-based scanners use a third-party solutions such as dnslog.cn, interact.sh, or other servers outside of the target network environment.
CyberPoint's CATO systems are housed safely within the customer's network. CATO's Log4j detection module can be configured to keep communication inside the customer network, rather than use an external provider. This has the benefit of preventing third parties from tracking a customer's vulnerable systems and provides a means of testing systems within restricted networks where exiting traffic may be blocked, but traffic between systems is allowed.