Log4Shell: A Tale of Two Detection Techniques

Endpoint detection and response (EDR) can only take you so far in identifying Log4j exploit attempts. Here’s why dynamic checks are needed to uncover vulnerable versions of Log4j.

When the Log4j vulnerability was disclosed at the tail end of 2021, it caused many IT teams to put down their well earned eggnog and cast a concerned look at their environment. Unfortunately, understanding what was vulnerable to this newly disclosed flaw was far more difficult than simply pulling an accurate inventory of Log4j instances, with the troublesome library often harder to track down than a Playstation 5.

Using an endpoint agent, for example endpoint detection and response (EDR), or a credentialed scan to identify Log4j instances will only get you so far. Like many Java libraries, Log4j is often bundled into “Fat Jars” (Jar files that include all external dependencies) or inserted directly into the source code as a way of shading the library versions to lessen the probability of conflicts. Simply asking “Do you have Log4j installed?” isn’t going to give you a very clear understanding of where you’re vulnerable.

But “EDR will block attempts to exploit Log4j!” I hear you all cry out in delight. Not so fast. An attacker could easily stay within the Java Virtual Machine (JVM), away from the prying eyes of the EDR process monitors; blocking outbound calls from a server is going to end badly. The idea of hiding nefarious activity within the Java virtual machine isn’t new, but all the top EDR vendors have been slow to address this rather large chink in their armor. EDR can stop breaches (as long as they’re not Java based).

In order to deal with the Log4j detection issue, Tenable released a whole new approach to assessment within hours of the legendary flaw being announced. Put simply, our dynamic checks fired a Java Naming and Directory Interface (JNDI) query into targets that instructed any systems vulnerable to Log4j to send a unique token to a Tenable hosted system that the scanner could look up to see if a message had been received. This approach ensured we’d be able to more easily uncover vulnerable versions of Log4j across a multitude of ports and protocols, because the only tokens being sent would be from those systems that had the flawed library somewhere within the stack or application code.

And we saw a lot of those unique tokens being sent to Tenable. Days after disclosure, we were seeing over 1,400 new tokens … EVERY SECOND and one in 10 assets assessed by Tenable were vulnerable.

In the case of Log4j, a false negative could mean a system is left vulnerable due to a poor assessment. Relying on endpoint detection to block exploitation is nowhere near enough of a defense, leading to a surefire foothold for any enterprising attacker. Tenable is investing significant effort in ensuring we continue to lead the market in detecting Log4Shell across the ever growing list of applications and protocols that are vulnerable.

Learn more

• Read the technical whitepaper for more information on the new approach to identifying Log4j via the dynamic plugins
• VIsit our landing page to keep up to date with all the log4j news
• Read the blog, Assess Log4Shell Like an Attacker with Tenable’s Dynamic Detections