The high-profile Log4j security vulnerability known as Log4Shell is attracting attacks at a rate that is astounding even veteran infosec professionals.
Nadir Izrael, chief technology officer for IoT security firm Armis, said that just a few days after its initial disclosure, the bug, designated as CVE-2021-44228, is being subjected to an alarmingly high level of exploit activity.
"Compared to others, this is kind of insane," Izrael told SearchSecurity. "The speed with which it started getting exploited, and the volume and magnitude, is insane."
Izrael estimated that more than a third of Armis' security clients have had internet-facing systems targeted by exploit scripts that seek to use the remote code execution flaw to place malware. Other security vendors and researchers have noted similar patterns, with attackers looking to run anything from cryptomining scripts to remote access and command payloads.
Security researcher Greg Linares noted on Twitter that his most active Log4j honeypot saw a 531% increase in exploitation attempts, or approximately 3,400 attempts per minute, early Wednesday morning. Linares said the majority of payloads observed were information stealers, with some cryptominers and ransomware mixed in.
Nadir IzraelCTO, Armis
A big part of the spread, Izrael said, is a combination of the ubiquity of the vulnerable component (a Java-based logging tool) and the ease with which the bug can be remotely exploited.
Though there have yet to be any major data breaches that were traced back to attacks on the vulnerability, Izrael believes that the first reports are probably going to be landing in a matter of days as attackers are likely already in the process of cataloging and exfiltrating data.
"If anyone is going to do it, they are going to do it now while everything is in disarray," he explained. "Hopefully nothing extreme happens, but realistically speaking this is the time to do something."
So far, the attackers are prioritizing internet-facing servers as targets, but Armis noted that more than a quarter of the attacks it observed were targeting VM instances and an increasing number are looking to exploit the Log4j component in IoT hardware.
That last set of targets could well prove to be the most troublesome for enterprises. While rooting out and patching the flaw is difficult enough on servers, cataloging when Log4j is exposed in embedded devices ranging from industrial operational technology gear to consumer surveillance and webcams is going to be an enormous challenge.
Ultimately, Izrael says, the bug is going to have an enduring "long tail" phase where vendors and enterprises constantly uncover vulnerable devices and struggle to get the word out on firmware updates.
"Most organizations don't even have an idea of what they have, never mind if it is vulnerable," he explained. "A lot of devices will never be patched; the vendor might never even think to release a patch."
Johannes Ullrich, fellow at the SANS Internet Storm Center, said in a blog post Tuesday that the threat of Log4Shell exploitation will require long-term planning in addition to immediate remediation and response efforts.
"Log4Shell will continue to haunt us for years to come," Ullrich wrote. "Dealing with Log4Shell will be a marathon. Treat it as such."
Second Log4j vulnerability revealed
If one Log4j vulnerability wasn't enough to ruin every administrator's week, Tuesday saw the disclosure of a second CVE entry related to the logging tool.
CVE-2021-45046 is an offshoot of the original CVE-2021-44228 Log4Shell vulnerability and addresses an issue that arose on some systems with specific configurations once the 2.15.0 update was installed. According to Mitre, the bug was discovered because "the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations."
Fortunately, CVE-2021-45046 is less of risk than the original Log4Shell flaw, exposing the systems to denial of service attacks rather than the remote code execution that allows for complete takeover. Administrators can protect their systems against both flaws by upgrading Log4j to version 2.16.0.