Log4j Patching A Real World Challenge

Security teams around the world working tirelessly 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.

The task will become 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.

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. 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.

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.

One major challenge organizations face in defending against attacks targeting Log4j is figuring out their full exposure to the threat.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 dependencies between different applications and components mean even if a component does not directly have the vulnerability, it can still be affected by it.

Issue Scoping

The way Java packing works can often make it hard to identify affected applications,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.

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.The time between identifying all compromised systems and fixing the problem can take a long time in some scenarios.

APIs and Third-Party Risks

Apps are not the only issue.Log4j vulnerability can affect application programming interface too. 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. 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

Another challenge organizations face is ensuring all third-party products and services they use are properly patched or have mitigations against the flaw. 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.