On Thursday, December 9, a critical vulnerability in Log4j, a widely used logging framework for enterprise java applications was identified and has tech industries around the world scrambling to address the issue as soon as they possibly can.
This blog discusses the vulnerability, its impact, and what enterprises must do to defend against it.
What Is Log4j?
Log4j is a project of the Apache Software Foundation that was initially released over 20 years ago. It is an open-source logging framework written in java that is used by millions of applications worldwide. Version 2.0 of Log4j was introduced as a successor to the initial version of Log4j in 2014. Log4j 2.0 was a complete rewrite of the logging framework and delivered significant performance improvements over the previous version.
What’s the Issue With Log4j and How Bad Is It?
The exploitation of this vulnerability is relatively easy and has been well documented on the internet since the initial announcement on December 9th. Attackers across the globe including from Russia, China, North Korea, and Iran have already been observed actively exploiting this vulnerability.
This vulnerability has also been exploited to deploy ransomware in attacks similar to the high-profile attacks on Colonial Pipeline and JBS Foods earlier in the year.
In addition to any in-house developed applications that use Log4j, this vulnerability impacted many cloud-based services including Salesforce, AWS, Microsoft, IBM, VMWare, Oracle, Cisco, and ServiceSoft—just to name a few.
Call To Action
Given the widespread use of Log4j, it’s highly likely that every enterprise is affected in one way or another. Certainly, the prudent thing to do is assume you’ve been impacted and take actions to mitigate the threat.
If you’re running in-house developed applications that are using Log4j, you should immediately upgrade your Log4j package to the latest available version (2.17.0 as of this blog post).
An initial patch for this vulnerability was rolled out as version 2.15.0, however this didn’t completely resolve the issue, so a follow-on patch was released (12.16.0) that finally addressed the underlying issue. One additional DDOS vulnerability was identified that caused the generation of 2.17.0.
One good source of actionable information on this vulnerability is the CERT vulnerability notes database, run by Carnegie Mellon University. It has a vulnerability note on this issue that includes a list of over 1,600 on-prem and cloud-based applications with information on whether they’re impacted. It additionally provides a set of downloadable tools that can be used to scan your systems to identify whether you’re vulnerable.
Bottom Line
Enterprises need to take this vulnerability very seriously and should assume by default that they’re exposed. The sheer number of systems impacted by this vulnerability and the fact that the details of the exploit were released to the public at almost the same time as the technology providers have combined to make this one of the most serious cybersecurity exposures in recent history.