Mehul Revankar
On December 9, 2021, a critical zero-day vulnerability affecting Apache’s Log4j2 library, a Java-based logging utility, was disclosed to the world and broke the internet.
As the third most used computer language, Java is practically ubiquitous, and its Log4j2 library is extremely popular, with an estimated 15 billion devices around the globe currently running Java. The worst part is that Log4j is hard to find and easy to exploit, which places hundreds of millions of Java-based applications, databases and devices at severe risk.
The full scope of risk presented by the vulnerability is unprecedented, spanning every type of organization across every industry. Due to the ease of the exploit combined with the difficulty in uncovering the vulnerability within your organization, Log4Shell is the proverbial needle in a haystack.
Cybersecurity and Infrastructure Security Agency director Jen Easterly noted that Log4Shell is the “most serious” vulnerability she has witnessed in her decades-long career. She urged business leaders not to delay remediation processes, noting that this vulnerability could take years to address. Remediating this vulnerability would not be a simple, one-and-done process, and multiple detection methods would be required.
Quick to patch, quicker to exploit
As many companies prepared to operate with skeleton IT staff in the last two weeks of 2021, hackers and attackers saw an opportunity. It didn’t take long for this critical Java vulnerability to be exploited in the wild. Nearly 1 million attack attempts were launched in just 72 hours following the vulnerability’s disclosure.
What’s worse, as part of an ongoing information-gathering operation, notorious Chinese hacking group APT41, which breached local government agencies in at least six U.S. states in the last 10 months, quickly leveraged Log4Shell as the primary vector to infiltrate at least two of the states’ computer systems.
The Qualys Research Team pulled recent data from the Qualys Cloud Platform, revealing that 30% of Log4j instances remain unpatched. Considering the recent APT41 attack, organizations that continue to leave this flaw unaddressed are hitting the snooze button when it comes to the wake-up calls that China and other adversaries are delivering.
Enterprise IT response to Log4Shell, by the numbers
We index more than 10 trillion data points across our installed enterprise customer base and completes 6 billion IP scans per year with 75 million cloud agents deployed in hybrid IT environments globally.
To shed a unique light on Log4Shell’s impact one month into the disclosure, our team analyzed anonymized security data from across its global network.
The results include:
Log4Shell exposure
We scanned more than 150 million IT assets, across all geographies, flagging 22 million vulnerable app installations. Of these, more than 80% were open source applications. Log4Shell was detected in more than 3 million vulnerable instances.
Log4Shell threat landscape
Nearly 68,000 vulnerabilities were found in cloud workloads and containers across the U.S. and EMEA, reinforcing the recommendation that enterprises need to monitor running containers for flaws like Log4Shell.
CISA and NCSC reported 1,495 products vulnerable to Log4Shell, and of those, we observed 1,065 products across 52 publishers currently in use.
Surprisingly, more than 50% of application installations with Log4j were flagged as “end-of-support.” This means that these publishers will likely not be providing Log4Shell security patches for these apps.
The vulnerability was detected in more than 2,800 web applications. Since web apps are public facing, this was the first line of defense for many enterprises looking to fend off early attacks. In the U.S., most detections occurred before/during the holiday period, while in the EU, detections spiked after the holidays.
Vulnerability trends
The vast majority of the vulnerable assets (over 80%) were on Linux. A total of 98 distinct Log4j versions were observed in use, 55% of which were vulnerable versions.
There was a 20% spike in detections as the New Year arrived and employees returned to work. Within the first month, we observed that 12% of total Log4j installations were vulnerable, while only 5% were not.
Remediation trends
The average time to remediation after detection was 17 days. Systems that could be exploited remotely were patched faster (12 days), while internal systems were patched at a slower pace.
After the first month, remediation efforts plateaued and began trending down, quite likely because security teams were finding it easier to mitigate Log4Shell rather than permanently fixing it.
Attack patterns
Our threat intelligence research team observed ransomware attack attempts by Conti, Khonsari and nation state-backed adversaries based on Log4Shell.
We detected 22,000 potential attacks per week at the height of the crisis. Many of these were scattershot “spray and pray” attacks trying to infect as many systems as possible quickly. Our data indicates that threat actors were trying to take advantage of the holiday season window of opportunity.
Attacks trended down in January, as enterprise IT teams rolled out mitigating controls and patches.
What’s next?
Although critical vulnerabilities as severe as Log4Shell are rare, the discovery of another weakness just as bad (or worse) is inevitable. That’s why all enterprises, large and small, are well advised to invest in solutions that can aid security operations, IT asset management, vulnerability detection and response, cloud security, EDR/XDR and web app protection.
CxOs should ensure that their security and IT Ops teams have a unified view of the organization’s risk posture. Real-time threat intelligence helps enterprises continuously assess, monitor and report on the latest and greatest security threats so that when “next time” inevitably arrives, we’ll be ready.
Comment