We have detected a critical security vulnerability in a Java logging library widely used in very extended open source projects like Jenkins, ElasticSearch or Apache Solr. This vulnerability, with CVE CVE-2021-44228, implies a level 9 risk in the CVSS vulnerability grading scale in terms of ease of exploiting and reach, which classifies it as a critical vulnerability. This allows the attacker to, in a trivial way and without the need of authentication, to remotely execute code in an application that uses this library to generate internal log entries.
There is the possibility to disable the function that allows this vulnerability to be exploted (JNDI) with environment variables in some versions of the library, but the long-term solution is to patch the log4j library to version 2.17.0.
Reach
This vulnerability has a very wide reach into several applications widely used in the technology stack of modern companies. A complete list of currently known affected software can be seen on CISA‘s github repository about the issue. This list will be updated as new software is discovered to be vulnerable.
Threat hunting and mitigation
It is possible to mitigate this vulnerability by disabling the JNDI lookup library that makes this attack possible with environrment variables, or deleting the java library entirely from the included functions inside the jar file which will make this impossible to exploit. These, however, are temporary patches, and the definitive solution to include on your roadmap is to update to log4j 2.17.0 as soon as possible.
You can investigate common post-exploitation trails and vulnerable log4j library entries with our in-house scanning tool script that has been developed to log detections of common post-exploitation trails in your scanned system, and to scan for any log4j libraries that exist on your filesystem and are vulnerable to this CVE’s.
Update 1: 2021-12-14
It has been discovered that Apache’s fix for this CVE in log4j 2.16.0 was incomplete in some non-default configurations and it still allowed to remotely execute code in some configurations. It is recommended to upgrade to log4j 2.17.0 as soon as possible to avoid being affected by this vulnerability.