Following the discovery of Log4Shell, a vulnerability in Log4J2, Elastic released a blog post describing how users of our platform can leverage Elastic Security to help defend their networks. We also released an advisory detailing how Elastic products and users are impacted.
On December 9th, 2021, Apache disclosed CVE-2021-44228 (colloquially referred to as Log4Shell), a remote code execution vulnerability in the Apache Log4j library, a Java-based logging tool widely used in applications around the world. A highest possible severity score of 10 has been assigned to this exploit.
If you find yourself baffled by the influx of events and newly discovered vulnerabilities affecting the popular Apache Log4j Java logging library, this post is for you. This post aims to survey the entire flow of events since the first discovery of CVE-2021-44228, AKA Log4Shell, to the present date, explain the important aspects of each related vulnerability, as well as provide practical remediation and mitigation advice.
No matter your role in tech, you’ve probably already heard about, or dealt with, the ubiquitous Log4Shell vulnerability impacting a large number of Java applications. To help spread the latest info on this critical, zero-day vulnerability, we recently hosted a webinar to get everyone up to speed.
Since December 10, in a span of just 20 days, there have been four different vulnerabilities published against Log4j. Engineers who worked long hours to update their Log4j versions to 2.15.0 on December 11th, were told three days later that they needed to do it all over again and upgrade to version 2.16.0. This is not sustainable. And yet the risks are high. Looking backward, we see that Log4j has been vulnerable since 2013 to the kinds of attacks described in CVE-2021-44228.
As CVE-2021-44228, a.k.a "Log4Shell" or Apache Log4j Remote Code Execution vulnerability continues to send shockwaves across the world of software, many security vendors and practitioners are rushing to provide recommendations on dealing with the crisis. If you need immediate help mitigating the impact of Log4shell, we're here for that. But the goal of this post is to look forward. This isn't the first and won't be the last high-impact vulnerability to be uncovered. So it's worth preparing your organization for the next one, so that you can respond faster, mitigate and remediate sooner - and have fewer weekends like the last one.
By now, we’re all likely tired of talking about Log4j and nodding our heads over Zoom when we all discuss the ramifications of exploitation of this small, but very pervasive and powerful vulnerability. At the risk of adding another layer of complexity to the information we have learned about Log4j, I think we are remiss not to mention IT-OT (Information Technology-Operational Technology) convergence and how it could be an enabler for Log4j to impact our critical infrastructure.
Another — though unlikely — vulnerability was discovered in Log4j’s latest versions: CVE-2021-44832. This is an Arbitrary Code Execution exploit using, yet again, the now infamous JNDI functionality. The vulnerability lets an attacker with control over the Log4j configuration set a malicious datasource for the JDBC (Java DataBase Connectivity API) appender. The datasource refers to an attacker-controlled JNDI URI that will execute arbitrary code on the application using Log4j.
Following the Dec. 9, 2021, announcement of the Log4j vulnerability, CVE 2021-44228, CrowdStrike Falcon OverWatch™ has provided customers with unrivaled protection and 24/7/365 vigilance in the face of heightened uncertainty. To OverWatch, Log4Shell is simply the latest vulnerability to exploit — a new access vector among a sea of many others.