Serious Log4j Security Flaw: Race Underway to Discern ScopeExpert Recommends Egress Filtering as 'Primary Containment Strategy, Long Term'
For many security teams, it's been all hands on deck since the Apache Log4j zero day vulnerability recently came to light. Experts say the flaw may be the most serious security vulnerability to have emerged in years.
See Also: A Guide to Passwordless Anywhere
The vulnerability, CVE-2021-44228, is part of the open-source Log4j 2 software library. The component, which is used to log events, is part of tens of thousands of deployed applications and cloud-based services.
Because of that ubiquity, the security threat posed by the bug is "about as serious as it gets," says Sam Curry, chief security officer at Cybereason.
Organizations are now racing to try and identify what risk and exposure they face, says Charles Carmakal, senior vice president and CTO of incident response firm Mandiant. Carmakal described the last two days as a "tough weekend."
"Most organizations don't know what the scope of the impacted systems actually is because Log4j is embedded in so many different applications and maybe even black box systems that organizations have in their network," Carmakal says. "So it's likely going to take weeks or months for organizations to really get a good handle on all the different applications and systems that use this."
Carmakal says some organizations have already moved to incident response due to attacks, which are easy to launch. The vulnerability can be exploited remotely by a single line of code. And because Java is cross-platform, it means it's exploitable on Windows and Linux OSes running vulnerable software.
Because logging components such as Log4j ingest nonsanitized and untrusted data by design, analysts are still figuring out how many different ways the vulnerability could be exploited. An exploit could be lurking in anything that Log4j 2 parses: an email, a user-agent string and much more.
"I've seen someone exploiting this using a Wi-Fi SSID," says Casey Ellis, CTO and founder of BugCrowd.
Ellis thinks there's a looming negative potential for the bug. "The idea of this ending up in a self-propagating piece of malware or ransomware or whatever else - that's to me a question more of when - not if - it will happen," he says.
Log4j 2: The Long Tail of Exploitation
The Apache Software Foundation has released a patch for the vulnerability, and organizations should apply that if possible. But that's just a part of the problem. Many organizations may not even know if they're vulnerable, as Log4j 2 can be embedded deep in applications that users will not themselves have developed.
Hence organizations are still wrapping their heads around the impact of the Log4j 2, which may be difficult to figure out in complex, legacy environments, Ellis says. Although a patch has been released, just applying the patch may not be straightforward.
Ellis says Java overall is powerful but can also be fragile, in that it's often comprised of many different interdependencies hooked together. So even if an organization finds where it has Log4j 2, undertaking regression testing and ensuring the patch doesn't break anything else will take time, he says.
"The long tail on this [vulnerability] is going to be quite, quite extraordinary over time," Ellis says.
In addition to finding where Log4j 2 is in their own software, organizations will be waiting for vendors to patch any vulnerable software they use. But time is short to mitigate and patch. Experts are already seeing the vulnerability exploited to install botnet code on IoT devices and cryptocurrency mining software.
Carmakal says Mandiant has seen mass scanning attempts that aim to deploy coin miners or malware for building botnets, among other concerning events. "We believe we are seeing some advanced activity, like state-sponsored activity, but it's hard to tell because we're still early on," he says.
How to Mitigate
If patching isn't possible at the moment, there are some mitigations. Also, web application firewalls - aka WAFs - are adding detections, although experts say WAFs won't be a foolproof way to defend against all attempts by attackers to target Log4j 2.
Ellis says organizations can disable JNDI (Java Naming and Directory Interface) lookups in Log4j 2. Here's the reason: An exploit can occur when Log4j 2 logs a malicious string and then executes.
That string can call on a remote server and pull down code, thus giving the attacker access to the system. Disabling the lookup function means the vulnerability will still be present, but it won't call on the malicious host, Ellis says.
Organizations should also implement outbound egress filtering and allow listing, Carmakal says.
"We recommend, where and when possible, leveraging outbound allow listing in order for a system to be able to connect out to the internet and where feasible, attempt to do that for recursive DNS as well," Carmakal says.
Inbound allow listing is common, but not many organizations do outbound allow listing because it's difficult to set up, Carmakal says. Newly created servers, for example, make many outbound connections, he said. But setting it up could potentially stop attackers from exfiltrating data.
Ellis says egress filtering may "end up being the primary containment strategy, long term."
There are also WAFs. WAF vendors write signatures that can detect strings that look like attacks or defend against known ones. But often those signatures are generic, says William Coulter, a senior security consultant with Alchemy Security Consulting in Adelaide, Australia.
Threat actors often have access to firewalls for testing and manually experiment with exploits that can evade WAFs, he says. Also, even if WAFs catch attacks, the bug still may be useful for privilege escalation once inside systems, Coulter says.
"I think it's going be a great privilege escalation technique or even for persistence," says Coulter, who is a penetration tester. "If you can find Log4j 2 or an Apache box floating around, you can just hit it up."