Following the critical vulnerabilities discovered in Log4j (CVE-2021-44228 and subsequent issues), system administrators need reliable methods to detect potentially vulnerable installations. On Ubuntu 18.04 LTS systems, Log4j may exist either as a direct installation or as a dependency within other Java applications.
Start with these terminal commands to scan your entire filesystem:
sudo find / -name "*log4j*" 2>/dev/null
For more targeted Java archive searches:
sudo find / -type f -name "*.jar" -exec grep -l "log4j" {} \; 2>/dev/null
Use Ubuntu's package management tools to check installed versions:
dpkg -l | grep -i log4j
For complete Java dependency trees:
apt-cache depends --recurse --installed | grep -i log4j
When dealing with embedded installations, use this Java class verification method:
for jar in $(find / -name "*.jar" 2>/dev/null); do
if unzip -l $jar | grep -q "org/apache/logging/log4j"; then
echo "Found in: $jar"
fi
done
For any discovered Log4j files, extract version information:
find / -name "*log4j*" -exec sh -c 'echo "File: {}"; \
unzip -p {} META-INF/MANIFEST.MF 2>/dev/null | \
grep "Implementation-Version\|Bundle-Version"' \; 2>/dev/null
Many services (Elasticsearch, Hadoop, etc.) bundle their own Log4j. Check common locations:
ls -la /usr/share/{elasticsearch,kafka,hadoop}/lib/log4j*
Consider these specialized scanners:
- log4j-detector:
java -jar log4j-detector.jar /path/to/scan
- log4j-scan:
python3 log4j-scan.py -u http://localhost
With the critical Log4j vulnerabilities (CVE-2021-44228, CVE-2021-45046, etc.) making headlines, system administrators need reliable methods to check for Log4j presence. On Ubuntu systems, Log4j can exist in multiple forms:
- Directly installed Java packages
- Bundled with third-party applications
- Nested in Docker containers
- Hidden in legacy deployments
Start with standard package manager checks:
dpkg -l | grep -i log4j
apt list --installed | grep -i log4j
However, this only finds system-wide installations and won't detect embedded instances.
For comprehensive detection, scan your filesystem for JAR files containing Log4j classes:
sudo find / -type f -name "*.jar" -exec sh -c 'jar -tf {} | grep -qi "org/apache/logging/log4j" && echo {}' \;
For faster scanning with parallel processing:
sudo find / -type f -name "*.jar" | parallel -j 4 'jar -tf {} | grep -qi "org/apache/logging/log4j" && echo {}'
Examine currently executing Java applications:
ps aux | grep java | awk '{print $2}' | xargs -I {} lsof -p {} | grep '\.jar'
When you find Log4j files, identify their versions:
find / -name "log4j-core*.jar" -exec sh -c 'unzip -p {} META-INF/MANIFEST.MF | grep "Implementation-Version"' \;
Consider these specialized scanners:
# Log4j-detector (requires Java 8+)
wget https://github.com/mergebase/log4j-detector/releases/download/v1.1/log4j-detector-1.1.jar
java -jar log4j-detector-1.1.jar /path/to/scan
# Grype vulnerability scanner
docker run --rm -v /:/host:ro anchore/grype dir:/host
For containerized environments:
# Check running containers
docker ps -q | xargs -I {} docker exec {} find / -name "log4j-core*.jar"
# Check images
docker images -q | xargs -I {} docker run --rm {} find / -name "log4j-core*.jar"
If Log4j is found:
- Immediately identify if vulnerable versions (2.0-beta9 to 2.14.1) are present
- Check for known mitigations (log4j2.formatMsgNoLookups=true)
- Plan for upgrading to 2.15.0 or later
- Monitor for subsequent CVEs