A high severity 0-day exploit was discovered on December 9, 2021, in the Java logging library, log4j 2 (version 2). The log4j 2 vulnerability was dubbed Log4Shell, and experts warn that its exploitation is very easy.
Our internal investigation did not identify vulnerable components within the Heficed infrastructure, but we advise all clients who use potentially vulnerable components on their services running on the Heficed infrastructure to patch them immediately or apply mitigative actions.
You can find more information about the vulnerability and mitigation below.
log4j 2 vulnerability
The remote code execution (RCE) vulnerability in Apache log4j 2 is actively exploited in the wild. Public proof of concept (POC) code was released, and further testing revealed that exploitation is trivial to perform and supports multiple attack vectors.
An attacker can submit a special request to a vulnerable system and, depending on how the system is configured, instruct it to download and execute a malicious payload. Attack vectors vary based on the actual application generating log entry.
Like many RCE exploits, Log4Shell triggered massive scanning activity for CVE-2021-44228 on the internet with the intent of seeking out and exploiting unpatched systems. Due to the recent discovery of this exploit, you might not have patched the vulnerable components yet.
We highly recommend that you upgrade to the latest version (2.15.0) of Apache log4j 2 for all systems you manage and maintain. If the upgrade option is not viable in a short frame, please use a workaround to mitigate the issue until the upgrade is available.
Affected Version
Apache Log4j 2.x <= 2.15.0
Affected Software
Many Java-based applications use log4j as their logging utility. They are all vulnerable to this CVE. Here are a few examples (incomplete list):
According to HackerNews, the formatMsgNoLookups property was added in version 2.10.0, per JIRA Issue LOG4J2-2109. Therefore, the formatMsgNoLookups=true mitigation strategy is available in version 2.10.0 and higher but is no longer necessary with version 2.15.0 because it becomes the default behavior.
If you are using a version older than 2.10.0 and cannot upgrade, you have 2 mitigation choices:
Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files. You can find more details about this here. The fix only works on versions >= 2.7.
Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application’s or stack’s classloading documentation to understand this behavior.
Further reading on details and mechanisms of the exploitation is available at:
