Here’s How to Remediate Log4j Quickly with the Right Tools

By Tom Blauvelt, Vice President of Sales Engineering

Image credit: Rob Fuller

The ever-evolving Log4j vulnerability landscape is the “vulnerability gift that just keeps on giving.”

A quick scan of the headlines is all one must do to understand my sarcasm: 

Cyberscoop reports that The US Cybersecurity and Infrastructure Security Agency (CISA) warns that the Log4j vulnerability will likely affect hundreds of millions of devices and that the vuln “is one of the most serious…if not the most serious” seen by the agency’s director Jen Easterly. 

Microsoft’s Threat Intelligence Center (MSTIC) is reporting “multiple attacker groups taking advantage of this vulnerability, including nation-state actors and access brokers linked to ransomware.”

The Hacker News reports “Hackers begin exploiting second Log4j vulnerability as a third flaw emerges.”

As if these “gifts” aren’t bad enough, security expert Rob Fuller points out in his LinkedIn post: “It’s a library, you can NOT 100% confirm this via a list of “installed” software. The JAR file can be anywhere.”

Devil in the Details: The Tricky Thing About Java and Locating Log4j

Rob’s point must not be overlooked.

With Java, dependencies can be embedded inside JAR files. The closest analogy is with Russian nesting dolls, where JAR can be “nested” in a JAR that is nested in a JAR, and so on. These nested JAR files can serve to “hide” vulnerabilities from traditional scanners and other tools.

However, it just so happens that Rezilion has developed a cool new technology that tears open the proverbial nesting doll and reveals what is hiding within!

Where many organizations are searching high and low for their Log4j vulnerabilities, Rezilion Validate helps customers very quickly identify vulnerabilities across their enterprise regardless of if they are in a CI/CD pipeline, on-prem server, or cloud workload.

Here’s how: Unlike other scanning tools in the market today, Validate doesn’t solely rely on a point-in-time scan of a host’s file system to determine software inventory or vulnerability risk, but rather, leverages a continuous scanning process combined with a powerful step: the “mining” of what is loaded into memory.

This dynamic mining of memory is unique in the market, and this is where the “magic” happens. Once we understand what is running in the host’s memory, content is then mapped back to the originating source on each file system, allowing linkage between memory and files, packages, libraries, JARs (nested or otherwise), etc.

Two key capabilities result: a fully searchable and up-to-date dynamic Software Bill of Materials (Dynamic SBOM) and an overlay of context about which files/packages/libraries are loaded or not loaded into memory.

“So how does this help with my Log4j problem… er, gift?” you might ask… Great question!

These two sources of information drive extremely powerful use cases, including a couple that are enabling our customers to find and mitigate the Log4j vulnerability. But rather than tell you, let me show you.

By way of example, here is a screen shot where we can show the output of a query that searches for all package names and versions that are associated with Log4j vulnerability.

Here you can see a list of packages that are returned by the query.

Specific JAR files are also searchable as shown here.

Returning the results here.

But even more than just identifying if the vulnerable Log4j library or JAR files exist, Validate will also report if the library is loaded into memory or not. This results in enabling defenders to focus remediation on hosts where the vulnerability can actually be exploited. This attack surface validation is based on what is loaded into memory and does not exist elsewhere in the market, proving a powerful ally for incident responders and remediation teams.

In this next screen shot, observe 10 packages that contain the Log4j vulnerability, only four are “loaded” – meaning only four are exploitable. This is a result of Validate’s ability to instrument the host and read what is loaded into memory.

After filtering out the six that are not loaded into memory, a remediation report based on actual risk is produced.

Lastly, Validate provides detailed information about each package.

If you are interested in finding out how Rezilion can help you with the Log4j vulnerability, please schedule a Log4j risk assessment with us today. Or perhaps you want to prepare for the next vulnerability “gift,” in which case, Rezilion can help you establish a dynamic SBOM. Learn more about Rezilion Validate.

Cyberscoop – CISA Warns ‘Most Serious’ Log4j Vulnerability Likely to Affect Hundreds of Millions of Devices

Microsoft Security Blog – Guidance for Preventing, Detecting, and Hunting for CVE-2021-44228 Log4j2 Exploitation

Hacker News – Hackers Begin Exploiting Second Log4j Vulnerability as a Third Flaw Emerges