Why Log4j Mitigation Is Fraught With Challenges

Security teams working to mitigate their organizations' exposure to the Log4j vulnerability have plenty of challenges to overcome. They include scoping the full extent of exposure, figuring out workarounds for systems that cannot be patched, and ensuring third-party products and services have been secured.

For many, the task will be further complicated by the need to constantly monitor for signs of attackers attempting to exploit the flaw or indications they might already have been compromised, security experts said this week.

Log4j is a logging tool that is present in nearly all Java applications. A critical remote code execution vulnerability (CVE-2021-44228) exists in versions of Log4j from 2.0-beta9 to 2.14.1 that enables attackers to take full control of vulnerable systems. The Apache Foundation released an updated version of the tool (Apache Log4j 2.15.0) last week, then issued a second update on Tuesday because the original fix did not fully protect against denial-of-service (DoS) attacks and data theft.

The flaw is widely considered to be among the most dangerous in recent memory because it is easy to exploit and is present across virtually every IT environment. Veracode, for instance, found 88% of its customers use some version of Log4j and 58% have a vulnerable version in their environments.

Attackers around the world have been attempting to exploit the flaw from the moment it was first disclosed last week. Numerous vendors have observed attempts to distribute coin miners, ransomware, remote access Trojans, Web shells, and botnet malware. Armis on Wednesday reported some 35% of its customers were under active attack via the vulnerability and 31% had a Log4j-related threat on unmanaged devices. The security vendor said it had observed as many as 30,000 attempted exploits against its customers. Several other vendors have reported similar activity.

Armis found the most targeted assets in IT environments so far have been servers, virtual machines, and mobile devices. In OT networks, 49% of compromised devices have been virtual machines and 43% have been servers. Other targeted devices in OT networks include IP cameras, human machine interface (HMI) devices, and SCADA systems.

Scoping the Problem
One major challenge organizations face in defending against attacks targeting Log4j is figuring out their full exposure to the threat, according to security experts. The vulnerability can be present not just on an organization's Internet-facing assets, but on internal and back-end systems, network switches, SIEM and other logging systems, internally developed and third-party apps, in SaaS and cloud services, and environments they might not even know about. The interdependencies between different applications and components mean even if a component does not directly have the vulnerability, it can still be affected by it.

The way Java packing works can often make it hard to identify affected applications, Noname Security says. As an example, a Java archive (JAR) file might contain all the dependencies — including the Log4j library — of a particular component. But that JAR file might contain another JAR file that, in turn, could contain yet another JAR file — essentially burying the vulnerability several layers deep, the security vendor said.

"One of the main challenges that organizations face in mitigating the vulnerabilities found in Log4j is identifying all compromised assets," says Gustavo Palazolo, threat research engineer at Netskope. The Log4j Apache Java-based logging library is very popular and can be used by many applications, as well as by IoT devices and legacy systems that are maintained for backwards compatibility, he adds. 

Even if an application is found to be vulnerable, updating it might be difficult because an organization may not be able to afford the downtime or lack proper patch management controls.

"Therefore, the time between identifying all compromised systems and fixing the problem can take a long time in some scenarios," Palazolo says.

APIs and Third-Party Risks
Apps are not the only issue. The Log4j vulnerability can affect application programming interface (API) environments as well. API servers that contain the vulnerability offer an attractive attack vector because many organizations have limited visibility over their API inventory and their APIs' behavior, Noname said. A business that doesn't use the Log4j logging framework might be using trusted third-party APIs that contain the Log4j flaw, thereby exposing it to risk.

"For an organization to minimize the risk of [Log4j vulnerability] exploitation via APIs, several steps need to be taken," says Aner Morag, vice president of technology at Noname Security. These include mapping all servers that are serving APIs with any Java service, not allowing any user input to reach a log message on any API server, using a proxy or other mechanism to control which servers back-end services can connect to, and putting APIs behind an API gateway or load balancer, Morag says.

Another challenge organizations face is ensuring all third-party products and services they use are properly patched or have mitigations against the flaw.

"A lot of vendor products are affected, [and] the list of affected vendors is growing on an everyday basis," says Tom Gorup, vice president of security operations at Alert Logic. "Not all vendors may have patches available."

Gorup recommends security teams check their vendors' websites or reach out to them directly to understand if any of their products are affected. A vendor might be vulnerable but have released mitigation steps to protect its customers. 

"At minimum, you’ll want to understand how you can validate your assets have received the update," Gorup notes. He also suggests security teams check lists of vulnerable products that have become available over the past few days, such as this one at GitHub.

"A response to this vulnerability could be, 'We don’t use Java,'" Gorup says. "Where this might be true, your third-party software might have it embedded, which may result in your vulnerability scans not showing up [the threat]."