Update 15th Dec 2021: As the current situation is evolving security researchers noted that the presented quick fixes to mitigate the current log4j security vulnerability can also be circumvented. The only working permanent solution is to upgrade to the latest version of 2.16 so far.
Whats going on at the moment?
The current log4j 0day security vulnerability (CVE-2021-44228) caused a massive disruption within the IT sector over this weekend. Attacks in the wild have already been documented making use of the vulnerability. Companies are assessing the current state finding out if they are affected and how to mitigate the situation. The impact is huge, and it is not yet clear how far this can go. It is believed that mostly IT service providers are affected and not so many consumers. Though IoT Devices in private hands are also at risk exposing this critical vulnerability if using Java in combination with the log4j library. Greatest threat would be a massive increase of ransomware attacks made possible by this security flaw which can be devastating to unprepared IT infrastructure as recent attacks launched at Saturn and Media Markt have shown. First attacks are already detected where systems got compromised by Cobalt Strike Beacons. The security software can maliciously be used as an entry point to further penetrate a victims’ network.
Image source: https://logging.apache.org/log4j/2.x/images/logo.png
Is your infrastructure affected?
First thing should be to find out if your IT infrastructure and its applications are affected. Since the library is often packaged within Java archives (JAR-Files) or other archive types it is difficult to spot the usage of the library right away. The open-source tool log4-detector can help detect vulnerable libraries used within any Java applications.
Image source: https://imgs.xkcd.com/comics/dependency.png
First line of defense
Filtering and blocking known bad IPs is one way discussed as another first line of defense. It is important to know that filtering may not be as effective since there exist countless ways to obfuscate malicious request that it is impossible to block every potentially bad request by a regex, as well as over blocking may lock out potential customers and may therefor create collateral damage by lost business.
AWS provides some updated WAF rulesets that may help as a quick way to mitigate attacks. It is important to upgrade all systems that use vulnerable versions on log4j to at least version 2.15. Version 1.2.x is not affected. The affected versions are 2.0-beta9 to 2.14.1. Contact your vendors. They may provide updated versions or at least can give you the information that they are not affected.
Versions of log4j 2.10 and greater support the deactivation of message look ups. You can start your JVM with the option “-Dlog4j2.formatMsgNoLookups=True” or by setting the environment variable “LOG4J_FORMAT_MSG_NO_LOOKUPS=true”. Older versions can mitigate by removing the class JndiLookup: “zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.”
For applications that are critical and cannot be redeployed easily, there is a way to apply a hot patch for Apache log4j. The patch does not require a restart and it tries to overwrite the lookup method of all org.apache.logging.log4j.core.lookup.JndiLookup instances. Alternatively, it can also be statically applied and included if you are able to redeploy the application.
While it remains uncertain if your IT infrastructure is safe from this vulnerability, measures like segmentation, access restrictions, disallowing outgoing traffic and restricting executable programs may help reduce the blast radius if something goes wrong.
Cloud service providers are also affected by this issue. AWS for instance has provided a list of all affected services and measures customers should take to protect against this vulnerability (click for the first update and here for the second).
If you need assistance assessing your situation or mitigating impacts for your IT infrastructure do not hesitate to contact us.