Apache Log4j unauthenticated remote code execution

Apache Log4j unauthenticated remote code execution

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.

Figure 2. Custom endpoint detection logic to detect and alert on exploitation attemptsProcess: Possible CVE-2021-44228 – Apache log4j RCE Attempt

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 Cybersecurity is dedicated to helping clients become stronger and more secure. Fidelis is trusted by many top commercial, enterprise, and government agencies worldwide. For more information, please Contact – Fidelis Cybersecurity (fidelissecurity.com).