All the attempts here to address the vulnerabilities in log4j fall short. You cannot rely on the
locate command since it only looks in a set of configured paths (
/etc/updatedb.conf on Debian).
Software can install itself in locations not configured in
updatedb.conf and be completely missed by the cron job which updates the locate database.
Also, it is being discovered that software vendors (like Elastic) have repackaged the vulnerable JndiLookup.class (eg:
elasticsearch-sql-cli-7.16.1.jar) in places that were not previously known which leaves solutions incomplete which are built around known file hashes, names or paths.
@shodanshok is on the right path here but rather than searching for log4j explicitly, a look in every '.jar' on the system is what's needed.
This is more complete, requires the zip package. and an extension of shodanshok's answer. This will merely show locations where the
JndiLookup.class code is found. Another line could be added to remove these vulnerabilities but I would rather leave that up to admin discretion. The Elastic link above shows how:
for jar in $(find / -name '*.jar'); do
unzip -l "$jar" | grep 'JndiLookup.class' &>/dev/null && echo "Found vulnerability in $jar"
# for jar in $(find / -name '*.jar'); do
> unzip -l "$jar" | grep 'JndiLookup.class' &>/dev/null && echo "Found vulnerability in $jar"
Found vulnerability in /usr/lib/unifi/lib/log4j-core-2.13.3.jar
Found vulnerability in /home/minecraft/.m2/repository/org/spigotmc/minecraft-server/1.15.2-SNAPSHOT/minecraft-server-1.15.2-SNAPSHOT.jar
Found vulnerability in /home/minecraft/.m2/repository/org/spigotmc/minecraft-server/1.15.1-SNAPSHOT/minecraft-server-1.15.1-SNAPSHOT.jar
Be wary when running this on a system with mounted network filesystems as performance may be affected. In those instances, you need to run the commands on the file server itself.