A high severity vulnerability and proof of concept was released today for a vulnerability in Apache. CVE-2021-44228 (also identified as Log4Shell) is a critically rated vulnerability impacting Log4j 2 (Java log manager) which is integrated into Apache’s web server suite. It impacts Apache Log4j 2 versions 2.0 through 2.14.1
Apache is nearly ubiquitous – thus scope of impact for this specific vulnerability is likely to be quite significant. Multiple frameworks, including but not limited to Apache Struts2, Apache Solr, Apache Druid, and Apache Flink, are likely impacted. Notably, organizations and brands supported by Apache such as Valve, Apple, Tesla, and Twitter among many others are likely to have been impacted though it cannot be said to what extent.
PoC and Exploitation
CVE-2021-44228 is most likely under active exploitation. Several sources report active internet scans searching for the vulnerability within the last 24 to 48 hours. Proof-of-Concept (PoC) for the exploit primitive is available on GitHub.
This specific vulnerability almost certainly allows unauthenticated remote code execution under the privilege context (at the very least) of the Apache daemon, which is likely to be elevated in most cases.
Cyber threat actors of various skill level and motivation are likely to leverage this vulnerability to establish initial access and gain a foothold in the victim environment.
Exploit Working and Remediation
The mechanism of exploitation likely exists in how the Log4j 2 JNDI module parses content of URLs presented (e.g., via POST request – into form fields, URI paths, etc.) to the vulnerable web-server. We see this reflected in both the guidance provided by Apache and Oracle relative to restricting JNDI.
If patching is not possible or delayed for CVE-2021-44228, Apache provides the following workaround guidance for mitigation:
- In previous releases (>=2.10) this behavior can be mitigated by setting system property “log4j2.formatMsgNoLookups” to “true” or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).
- Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against RCE by defaulting “com.sun.jndi.rmi.object.trustURLCodebase” and “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false”.
Fidelis Network
Fidelis threat research has release network detection logic to detect and alert on exploitation attempts – FSS_CVE-2021-44228 – Apache Log4j Inject request. Please refer to the screen capture below:
In addition, emerging threat signatures have been implemented.
Fidelis Endpoint
Fidelis Endpoint policy has been released with a rule to detect possible log4j RCE attempts.
Fidelis CloudPassage Halo customers can run vulnerability scans on their cloud workloads to detect this vulnerability. The screen capture below shows an example detection.
Fidelis Deception customers running decoys in the DMZ or public facing decoys, would automatically receive alerts on adversaries looking for the vulnerability.
Conclusion
As the scope of impact for this vulnerability is likely to be quite significant organizations are urged to patch as soon as possible or implement the workaround.
Fidelis Security is dedicated to helping clients become stronger and more secure. Fidelis is trusted by many top commercial, enterprise, and government agencies worldwide.
*This post was last Updated on 15 December 2021
