The string of vulnerabilities found over the past few weeks in the widely used Log4j open-source Java component continue to keep enterprise security teams busy. While patching the impacted library should be the priority, identifying all affected applications and servers on big networks is not straightforward due to indirect software dependencies and third-party products.
The problem is the more time it takes organizations to find potentially exposed assets, the more time attackers have to find them and exploit them. Different groups of attackers are currently exploiting the remote code execution flaws, ranging from state-sponsored cyberespionage actors to ransomware groups and cryptocurrency mining and DDoS botnets.
It’s therefore vital that organizations not only identify vulnerable assets and put in place a mitigation strategy, which might be different for every case, but also look for indicators of compromise and exploitation attempts in their servers and application logs.
Detecting vulnerable applications and servers
The security community has developed and released multiple open-source tools that can be used to scan directories and file systems for instances of vulnerable Log4j packages, and commercial vulnerability scanners have also added detection for this vulnerability. However, all scanners can have blindspots and that’s particularly true when dealing with Java components like lLog4j.
First, while many Java packages come packaged as JAR (Java ARchive) files, this is not the only format used for Java application deployment. There’s also TAR (uncompressed Tape Archive), WAR (Web Application Archive), EAR (Enterprise Application Archive), SAR (Service Application Archive), PAR (Portlet Archive), RAR (Resource Adapter) and KAR (Apache Karaf Archive).
