After public disclosure of the vulnerability in Log4j last week, an open source Java-based logging tool, vendors have been scrambling to find where they might be at risk to the CVE that broke the Internet. Vicarius, the Israeli autonomous vulnerability remediation company, is ahead of their competitors, offering new technology to detect and fix Log4J with no vendor involvement whatsoever. 

With a successful exploit, an attacker can hijack a Java-based web server and execute code remotely, ultimately controlling the organization’s servers. From here, the attacker can launch a plethora of malicious campaigns, such as a cryptomining attack, DDoS attack, or encrypting files for ransom. 

“Software developers use the Log4j logging library as a way to accelerate the software release process. This is not uncommon; using pre-existing libraries is a standard practice in modern product development. It’s found in everything from web cams to Twitter to Apple iCloud. Because Log4j is widely used across enterprise applications, attackers have a large attack surface at their disposal,” said Yossi Ze’evi, CTO, Vicarius. 

Vendors are working against the clock. They need to find which applications are vulnerable to Log4j and create their own patches, a process that could take months. With hundreds of applications to sift through, there is a significant window of opportunity for attackers to exploit the unpatched vulnerability. As a result, security teams will be forced to wait for a vendor update or security patch while remaining helpless against a potential attack. 

“We have this enigma in vulnerability management where the customer is dependent on the vendor for protection as it relates to vulnerability exploitation. This is a prime example of that problem: a zero-day becomes public, vendors scramble to fix it, and organizations are left biting their nails as they pray they don’t get targeted. It’s a game, and the defense is always going to lose if they keep using the same play. We need new solutions that can adequately address this problem”, said Michael Assraf, CEO, Vicarius.

Fortunately, Vicarius has come up with a way to help security teams stuck in this situation. After learning the structure of each software and where the files are located, the Vicarius platform searches for the vulnerable Log4j library file on the disk post-deployment. This accelerates the vulnerability discovery and remediation process. 

The CEO also added that the company not only found a new way to detect the threats, but also to fix it using hot-file swapping of the old JAR file of Log4j version 2.14 and replacing it with  2.16. Security teams may be able to salvage some of their holiday relaxation time as this method does not require updating the software. 

It’s difficult to assess the potential fallout from the Log4j vulnerabilities. Criminal groups, nation state actors, and other malicious actors have actively been targeting servers for the vulnerabilities, and more exploitation is likely to follow in the coming months as organizations prepare their patching cycles. Perhaps a closer look at the dependencies placed on open source code will be needed to avoid a catastrophe like this in the future.