The December 9th Log4j Vulnerability
January 2022
What Happened?
On December 9th, a zero-day critical vulnerability caused by a remote code execution flaw in Log4j was discovered (CVE-2021-44228). The library is developed by Apache Software Foundation and is a key Java-logging framework, so Kotlin, Java, ColdFusion systems are at high risk.
Log4J is an incredibly widely used Java library for logging error messages in web apps. It is used in both enterprise and custom software applications and forms part of many cloud computing services.
Several national cybersecurity agencies, including the UK’s National Cyber Security Centre (NCSC) and the Cybersecurity and Infrastructure Security Agency (CISA) have sent out warnings about this situation.
How Do You Know If Your System is Affected by the Log4j Exploit?
A huge part of the challenge will be figuring out which software systems are harboring the Log4j vulnerability. The Netherland’s Nationaal Cyber Security Centrum (NCSC) published a comprehensive A-Z list on GitHub of all affected products and their vulnerability status:
Vulnerable – Software is vulnerable for CVE-2021-44228.
Fix – Software contains a fix for CVE-2021-44228
Workaround – Software is vulnerable but mitigation steps are available
Not vuln – Software is NOT vulnerable for CVE-2021-44228
Investigation – Software is under investigation whether it is vulnerable or not
This list truly shows just how widespread the vulnerability is – spanning cloud, developer, security, mapping services, and more. Well-known vendors like Microsoft Azure and Atlassian are still vulnerable.
So, What Should You Do?
Update Systems Running Log4j to 2.16.0 ASAP
CISA’s main advice is to identify and upgrade all devices running Log4j to the latest version (2.16.0). If that cannot be done, they advise to apply the mitigations provided by vendors “immediately.” They also recommend setting up alerts for attacks on devices running Log4j.
NCSC also recommends updating to version 2.15.0 or later, and where that isn’t possible, to do the following:
“Where a vendor has not provided an update to a product, the vulnerability can be mitigated in previous releases of Log4j (2.10 and later) by setting system property “log4j2.formatMsgNoLookups” to “true”. The JndiLookup class can also be removed from the classpath.”
In response, AWS updated its WAF rule set – AWSManagedRulesKnownBadInputsRuleSet AMR – to detect and troubleshoot Log4j attack attempts and scanning. It also has mitigation options that can be enabled for CloudFront, Application Load Balancer (ALB), API Gateway, and AppSync. It’s also currently updating all Amazon OpenSearch Service to the patched version of Log4j.
We always encourage the use of best security practices. Staying up to date on possible exploits involving your system is a crucial one! For more information on this exploit, some security bulletins from CVE:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046