Adam has over 12 years of collective intelligence experience – with 8 years in Cyber Threat Intelligence (CTI) distributed across various disciplines which include: incident response, malware analysis, vulnerability/exploit research, offensive security assessments, and cyber-HUMINT collection.
Prior to ... Read More
December 11, 2021
Safeguarding Your Assets Against Apache Log4j Vulnerability
Updated on 15 December 2021
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 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 policy has been released with a rule to detect possible log4j RCE attempts.
Figure 2. Custom endpoint detection logic to detect and alert on exploitation attempts. Process: Possible CVE-2021-44228 – Apache log4j RCE Attempt
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.
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.
See Fidelis platforms in action. Learn how our fast, scalable Fidelis Elevate and Fidelis CloudPassage Halo platforms provide deep insights into the SOC to help security teams worldwide protect, detect, respond, and neutralize even the most advanced cyber adversaries.