It is freely available on GitHub and Cybereason said it “is a relatively simple fix that requires only basic Java skills to implement.”
“In short, the fix uses the vulnerability itself to set the flag that turns it off. Because the vulnerability is so easy to exploit and so ubiquitous—it’s one of the very few ways to close it in certain scenarios,” said Yonatan Striem-Amit, CTO of Cybereason.
“You can permanently close the vulnerability by causing the server to save a configuration file, but that is a more difficult proposition. The simplest solution is to set up a server that will download and then run a class that changes the server’s configuration to not load things anymore.”
The “vaccine” garnered a mixed response from experts, some of whom praised the company for stepping up while others said it wasn’t nearly enough to protect those affected by the vulnerability.
Dr. Richard Ford, CTO of Praetorian, said the Log4j vulnerability can be subtle, and while it is sometimes revealed with simple scanning, it is also frequently found buried deep in customer infrastructure, where it can be trickier to trigger.
“For this reason, I am concerned that some of the well-meaning responses I’ve seen from the industry can cause longer-term problems. In the case of Logout4Shell, it’s not always as trivial to exploit as entering a simple string into ‘a vulnerable field.’ Knowing which field is vulnerable can be tricky, and with many folks now filtering traffic en route knowing your string even reached the server intact is not trivial,” Ford explained.
“If we inadvertently give a customer the impression that just popping ${$jnfi… into a string is good enough, folks could end up with a false sense of security. In addition, generically patching a server could have unpleasant unintended consequences, and it’s up to customers to figure out what risks they can tolerate in a production system. Cybereason’s tool is an interesting approach, but would not recommend a customer solely rely on it.”
Randori’s Aaron Portnoy said hot patching solutions such as this can be effective stop-gap mitigations, but this solution will only be effective for the lifetime of the Java Virtual Machine.
“If the application or the system restart, the ‘vaccine’ would need to be re-applied. The best remediation is to upgrade the log4j2 library and apply default-deny firewall rules on outbound traffic for systems that may be susceptible,” Portnoy said.
Bugcrowd CTO Casey Ellis noted that to run this without permission on someone else’s infrastructure “is almost certainly in violation of anti-hacking laws like the CFAA, which creates legal risk regardless of whether the intent is benevolent or malicious.”
“While folks may be well-intentioned, it’s important for them to understand the legal risk it creates for them. It’s a similar technique to what the FBI and DOJ did earlier in the year to mitigate HAFNIUM web shells on Exchange servers, only the FBI had the legal blessing of the DOJ,” Ellis said.
“Aside from that, I quite like the ‘chaotic good’ nature of this solution – especially given the chaos organizations are experiencing in finding all of the places that log4j might exist within their environment. The script basically takes the workaround first flagged by Marcus Hutchins which disables indexing and then uses the vulnerability itself to apply it. The fact that solutions like this are coming out so quickly is telling regarding the ubiquity of this vulnerability, the complexities of applying a proper patch, and the sheer number of ways that it can be exploited.”
Ellis added that the tool’s effectiveness is limited because it does not work for versions prior to 2.10, requires a restart, and the exploit must fire properly in order to be effective. Even when it does run properly, it still leaves the vulnerable code in place, Ellis explained.
Because of the complexity of regression testing Log4j, Ellis said he already heard from a number of organizations that are pursuing the workarounds contained in the Cybereason tool as their primary approach.
He expects at least some to use the tool selectively and situationally but said it is critical to understand that this isn’t a solution – it’s a workaround with a number of limitations.
“It has intriguing potential as a tool in the toolbox as organizations reduce log4j risk, and if it makes sense for them to use it, one of the primary reasons will be speed to risk reduction,” Ellis said.
