CVE-2021-44228 (AKA Log4J) was released in December 2021, and remains one of the most exploited vulnerabilities still 2 years later! How can this be?
What is it?
Log4J is part of the Apache Foundations Logging Services Project. This was initially included in the application from October 1999 but wasn’t really adopted until the Logging Services Project general release in January 2001. The current release is the Log4J 2 branch, which was generally released in July 2014.
For a complete overview of the vulnerability and its history, please take time to read here: Log4j explained: Everything you need to know (techtarget.com). The short version is that the vulnerability enabled an attacker to launch an RCE (Remote Code Execution) on vulnerable systems. So pretty serious!
Why is this STILL a problem?
There are many reasons for this. For example, 2 years after the vulnerability became public, up to 40% of Log4J downloads were STILL vulnerable according to researchers in February 2023! (40% of Log4j Downloads Still Vulnerable (securityintelligence.com)). The problem is that this vulnerability has been embedded in so many applications, that may or may not being getting updates. And we can see the repercussions of this. In Verizon’s always good to read report on Data breach investigations, they found that up to 8% of organizations still had vulnerable Log4j in their systems. And that 22% of those organisations had more than one instance of this. – 2023 Data Breach Investigations Report | Verizon.
The USA Homeland Security “Cyber Safety Review Board” report of July 2022 stated “The Board predicts that, given the ubiquity of Log4j, vulnerable versions will remain in systems for the next decade, and we will see exploitation evolve to effectively take advantage of the weaknesses” (CSRB Report on Log4j – Public Report – July 11 2022_508 Compliant (cisa.gov)).
So what we have is a Vulnerability that is in a LOT of software, that the operators of may or may not know they have, and on top of that, may or may not have a means to patch it. In many ways it is the “Perfect Storm” for a vulnerability- Remote access, unknown where it is, and not patchable in a lot of instances.
What to do?
Patch where possible is the easy answer. But it is precisely this type of problem we had in mind at Innoculator when coming up with our solution. What is needed is a way to stop attackers from exploiting what is a major vulnerability. With Innoculator you are able to stop or alert on ANY attempts to call Log4J, giving you peace of mind that you are across this threat vector.
