Log4j CVE-2021-44228
Since its discovery, much has already been said about the vulnerability discovered within the Log4j logging framework, CVE-2021-44228. Similar to Heartbleed and Shellshock from the prior decade, the effects on the cybersecurity industry has been felt for months with hundreds of millions of devices, corporate networks, and cloud-based applications at-risk of exploitation.
This high severity vulnerability (CVSS severity level 10 out of 10) gave attackers the ability to launch any application they want, including the delivery of malicious payloads. There were many reports of bots actively scanning the web – for example, within the first week of discovery, it is estimated hackers launched more than 1.2 million attacks against companies in an attempt to exploit Log4j.
Automation – Efficient and Easy to Scale
As with any zero-day vulnerability, time to remediate is critical. With new zero-day application vulnerability disclosures such as Log4j, adversaries will leverage the efficiency and scale of automated vulnerability scanner tools to test thousands of URLs to identify which systems haven’t been patched and make for an easy target. This is the initial “scan-to-exploit” phase of a mass vulnerability event.
While OWASP automated threats such as credential stuffing, card cracking and web scraping often steal the headlines when it comes to bot management use cases, this Log4j event serves as a reminder on the importance of being able to detect and stop automated vulnerability scanning attempts with malicious intent (OWASP OAT-14). Such scans can be highly efficient in finding weaknesses when a security vulnerability exists.
Kasada’s expertise lies in detecting the presence of automation. Traces of automation present themselves whenever bots interact with websites, mobile apps, and APIs. Kasada’s invisible, client-side interrogation methods for automation detection actively blocks malicious vulnerability scanners aimed towards exploiting zero day vulnerabilities like Log4j CVE-2021-44228 – without requiring specific knowledge of the vulnerability itself.
Automated Vulnerability Scans to Exploit Log4j
Coinciding with the public disclosure of CVE-2021-44228 on December 9th 2021, Kasada began to observe automated attempts to exploit the websites of our customers. First attempts were detected at December 9th 7am ET while the peak number of attempts were observed approximately 24-hours post disclosure. Since then, the number of attempts have subsided, likely due to attackers moving-on to other targets once they realized the vulnerability could not be exploited. The exploit attempts observed by Kasada weren’t limited to a small number of customers as these malicious requests were seen across nearly our entire customer base. This demonstrates how automated vulnerability scanning is pervasive for those operating on the Internet.
The figure above shows automated Log4j exploitation attempts across Kasada customers where the Java Naming and Directory Interface (JNDI) received a log message that included a specific formatting of “${jndi}” command within the HTTP.
From the very first request, Kasada’s client interrogation method successfully stopped the requests by detecting the underlying off-the-shelf and open-source automation tools attempting to exploit the Log4j vulnerability.
Summary
Applying a bot mitigation tool that is able to detect and stop automated threats, in real-time, serves as an important defense layer when used in concert with Web Application Firewall (WAF) rule updates and application software upgrades. In doing so, businesses are better prepared for the initial scan-to-exploit phase of a mass event before the vulnerability is effectively contained.
This layer of defense against scanning tools provides value for newly discovered vulnerabilities, such as the Log4j event presented in this example, and also more common automated web application exploit attempts such as a SQL injection attack.
