The recently disclosed Log4j vulnerability (CVE-2021-44228) is one of the most pervasive security vulnerabilities that organizations have had to deal with over the past decade. Log4j is ubiquitous and used by applications and systems deployed across organizations of all sizes. Organizations are struggling to assess the scope and impact of the exposure, given it’s not obvious which applications and systems even use Log4j. Software vendors are actively determining whether their software uses Log4j and are communicating the impact to their customers. Organizations must actively monitor for security patch availability and apply it as quickly as possible. They must deploy mitigations to reduce the exploitability and impact of the vulnerable systems that they cannot patch or don’t yet know about. Unfortunately, fast-moving adversaries will have the advantage in this scenario, and many are already carrying out large-scale efforts to gain footholds in vulnerable target networks.
In the wake of the vulnerability disclosure, financially motivated actors involved in cryptocurrency mining were among the first to exploit targets en masse. We anticipate that additional financially motivated actors will increasingly exploit the vulnerability in operations, leading to various monetization activities. This includes data theft, ransomware deployment, and multifaceted extortion, as these actors are known to incorporate zero-day and one-day exploits into their operations rapidly.
Due to the urgency of identifying and patching vulnerable applications and systems related to this vulnerability, on December 17, 2021, the Cybersecurity and Infrastructure Security Agency (CISA) instituted
Emergency Directive 22-02, which requires that civilian federal agencies must identify and mitigate impacted assets by December 23, 2021, or remove them from agency networks.
As of the publish date of this blog post, we have uncovered evidence of exploitation by China and Iranian state actors. Microsoft has observed exploitation by
threat actors based in other countries. We expect threat actors from additional countries will exploit it shortly, if they haven’t already. In some cases, state sponsored threat actors will work from a list of prioritized targets that existed long before this vulnerability was known. In other cases, they may conduct broad exploitation and then conduct further post-exploitation activities of targets as they are tasked to do so.
This blog post provides an overview of how this vulnerability impacts organizations, shares additional context on how attackers have leveraged it in the wild, and provides mitigation recommendations.
We anticipate this problem will have a very long tail, as adversaries exploit their footholds to carry out major compromises in the coming months.
Background
Log4j 2 is an open source Java logging library developed by the Apache Foundation. It is widely used in many applications and integrated as a dependency in many services. On December 9, 2021, a critical severity unauthenticated remote code execution vulnerability (
CVE-2021-44228 aka “Log4Shell”) impacting multiple versions of the Apache Log4j 2 utility was publicly disclosed. Proof of concept (POC) exploitation tools were immediately available, providing remote code execution capabilities within the context of the user running an application that utilizes the library.
From the CVE-2021-44228 description: “Apache Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 JNDI features used in configuration, log messages, and parameters do not protect against attacker-controlled LDAP and other [Java Naming and Directory Interface] JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.”
The JNDI injection can leverage specific protocols to request a malicious payload from an attacker’s infrastructure - including:
- Lightweight Directory Access Protocol (LDAP)
- Secure LDAP (LDAPS)
- Remote Method Invocation (RMI)
- Domain Name Service (DNS)
As an example, to exploit the vulnerability, an attacker could construct a JDNI insertion and include it within the User-Agent HTTP Header - targeting an application or web server that leverages a vulnerable version of Log4j 2 to download a malicious class file or payload.
On December 14, 2021, an additional Log4j vulnerability was identified (
CVE-2021-45046), based upon the fact that Log4j version 2.15.0 did not fully mitigate the CVE-2021-44228 vulnerability with certain non-default configurations, potentially resulting in a denial-of-service attack.
Mitigation Section
Assess the Scope
Identify
The first step an organization must consider is to determine the scope of applications and dependent services (organization managed and third-party integrated technologies) that leverage the Log4j library. This can be a very challenging and time-consuming process, as the Log4j library could be integrated with many third-party vendor applications and products, in addition to being installed locally on servers and endpoints within an environment.
Example methods which can be potentially leveraged to identify the presence of Log4j:
- Verifying with vendors if the products that are leveraged by the organization are impacted.
- If third-party applications are impacted, understanding the vendor recommended short-term mitigation measures, in addition to the timeframe for when a patch or update path will be available.
- Leveraging internal and external vulnerability scanning tools (ex: Mandiant Attack Surface Management (fka Intrigue), Tenable, Rapid7, Qualys, WhiteSource) which contain signatures or plugins for identifying vulnerable Log4j instances. Additionally, open source vulnerability toolsets can also be leveraged to identify vulnerable Log4j instances, including:
| Scanning should not only be focused for on-premises (external-facing and internal) resources – but also cloud assets and applications that are managed by the organization. |
- Reviewing software asset inventory systems to determine if Java Virtual Machine (JVM) or Log4j libraries are present. Additionally, software asset inventory systems can be leveraged to verify the presence of applications that correlate to vendor notifications of impacted products that rely upon Log4j.
- Leveraging EDR tools to scan for JAR files (ex: log4j-core-2.x.jar), class files (ex: JndiLookup.class), or process execution events associated with Log4j.
- Leveraging tools that can generate a software bill of materials (SBOM) for filesystems and containers (e.g. syft).
Reviewing SIEM logs, endpoint logs, or network traffic to identify
matching patterns of potential exploitation attempts and
correlating any observed instances to specific endpoints or applications for further review.
Contain
Once the scope is identified, the following high-level containment steps should be followed:
- Restrict egress capabilities from applications and servers. This step will essentially prevent the Java service from having the ability to download a malicious class file via LDAP, LDAPS, RMI, or DNS (or potentially other methods), reducing the impact of identified vulnerability exploitation methods.
- Reduce the attack surface of impacted applications and servers by enclaving or limiting access to the application interfaces that could be leveraged for exploitation targeting.
Note: Until all third-party integrated technologies have been confirmed patched by vendors, these are important initial steps to take to reduce the risk of CVE-2021-44228 exploitation.
- Determine if the identified applications and services can have Log4j patched to either version 2.12.2 (Java 7) or 2.16.0 (Java 8).
- For third-party integrated technologies, engage with the application / technology vendors to verify if the platform is impacted—and when security updates will be available.
- Once security updates are available, test and install the updates – prioritizing technologies and applications that are external facing (or have a broad access requirement within the organization).
- If patching is not a viable option, consider the implementation of temporary mitigation measures.
The Cybersecurity and Infrastructure Security Agency (CISA) has collected a list of ‘affected’ and ‘not affected’ third-party vendors vulnerable to the Log4j vulnerability. This list can be found on their
GitHub.
