Original Fix for Log4j Flaw Fails to Fully Protect Against DoS Attacks, Data Theft
Security experts are now urging organizations to quickly update to a new version of the Log4j logging framework that the Apache Foundation released Tuesday because its original fix for a critical remote-code execution flaw in the logging tool does not adequately protect against attacks in some situations.
According to the Apache Foundation, the Apache Log4j 2.15.0 version that it released last week to address the Log4j flaw (CVE-2021-44228) is “incomplete in certain non-default configurations” and gives threat actors a way to trigger a denial-of-service (DoS) attack on vulnerable systems.
“Note that previous mitigations involving configuration such as setting the system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific vulnerability,” the Apache Foundation said.
The foundation assigned a new vulnerability identifier (CVE 2021-45046) for the issue and pushed out a fresh version (Apache Log4j 2.16.0) of the tool that it said addresses the DoS issue.
Meanwhile, security vendor Praetorian, among the first to exploit the Log4j flaw last Friday, today said the Log4j 2.15.0 version from last week was vulnerable to another issue as well: exfiltration of data under certain conditions.
Praetorian did not share the technical details of the research and said that the company had passed on its finding to the Apache Foundation.
“In the interim, we strongly recommend that customers upgrade to 2.16.0 as quickly as possible,” said Praetorian CEO Nathan Sportsman in a blog posted this afternoon.
Anthony Weems, principal researcher at Praetorian, says the Apache Foundation’s description about the Log4j 2.15.0 version restricting JNDI LDAP lookups to localhost by default is incorrect.
“We have a bypass for this localhost restriction that means that when a host is affected by CVE-2021-45046, you can exfiltrate [environment variables] via DNS,” Weems says.
The new developments mean that organizations that already downloaded Log4j 2.15.0 to address the original flaw (CVE-2021-44228) now will need to implement version 2.16.0 to mitigate the DoS issue tied to CVE-2021-4506.
“If someone owned a network or application and found the need to patch Log4j to 2.15, they will need to update to 2.16 now,” says Vikram Thakur, technical director at Symantec, a division of Broadcom Software.
Security experts have described the flaw in Log4j as one of the worst ever in recent memory because of its broad scope and ease of exploitability. Almost all Java applications use the logging tool, meaning that the vulnerability is present almost everywhere a Java app is used.
“It is frequently included as a default log handler in enterprise Java applications and is commonly included as a dependency component in other Java projects (including in over 470,000 other open source projects),” ShadowServer said this week. The logging tool is present in almost all software-as-a-service and cloud-service provider environments, as well as in both Internet-facing and internal systems.
An analysis by Sonatype earlier this week showed more than 28.6 million downloads of Log4j in the past four months.
Growing Attack Activity
Attackers — including a growing number of advanced persistent threat groups from Iran, North Korea, and Turkey — have predictably been attempting to exploit the flaw right from the moment it was first disclosed. Microsoft on Tuesday said its researchers had observed Iranian threat actor Phosphorous acquiring an exploit for Log4j and making modifications to it presumably in preparation for attacks targeting the flaw. Hafnium, the China-based group behind numerous zero-day attacks on the ProxyLogon set of flaws in Exchange Server, has begun using the Log4j to target virtualization infrastructure, Microsoft said.
Others have described threat actors targeting the flaw to try and distribute cryptocurrency coin miners, remote access Trojans, ransomware, and web shells for future exploitation.
Edge cloud services provider Fastly, which has been tracking the threat, on Wednesday said it had observed attackers targeting the flaw on a huge scale. Many have begun figuring out ways to try and evade mitigations for the flaw. As an example, Fastly pointed to attackers using nested statements to make it harder for defenders to create simple rules for detecting an attack. There has also been a growing number of attacks where threat actors attempt to extract data, such as AWS access keys, AWS session tokens, and OS version details. In fact, 35% of the attacks that Fastly observed involved attempts to steal data.
“The nested templates used in Log4j attacks allow for attackers to both obfuscate the strings included as well as try to steal information,” says Mike Benjamin, vice president of security research at Fastly.
The obfuscation makes it more difficult for defenders to block or alert without false positives, he says.
“For the theft of information, defenders need to be mindful of any environment variables or other information available to the Java runtime that could be stolen by an attacker,” Benjamin explains.
Fastly also found that 91% of unique callbacks — or responses from vulnerable machines to attacker scans — pointed back to four sites that are largely associated with well-known security tools sometimes used for legitimate purposes, such as pen testing.
“Penetration testers and bug-bounty researchers often make use of these tools to make out-of-band callbacks,” Benjamin says. “They become an easy place to deliver payloads and test against potentially vulnerable services.”
Read More HERE