[By Mike Walters, President and co-founder of Action1]
Two years have passed since the cybersecurity world was rocked by the discovery of Log4Shell, a critical vulnerability in the Log4j library. First discovered on December 9, 2021, this legendary flaw exposed hundreds of thousands of systems to potential attacks. Jen Easterly, head of the Cybersecurity and Infrastructure Security Agency (CISA), called it “the most serious flaw” she has seen in her decades-long career. Since Log4Shell emerged, bad actors have been spreading various payloads through this vulnerability, including coin miners, botnets, and malware that helped them establish backdoors and carry out other illegal activities. The most notorious threats that have used Log4Shell are Dridex and Conti.
Even today, Log4Shell remains a haunting presence in the digital realm, demanding attention of cybersecurity professionals. As we approach the second anniversary of Log4Shell, let’s delve into the ongoing dangers it poses, the measures organizations should take to protect themselves, and the broader question of whether vulnerabilities in common libraries will continue to rise.
Understanding Log4Shell and Its Enduring Impact
Log4j, a logging library fundamental to Java-based applications, had been prone to the Log4Shell vulnerability for decades before its official discovery. With Java being widely used on billions of systems, including IoT devices and critical infrastructure, the vulnerability’s reach is extensive. Log4Shell exploits Log4j’s ability to resolve requests to LDAP and JNDI servers without proper validation, granting attackers the ability to execute arbitrary Java code or access sensitive information.
This vulnerability, assigned a critical score of 10 and tagged as CVE-2021-44228, affected major companies like Microsoft, Amazon, and IBM. As we enter 2023, its effects linger. The Cybersecurity and Infrastructure Security Agency (CISA) has recently warned organizations that threat actors are still frequently using the Log4Shell exploit in their attacks due to its ease of discovery through vulnerability scanning and open-source research. The agency advises organizations to prioritize patching Log4Shell in their environments.
The 2023 Arctic Wolf Labs research found that Log4j was among four of the top five external software exploits utilized by threat actors in 2022. According to Tenable, 72% of organizations remained vulnerable to Log4Shell in October 2022. We can suggest that their percentage hasn’t reduced much since then.
Why Log4Shell Persists as a Threat
The Log4Shell vulnerability presents a unique set of challenges in its detection and remediation. Despite the availability of the patch that is easy to install, identifying every system vulnerable to Log4Shell within complex infrastructures remains a formidable task. This difficulty arises from the extensive use of the Log4j library by enterprises across a wide range of infrastructures and applications, both directly and through third-party integrations.
Within this landscape, there exists a multitude of vulnerable software titles, numbering in the hundreds. Some of this software has regrettably been forgotten over time, slipping under the radar of traditional vulnerability management solutions. Even custom, homebrew software often relies on the Log4j library, further complicating the detection process.
Crucially, the task of detection should not be entrusted solely to the software itself. Instead, a more effective approach involves direct examination of the library files, specifically the lib and jar files, by third-party solutions. This shift in focus addresses the challenge of identifying Log4Shell in the software that may not be readily apparent through standard software-level scans.
Despite concerted efforts over the past two years to mitigate the risks associated with Log4Shell, significant gaps persist in our defenses. It is incumbent upon software companies to play a pivotal role in enforcing the security-by-design approach.
Firstly, software companies should take proactive steps by implementing specific scripted detections. Using languages such as PowerShell or Python, they can develop detection mechanisms tailored to their own software utilizing the Log4j library.
Secondly, software companies must adopt a compositional analysis approach during vulnerability scanning. This advanced technique enables them to go beyond merely identifying the software itself and its version. It extends to detecting the libraries used by the software, providing a comprehensive view of the potential vulnerabilities. While some virtual machine (VM) software currently possesses this capability, not all solutions are equipped for this level of analysis.
The Future of Library Vulnerabilities
In September of this year, a vulnerability (CVE-2023-4863) emerged in libwebp, a library used for handling WebP bitmap images. Though not identical, it drew comparisons to Log4Shell.
First, similar to Log4j’s role in Java-based applications, libwebp is indispensable for displaying WebP-formatted images. Its widespread use elevates the risk, potentially affecting a vast array of software. Second, both vulnerabilities earned a critical severity rating of 10.0 on the CVSS scale.
Just as Log4j allowed remote code execution, libwebp’s flaw permits maliciously crafted files to breach expected boundaries, leading to unauthorized access, data leaks, and malicious activity.
In both cases, initial assessments underestimated the extent of the vulnerabilities. Libwebp’s impact initially seemed confined to Google Chrome but extended further. Similarly, Log4Shell was initially associated with web services but later revealed its reach across multiple software types. Notably, both vulnerabilities were quickly exploited by threat actors after disclosure.
The parallel between the libwebp incident and Log4j/Log4Shell suggests a potential trend in the proliferation of vulnerabilities in common libraries.
Conclusion: The Path Forward
To rid ourselves of vulnerabilities like Log4Shell in the future, a security-by-design strategy is paramount. Software vendors should regularly update all libraries used in their software. Software consumers must remain vigilant, conducting regular vulnerability scans on internet-facing hosts, fixing vulnerabilities, conducting regular penetration tests, and having a proper Web Application Firewall (WAF) in place.
As we approach the second anniversary of Log4Shell’s discovery, its enduring presence serves as a stark reminder of the ever-evolving cybersecurity landscape. By learning from the lessons it presents, we can better prepare for the challenges of tomorrow and secure our digital environments against the next Log4Shell.
