A new vulnerability was discovered in the Apache Log4j library. Tracked as CVE-2021-44832, this bug may allow arbitrary code execution in compromised systems when the attacker has permissions to modify the logging configuration file. CVE-2021-44832 has received a CVSS score of 6.6 out of 10, and it affects all versions of Log4j from 2.0-alpha7 to 2.17.0, excluding 2.3.2 and 2.12.4. This is the fourth Log4j vulnerability addressed by Apache in December 2021.

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.

As previously predicted to unfold, at approximately 7:35 PM GMT, 28th of December 2021, another security vulnerability impacting the Log4j logging library was published as CVE-2021-44832. This new CVE-2021-44832 security vulnerability is affecting versions up to 2.17.0, which was previously thought to be fixed. This vulnerability is similar in nature to CVE-2021-4104 which affected the 1.x branch of Log4j.

The discovery of the Log4Shell vulnerability in the ubiquitous Apache Log4j package is a singular event in terms of both its impact and severity. Over 1 million attack attempts exploiting the Log4Shell vulnerability were detected within days after it was exposed, and it may take years before we see its full impact.

The Log4J library is one of the most widely-used logging libraries for Java code. On the 24th of November 2021, Alibaba’s Cloud Security Team found a vulnerability in the Log4J, also known as log4shell, framework that provides attackers with a simple way to run arbitrary code on any machine that uses a vulnerable version of the Log4J. This vulnerability was publicly disclosed on the 9th of December 2021.

The announcement of Log4j vulnerability cve-2021-44228 sent security and development teams into a tailspin and highlights the one of biggest challenges of open source security: dependency management. The open source libraries that make up up to 80% of our applications are often a tangled web of dependencies.

Note: This post first appeared in r/CrowdStrike. First and foremost: if you’re reading this post, I hope you’re doing well and have been able to achieve some semblance of balance between life and work. It has been, I think we can all agree, a wild December in cybersecurity (again). At this time, it’s very likely that you and your team are in the throes of hunting, assessing and patching implementations of Log4j2 in your environment.