The Log4Shell vulnerability critically threatens anybody using the popular open-source Apache Struts framework & could lead to a “Mini internet meltdown soonish.”
A really easily exploited issue in the common Java logging library Apache Log4j could allow unauthenticated remote code execution (RCE) & complete server takeover & it is being exploited in the wild.
Minecraft
The issue 1st appeared on sites that relate to users of the world’s favourite game, Minecraft, on Thurs. The sites reportedly warned that attackers could unleash malicious code on either servers or clients running the Java version of Minecraft by manipulating log messages, including from text typed into chat messages.
The same day, the as-yet-unpatched flaw was named “Log4Shell” by LunaSec & began being tracked as CVE-2021-44228.
By early Fri. morning, the Cyber Emergency Response Team (CERT) of the Deutsche Telekom Group tweeted that it was seeing attacks on its honeypots coming from the Tor network as threat players tried to exploit the new bug,
CERT New Zealand
Also for CERT New Zealand; & all day, people have posted on Twitter to warn that they’re also seeing in-the-wild exploits.
This problem is going to cause a mini-internet meltdown, experts state, given that Log4j is incorporated into loads of popular frameworks, including Apache Struts2, Apache Soler, Apache Druid and Apache Flunk.
That exposes a large number of 3rd-party apps that may also be vulnerable to the same type of high-severity exploits as that spotted in Minecraft, as well as in cloud services such as Steam & Apple iCloud, Lunacek warned.
As of Fri., version 2.15.0 had been released: log4j-core.jar is available on Maven Central here, with release notes are available here & Apache’s Log4j security announcements available here.
‘Mini-Internet Meltdown’ Imminent?
Even though an initial fix was put out on Fri., it is going to take time to come down to all of those projects, given how extensively the logging library is incorporated downstream.
“Expect a mini-internet meltdown soonish,” warned British security specialist Kevin Beaumont, who tweeted that the fix “needs to flow downstream to Apache Struts2, Sor, Linux distributions, vendors, appliances etc.”
US National Security Agency
Just 1 example of the bug’s massive reach: On Fri. morning, Rob Joyce, Director of Cybersecurity at the US National Security Agency (NSA), tweeted that even the NSA’s GHIDRA – a suite of reverse-engineering tools developed by NSA’s Research Directorate – includes the buggy Log4j library.
“The Log4j vulnerability is a significant threat for exploitation due to the widespread inclusion in software frameworks, even NSA’s GHIDRA. This is a case study in why the software bill of material (SBOM) concepts are so important to understand exposure.” — Rob Joyce, NSA Director of Cybersecurity.
Max CVSS Score of 10
The bug find has been credited to Chen Shamoun of Alibaba. It’s been assigned the maximum CVSS score of 10, given how relatively easy it is to exploit, attackers’ ability to seize control of targeted servers & the ubiquity of Log4j. According to CERT Austria, the security hole can be exploited by simply logging a special string.
Researchers told Ars Technica that Log4Shell is a Java deserialization bug that stems from the library making network requests through the Java Naming & Directory Interface (JNDI) to an LDAP server & executing any code that is returned. It is reportedly triggered inside of log messages with use of the ${} syntax.
Returned Code
“JNDI triggers a look-up on a server controlled by the attacker & executes the returned code,” according to CERT Austria’s advisory, posted Fri., which noted that code for an exploit proof-of-concept (PoC) was published on GitHub.
The internet’s reaction: “Umm, yikes.”
“This Log4j (CVE-2021-44228) vulnerability is extremely bad,” tweeted security expert Marcus Hutchins. “Millions of applications use Log4j for logging, & all the attacker needs to do is get the app to log a special string.”
Affected Versions
On Thur., LunaSec explained that affected versions are 2.0 <= Apache log4j <= 2.14.1.
It added that JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector, given that in those versions, “com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load a remote codebase using LDAP.”
Vulnerability also depends on specific configurations. But there are “other attack vectors targeting this vulnerability which can result in RCE,” LunaSec continued.
Existing Code
“Depending on what code is present on the server, an attacker could leverage this existing code to execute a payload,” pointing to a Veracode post on an attack targeting the class org.apache.naming.factory.BeanFactory that’s present on Apache Tomcat servers.
LunaSec concluded that, “given how ubiquitous this library is, the impact of the exploit (full server control), & how easy it is to exploit, the impact of this vulnerability is quite severe.”
Ondiola
Organisations can tell if they are affected by examining log files for services using affected Log4j versions. If they contain user-controlled strings – CERT-NZ uses the example of “Ondiola” – they could be affected.
“If you believe you may be impacted by CVE-2021-44228, Randori encourages all organisations to adopt an assumed breach mentality & review logs for impacted applications for unusual activity,” cyber-security researchers at Randori wrote in a blog post.
Temporary Mitigation
To keep the library from being exploited, it is urgently recommended that Log4j versions are upgraded to log4j-2.15.0-rc1.
For those who can’t update straight off, LunaSec pointed to a discussion on Hacker News regarding a mitigation strategy available in version 2.10.0 and higher of Log4j that was posted in the early hours of Fri. morning.
Mitigation Choices
For versions older than 2.10.0 that cannot be upgraded, these mitigation choices have been suggested:
- Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files (here are Apache’s details); or,
- Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your class loader uses your replacement instead of the vulnerable version of the class. Refer to your application’s or stack’s class-loading documentation to understand this behaviour; or
- Users should switch log4j2.formatMsgNoLookups to true by adding:”‐Dlog4j2.formatMsgNoLookups=True” to the JVM command for starting the application.
