The Log4Shell critical vulnerability that impacted millions of enterprise applications remains a common cause for security breaches a year after it received patches and widespread attention and is expected to remain a popular target for some time to come. Its long-lasting impact highlights the major risks posed by flaws in transitive software dependencies and the need for enterprises to urgently adopt software composition analysis and secure supply chain management practices
Log4Shell, officially tracked as CVE-2021-44228, was discovered in December 2021 in Log4j, a widely popular open-source Java library that’s used for logging. Initially disclosed as a zero-day, the project’s developers quickly created a patch, but getting that patch widely adopted and deployed proved challenging because it relies on developers who used this component in their software to release their own updates.
The issue was further complicated by the transitive nature of the vulnerability because software projects that incorporated Log4j included many other third-party components or development frameworks that themselves were used as dependencies for other applications. Use of the Log4j library itself was not even needed to be affected, as the vulnerable Java class called JndiManager included in Log4j-core was borrowed by 783 other projects and is now found in over 19,000 software components.
Log4j exploitation “will remain a challenge”
“We assess that the threat of Log4j exploitation attempts will remain a challenge for organizations well into 2023 and beyond,” researchers from Cisco’s Talos group said in their end-of-year report. “Log4j’s pervasiveness in organizations’ environments makes patching challenging. Since the library is so widely used, Log4j may be deeply embedded within large systems, making it difficult to inventory where all software vulnerabilities may be in a particular environment.”
According to data from vulnerability scanning specialist firm Tenable, 72% of organizations still had assets vulnerable to Log4Shell as of Oct. 1, 2022, a 14-point improvement since May but still a very high percentage. The average number of vulnerable assets per organization decreased from 10% in December 2021 to 2.5% in October, but Tenable observed one in three assets having a Log4Shell recurrence after initially achieving remediation.
“What our data shows is companies that have mature open-source programs have largely remediated, while others are still floundering a year later,” Brian Fox, CTO of software supply chain management firm Sonatype, tells CSO. “The number of vulnerable Log4j downloads every day is in the hundreds of thousands which, in my opinion, shows that this isn’t an open-source maintainer problem but an open-source consumer problem. This is proof that companies simply don’t know what is in their software supply chain.”
Sonatype maintains and runs the Maven Central Repository, the largest and most widely used repository of Java components. The company is therefore able to track the number of downloads for any component, such as Log4,j and maintains a page with statistics and resources for Log4Shell. Since December 10, one in three Log4j downloads have been for vulnerable versions.
Number of Log4Shell exploitation attempts remain high
Following the flaw’s public disclosure in late 2021, telemetry from the Snort open-source network intrusion detection system showed a spike in the number of detections for Log4Shell exploitation attempts that reached nearly 70 million in January. The volume of new detections decreased until April but have remained relatively constant since then at around 50 million per month. This shows that attackers continue to have an interest in probing systems for this vulnerability.
Managed detection and response firm Arctic Wolf has seen 63,313 unique incidents of attempted exploitation since the end of January against 1,025 organizations that represent around a quarter of its customer base. Around 11% of incident response engagements by Arctic Wolf at organizations who were not previously its customers had Log4Shell as the cause for intrusion. This was topped only by the ProxyShell (CVE-2021-34473) vulnerability in Microsoft Exchange.
The exploitation of vulnerabilities in publicly facing applications, which included Log4Shell, was tied with phishing for the position of top infection vector during the first half of the year, according to data from Cisco Talos’s incident response team. In Q3, application exploits were the third most common infection vector and included the targeting of VMware Horizon servers vulnerable to Log4Shell.
The types of attackers who exploit Log4Shell vary from cybercriminals deploying cryptocurrency miners and ransomware to state-sponsored cyberespionage groups. Around 60% of the incident response cases investigated by Arctic Wolf this year were attributed to three ransomware groups: LockBit, Conti, and BlackCat (Alphv). The average cost of such an incident is estimated by the company at over $90,000.
According to Cisco Talos, the now defunct Conti ransomware group started exploiting Log4Shell shortly after the flaw was made public in December 2021. However, exploitation of this flaw by ransomware groups continued throughout the year. Cryptocurrency mining gangs were even quicker to adopt Log4Shell than ransomware groups, being responsible for many of the early scanning and exploitation activity associated with this flaw.
However, throughout the year Cisco Talos has seen Log4Shell being leveraged in cyberespionage operations by APT groups as well, including North Korea’s Lazarus Group, threat actors associated with Iran’s Islamic Revolutionary Guard Corps, and the China-linked Deep Panda and APT41 groups.
“Log4j is still a highly viable infection vector for actors to exploit, and we expect that adversaries will attempt to continue to abuse vulnerable systems as long as possible,” the Cisco Talos researchers said. “Although threat actors remain adaptable, there is little reason for them to spend more resources developing new methods if they can still successfully exploit known vulnerabilities.”
Copyright © 2022 IDG Communications, Inc.
