I see a lot of posts about the Log4j vulnerability and the steps to mitigate it with Jamf products. Has anyone been successfully in searching their Mac endpoints looking to see if any of the managed systems have the vulnerable versions? I know for a fact there there are many versions and installed applications that have a vulnerable versions. I would love to be able to report of them either with an EA or a script with some kind of output.
Anyone tried to tackle this yet?
a lot of big companies will use scanning products to pick up on vuns esp when they can be configured for just finding the jar's...
if you dont have big ol' corporation infra or power to bring in a 3rd party system deploying and runing this java app to return a result into a EA might be good but it will probably take a while to run so maybe do at low use times for endpoints. returns nice exit codes...
I've just whacked together an Extension Attribute that uses lsof to look for open files that contain log4j. Thought it was a good starting point, it's only going to pick up Apps or services that are currently running though. Tenable Nessus can be used to scan the network for log4j vulnerabilities.
#!/bin/sh log4j=$(lsof | grep log4j) if [ -z "$log4j" ] then echo "<result>Not Found</result>" else echo "<result>$log4j</result>" fi exit 0
You would have to search the whole of the drive because the files could be anywhere. The search would take quite some time so putting it directly into an Extension Attribute might not be the best idea.
You could use the command below in a policy, but output the results to a text file, then read that text file into an Extension Attribute. The output might need some cleaning up.
/usr/bin/find / -name "log4*.jar"
You can safely remove the Gradle caches. The only problem with that is if the user has the vulnerable version as a dependency to their build process then the next time they build with Gradle it'll appear again in their new cache. I'm reviewing a way to run Logpresso across the environment. The scan determines if the file is actually vulnerable by looking for the existence of the JNDI Lookup Class inside the files. There is also a way to run the scan with a "fix" switch that will actually remove the JNDI Lookup Class from the file leaving it in place to continue logging, but without the vulnerability. Users should still look to update their dependencies in their build apps to v. 2.17.1 (at least that's what it is right now, I'm sure it'll change again).
GitHub - logpresso/CVE-2021-44228-Scanner: Vulnerability scanner and mitigation patch for Log4j2 CVE...
@Stephen_marquar I am looking into using logpresso. Curious to know how it worked for you and was it effective? Especially how you set the san target paths, is there a way to do multiple? Seems like a great tool based off of the Github page for it, just looking to know some more about it. Currently dealing with that gradle issue as well.