Log4J ZeroDay BailOut ! With Limitations

A bailout against the Log4Shell vulnerability appears to offer a way to reduce risk from the widespread flaw affecting servers that run Apache Log4j. The script was developed by researchers for the same.

The Log4Shell vulnerability affects Apache Log4j, an open source Java logging library deployed broadly in web servers and the services that run on them. The flaw is considered highly dangerous since it can enable remote code execution (RCE) in which an attacker can remotely access and control devices and is seen as fairly easy to exploit.

An estimated 31.5% of all websites run on Apache servers. The list of companies with vulnerable infrastructure reportedly includes Apple, Amazon, Twitter, and Cloudflare. Vendors including Cisco, VMware, and Red Hat have issued advisories about potentially vulnerable products.

The vulnerability has impacted version 2.0 through version 2.14.1 of Apache Log4j, and organizations are advised to update to version 2.15.0 as quickly as possible.

Patching can be a time-consuming process. To supplement patching efforts, The tool called “Logout4Shell”has the potential to “immunize” vulnerable servers, providing protection against attacker exploits that target the flaw.

The Logout4Shell essentially buys some time for security teams as they work to roll out patches. The fix disables the vulnerability and allows organizations to stay protected while they update their servers.

With the Logout4Shell tool, security teams can “take a server that you suspect is vulnerable, and feed the string into places that you think are potentially vulnerable. If your application is not vulnerable at all, nothing happens,”

If server is vulnerable to this attack, the exploit will get triggered, which will download the code that we supply, and what that source code does is go into the configuration and disable the vulnerable components. So the server continues running, none the wiser but any future attempt to exploit this vulnerability now won’t do anything.

There are some limitations for the bailout tool.The mitigation does not work prior to version 2.10 of Log4j. The exploit also must fire properly in order to be effective, and even when it does run properly, it still leaves the vulnerable code in place.

Many organizations are currently struggling to inventory where Log4j exists in their environment, and updating a component like this necessitates a dependency analysis in order to avoid breaking a system in the pursuit of fixing a vulnerability.

All of this adds up to a lot of work. And having a ‘fire and forget’ tool to clean up anything that may have been missed at the end of it all seems like a scenario that many organizations will find themselves in, in the coming weeks.