Attackers are closing in on a critical vulnerability in the popular Log4j Java logging library, with researchers on Friday observing a “sharply increasing” number of exploitation attempts. If exploited, the flaw allows for unauthenticated remote code execution, which can give attackers full control of impacted servers.
Log4j is a tool developed by the Apache Software Foundation that helps programmers output log statements. The Java logging library is incorporated widely into various Apache applications, including Apache Struts, Solr and Druid, widening the flaw's reach to millions of third-party enterprise applications, cloud services and manufacturers, including Apple, Twitter, Steam and Tesla.
The vulnerability (CVE-2021-44228) impacts certain versions of Apache Log4j up to version 2.14.1. The flaw, which was discovered by Chen Zhaojun of the Alibaba Cloud Security team and was first publicly disclosed on Dec. 9, has been fixed in Log4j version 2.15 that was released earlier this week. However, security researchers say that exploitation attempts of the flaw have started to impact servers that remain vulnerable.
“This vulnerability is highly likely to be exploited in the wild and is likely to impact thousands of organizations,” according to researchers with Randori in a security alert. “This vulnerability poses a significant real world risk to affected systems.”
Matt Sicker, member of the Apache Logging Services Project Management Committee, said that the committee was first informed about the flaw in late November.
"I hope that what the security industry has been doing to raise awareness of the severity of this vulnerability does light a fire for software providers.”
The vulnerability was identified publicly after reports emerged of an issue affecting Minecraft, which uses Log4j (Minecraft has since released an update that applies the fixes). The flaw exists because certain Java Naming and Directory Interface (JNDI) features, which are used for Log4j in configuration, log messages and parameters, do not protect against attacker-controlled Lightweight Directory Access Protocol (LDAP) and other JNDI-related endpoints.
Dustin Childs, with Trend Micro’s Zero Day Initiative, said the bug “appears very easy to exploit.” In order to exploit the flaw, an attacker would merely need to send a specially crafted request to an affected server, which would then connect back to an attacker-controlled server, he said. This allows the attacker’s payload to be injected and results in code execution.
“An attacker could use this to get code execution on the target,” said Childs. “Depending on the system, that code execution would likely be with elevated privileges, so they could take over the server.”
According to the Apache Software Foundation, the flaw has been mitigated in version 2.15 by setting system property "log4j2.formatMsgNoLookups" to “true” or by removing the JndiLookup class from the classpath.
“One vector that allowed exposure to this vulnerability was Log4j’s allowance of Lookups to appear in log messages,” according to the Apache Software Foundation. “As of Log4j 2.15.0 this feature is now disabled by default. While an option has been provided to enable Lookups in this fashion, users are strongly discouraged from enabling it.”
Researchers are urging companies to update their systems as soon as possible, due to both the wide level of utilization of Log4j, coupled with the fact that the vulnerability is easy to exploit and has a potential significant impact. However, John Hammond, senior security researcher at Huntress, said that this isn’t an “across the board” solution, as some companies may need to wait until vendors push security updates out for their own products downstream to customers.
“Truthfully, the response time for vendors pushing updated security patches from dependencies varies from provider to provider,” said Hammond. “It is a matter of how quickly their team works, how policies and processes are in place, and how much urgency this has. I hope that what the security industry has been doing to raise awareness of the severity of this vulnerability does light a fire for software providers.”
“It wouldn’t surprise me if we were finding impacted programs months or even years down the line.”
Multiple organizations and security researchers said they have observed increased levels of scanning and exploitation attempts for the flaw. Deutsche Telekom CERT said they have seen widespread attacks of the flaw in their honeypot infrastructure coming from the Tor network, while GreyNoise said it has detected a “sharply increasing” number of hosts attempting to exploit the vulnerability.
Hammond said that these exploitation attempts currently have no obvious target, and attackers are instead taking a spray-and-pray approach “to wreak havoc.” As of Friday afternoon, Huntress is aware of just over 100 malicious IP addresses actively trying to exploit vulnerable Log4j instances across the Internet. While these payloads have thus far been cryptocurrency miners, Hammond said there is potential for these attacks to become any sort of post-exploitation threat.
“Threat actors could use this to deploy remote access trojans (Cobalt Strike beacons or other threats), work to compromise other systems, deploy ransomware, or more,” he said.
Looking ahead, Childs said he is concerned that the impact of this vulnerability will continue in the coming months due to the sheer number of companies impacted. If organizations run a server built on open-source software, there’s a "good chance" they are impacted by this vulnerability, he said.
“Since there isn’t a definitive list of programs impacted by this bug, we’ll likely see this vulnerability for quite a while,” he said. “It wouldn’t surprise me if we were finding impacted programs months or even years down the line.”