I have read about security vulnerabilities related to Log4j.
How do I check if Log4j is installed on my server?
My specific servers use Ubuntu 18.04.6 LTS.
I have installed many third-party packages and maybe some of them contain it.
Is there a command to run on my server to check if Log4j is installed?
Try this script to get a hint:
echo "checking for log4j vulnerability..."
OUTPUT="$(locate log4j|grep -v log4js)"
if [ "$OUTPUT" ]; then
echo "[WARNING] maybe vulnerable, those files contain the name:"
echo "$OUTPUT"
fi
OUTPUT="$(dpkg -l|grep log4j|grep -v log4js)"
if [ "$OUTPUT" ]; then
echo "[WARNING] maybe vulnerable, dpkg installed packages:"
echo "$OUTPUT"
fi
if [ "$(command -v java)" ]; then
echo "java is installed, so note that Java applications often bundle their libraries inside jar/war/ear files, so there still could be log4j in such applications."
fi
echo "If you see no output above this line, you are safe. Otherwise check the listed files and packages."
Make sure your locate database is up to date with updatedb.
Or better check and run the enhanced script from GitHub which also searches inside packed Java files. Run in one line with
wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q -O - | bash
I am not sure if there could be compiled Java Programs running on the server without java being installed though?
Or even compiled versions where the source files aren't even found inside packed archives any more?
There is also a lot development on GitHub, where you find attacks and countermeasures.
This takes to much time for me. I am looking for someone I can transfer the ownership of the repository on GitHub
There is no command that will surely tell you that. Some applications ship the libraries they use directly as a jar file, some will contain them in an archive.
And even then you don't know which version is shipped and how it is used. The only way to be sure you mitigate the CVE is to read the security announcements and release notes of your applications and follow their advisories.
Try this Commands:
dpkg -l | grep liblog4j
dpkg -l | grep log4
find / -name log4j-core-*.jar
locate log4j | grep -v log4js
I wrote this Python script to find vulnerable Log4j2 versions on your system: https://github.com/fox-it/log4j-finder
It works by by scanning the disk and inside Java Archive files recursively and looking for known bad files.
Published by Google under the Apache-2.0 License, log4jscanner is a log4j vulnerability filesystem scanner and Go package for analyzing JAR files.
Apologizing for the referencing of outside material, I hope this will be tolerable in the present circumstance.
The information Lunasec.io has put out about hashes of vulnerable binary Java .class files:
https://github.com/lunasec-io/lunasec/blob/master/tools/log4shell/constants/vulnerablehashes.go
Also see their blog: https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/
Should you have ordered hashes (one per line) of suspected classes in a file hashes and have a jar file subject.jar and have the unzip, find and sha256sum commands, then you can do a compare against the known hashes with:
JARFILE=subject.jar; DIROUT=$(mktemp -d); unzip -qq -DD "$JARFILE" '*.class' -d "$DIROUT" && find "$DIROUT" -type f -not -name "*"$'\n'"*" -name '*.class' -exec sha256sum "{}" \; | cut -d" " -f1 | sort | uniq > "$JARFILE"-hashes; rm -rf -- "$DIROUT"
comm -12 hashes subject.jar-hashes
If comm has output, then there is a matching hash.
Try syft. It creates a software bill of materials (SBOM), which you can then search for old log4j versions (even works with docker images).
Something like syft dir:/opt/foo-application | grep log4j searches in conventional deployments. syft dir:/ | grep log4j should work for your whole server.
Passing your docker images also works:
# syft -q jacobalberty/unifi:5.13.29 | grep log4j
log4j-api 2.12.1 java-archive
log4j-core 2.12.1 java-archive
log4j-slf4j-impl 2.12.1 java-archive
tomcat-embed-logging-log4j 8.5.2 java-archive
Creating a script to pass all your docker images to syft should not be too hard, but you might find some inspiration in those scripts of mine: https://github.com/debuglevel/syft-grype-utils
John Hammond published with some others a hosted LDAP redirect service so you can skip all the shenanigans. https://log4shell.huntress.com/
Directions are simple - It generates a client ID for you (it's in the URL, as well as part of the injection string) which you can post to any Form/request/or derivative of web request.
Generally, if you are running anything that "doesn't work with this because it's local access" then you're fine anyway as there is no means for forwarding through your java-based application.
Of note - I believe the majority of concern should be placed at L2/L3 network management hardware; Especially if you're dealing with an ISP or your content is served via a Hosting service.
Checking for installed packages is not sufficient, as log4j can be manually installed by some other applications.
For Linux servers I am using the following: find / -iname "*log4j*.jar"
For Windows servers one can use something similar to that: dir C:\*log4j*.jar /s (changing C: to D: and so on for other disks).
Filenames will generally show the library version, but to double-check you can open the manifest file and read the version/implementation fields.
Please note that the above is not sufficient to catch embedded log4j (eg: in other jar files). For these one has to grep the relevant string, but this is quite time and resource intensive so I suggest going with file search as a first (but incomplete) step.
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"
done
Example:
# for jar in $(find / -name '*.jar'); do
> unzip -l "$jar" | grep 'JndiLookup.class' &>/dev/null && echo "Found vulnerability in $jar"
> done
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.
lsof checks open files, posted by Florian Roth on twitter:
ps aux | egrep '[l]og4j'
lsof | grep log4j
two others commands also, but these are the resident, in-memory search commands
