log4j remediation (beyond jamf server)

I think it depends on what it is.  I've just packaged a patch for SPSS which had the files buried in the App.

Probably best to figure which machines have log4j and where and start from there

I assume that many products that use log4j are not necessarily vulnerable in the same way as servers that listen on http or https. So for now I don't worry about clients that have apps that use log4j. I also would not go and replace files individually, since I don't know which version they are using and which version they are compatible with. I hope the vendors will look after their product and maintain its security, and if they don't off it goes.

Might want to reach out to each vendor to get their mitigation statement. They're either going to say "we fixed it in XYZ version" and you can deploy the update, or they might say "our product is not vulnerable", or might blow it off.

Pays to be proactive, download/deploy/run this log4j detector tool to get ahead of the curve.

https://github.com/mergebase/log4j-detector/

PS, I submitted an "Issue" asking for the ability to exclude paths, the developer turned it around the next day.

And advice or tips on how to even deploy this for folks not familiar with things like this?

looking for the best way to deploy this using Jamf to our endpoints as well.  

Deploy the log4j-detector-latest.jar to the folder you deploy your scripts/tools to, for example:

"/Library/Application Support/COMPANYNAME/log4j-detector/log4j-detector-latest.jar"

Run a script Once Per Computer that scans the computer, and spits out a file with vulnerability info (paths to log4j instances, including the assessment that is in the end of each line) into the same folder. Note use of nohup and & so the policy doesn't hold up any pending policies, and don't bother updating inventory, that'll happen later, when the file is populated.

The reason for Once Per Computer, is to avoid a race condition that can return empty or missing reports. If you want to run it again, flush all logs for the policy.

#!/bin/bash
if [ -e "/Library/Application Support/COMPANYNAME/log4j-detector/log4j-detector-latest.jar" ]
then
/usr/bin/nohup /usr/bin/java -jar "/Library/Application Support/COMPANYNAME/log4j-detector/log4j-detector-latest.jar" / > /Library/Application Support/COMPANYNAME/log4j-detector/log4j-detector.txt"
fi

Have an Extension Attribute (EA) that grabs the contents of the file.

#!/bin/bash
SUMMARY_FILE="/Library/Application Support/COMPANYNAME/log4j-detector/log4j-detector.txt"

if [ -e "$SUMMARY_FILE" ]
then
echo "<result>$(/bin/cat "$SUMMARY_FILE")</result>"
else
echo "<result>DoesNotExist</result>"
fi

If you want to get slick, create another Extension Attribute that gives you a count of all instances of for example "_VULNERABLE_":

#!/bin/bash

HOW_MANY=$(/usr/bin/grep -o "_VULNERABLE_" "/Library/Application Support/COMPANYNAME/log4j-detector/log4j-detector.txt" | /usr/bin/wc -l | /usr/bin/awk '{print $NF}' 2>/dev/null)

echo "<result>${HOW_MANY}</result>"

Hope this is helpful.

And if you were told the log4j exists or is being detected and running the detections says otherwise?

Has anyone run up against this?

How woudl one upgrade after detection is successful?

Much apprecitated help.

Dom