Description
As if finding one easily exploited and extremely dangerous flaw in the ubiquitous Java logging library Apache Log4j hadn’t already turned the Internet security community on its ear, researchers now have found a new vulnerability in Apache’s patch issued to mitigate it.
Last Thursday security researchers began warning that a vulnerability tracked as CVE-2021-44228 in Apache Log4j was under active attack and had the potential, according to many reports, to break the internet. Dubbed Log4Shell by LunaSec, the flaw resides in the broadly deployed Java logging library and is a remote code execution (RCE) bug that’s simple to exploit in many services and products.
A barrage of attackers immediately set upon Log4Shell, initially to 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. Then attackers began to branch out, spawning 60 or more bigger mutations of the original exploit in one day.
To its credit, Apache hastily released a patch to fix Log4Shell with Log4j version 2.15.0 last Friday. But now researchers have found that this fix “is incomplete in certain non-default configurations” and paves the way for denial of service (DoS) attacks in certain scenarios, according to a security advisory by Apache.org.
The newly discovered flaw, tracked as CVE-2021-45046, could allow attackers with control over Thread Context Map (MDC) input data to craft malicious input data using a Java Naming and Directory Interface (JNDI) Lookup pattern in certain instances, resulting in a DoS attack, according to the advisory.
The set-up for exploit is when the logging configuration uses a non-default Pattern Layout with either a Context Lookup – for example, $${ctx:loginId} – or a Thread Context Map pattern (%X, %mdc, or %MDC), according to the advisory.
“Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default,”
according to Apache.org. “Note that previous mitigations involving
configuration such as to set the system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific vulnerability.”
Fixing the Fix
A new release of Log4j, version 2.16.0, fixes the issue by removing support for message lookup patterns and disabling JNDI functionality by default, according to the advisory. To mitigate the bug in previous Log4j releases, developers can remove the JndiLookup class from the classpath, Apache.org advised.
One security professional noted that it may have been Apache’s haste to release a patch for Log4Shell after the initial panic over its discovery may have inadvertently caused the latest CVE.
“Often rushing patches to fix vulnerabilities means that the fix may not be complete, as the case is here,” observed John Bambenek, principal threat hunter at Netenrich, in an email to Threatpost on Tuesday. He said the solution to the problem is “to disable JNDI functionality entirely.”
Since at least a dozen groups are already known to be exploiting these vulnerabilities, he urged immediate action be taken to either patch, remove JNDI from Log4j or take it out of the classpath – “preferably all of the above,” Bambenek said.
Getting a Handle on the Situation
Researchers and security professionals are still wrapping their heads around the broad and wide-reaching implications of Log4Shell as well as the potential that remains for even more related bugs to be found, another security professional noted.
“When a vulnerability is discovered and makes as much noise as Log4Shell, it invariably signals that there are additional vulnerabilities in the same software or fixes for that software and triggers additional research and discovery,” Casey Ellis, founder and CTO at Bugcrowd, wrote in an email to Threatpost.
Indeed, there already is some confusion about how many vulnerabilities currently exist that are related to Log4Shell and how they all correlate to one another, adding to the avalanche of information being published about the bug, researchers from RiskBased Security wrote in a blog post published Tuesday.
At this point, there are currently three published CVEs associated with Log4Shell – CVE-2021-44228, the original zero-day; CVE-2021-45046, the “incomplete fix”; and CVE-2021-4104, a flaw found in another component of Log4j, JMSAppender, that doesn’t appear to be of great concern, according to the RiskBased Security team.
In the case of CVE-2021-44228, researchers argue that it is not a new problem at all, “but is really the same vulnerability,” according to the post.
“MITRE and CVE Numbering Authorities (CNA) will assign a second CVE ID in cases of fixes not fully patching an issue,” researchers wrote. “This helps some organizations in tracking an issue while introducing confusion to others.”
And despite there being more than one CVE, “places have been treating them as a single issue, but this is definitely not the case,” according to RiskBased Security.
Worse Before It Gets Better
One thing that’s certain about the mounting drama surrounding Log4Shell is that, because the attack surface for the vulnerability is so vast, there is great potential for extensive and further exploitation, according to RiskBased Security.
“It is important to call out that Log4j is a popular logging framework in Java,” researchers wrote in the post. “This means it’s used in an _extraordinary _number of things.”
Indeed, a long list of vendors’ products are vulnerable to Log4Shell, including but not limited to: Broadcom, Cisco, Elasticsearch, F-secure, Fedora, HP, IBM, Microsoft, National Security Agency (NSA), RedHat, SonicWall and VMWare.
Within hours of public disclosure of the flaw, attackers were scanning for vulnerable servers and unleashing attacks to drop coin-miners, Cobalt Strike malware, the new Khonsari ransomware, the Orcus remote access trojan (RAT). reverse bash shells for future attacks, Mirai and other botnets, and backdoors.
Whatever happens going forward, as variations for the original exploit continue to be spawned and attackers continue to swarm, the situation is likely to get worse before it gets better. This means that the dust over Log4Shell probably won’t settle for a very long time.
“This new Log4j vulnerability will likely haunt us for years to come,” according to RiskBased Security.