+3I 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?
+5a 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...
https://github.com/mergebase/log4j-detector
+7a 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...
https://github.com/mergebase/log4j-detector
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
+5I'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
This works great and exactly what I was looking for to run on my macs. Thank you so much!
+9Hey all - I was looking for something like this thank you! I'm wondering though, if we wanted to utilize this to search for ANY *.log4*.jar files(even those not in running apps) how would that be accomplished?
+7Hey all - I was looking for something like this thank you! I'm wondering though, if we wanted to utilize this to search for ANY *.log4*.jar files(even those not in running apps) how would that be accomplished?
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"
+5You 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"
yeah i second that, you could even just make a script to find or use log4j-detector and if necessary i can either be scan results in a file or just touch a marker file in to existence to let the EA pick that up.
+6https://www.rumble.run/blog/finding-log4j/ suggest using the following
find / -type f -print0 |xargs -n1 -0 zipgrep -i log4j2 2>/dev/null
We have simply picked a single device (that's has the majority of our software on) and ran this as a starting point
+4is there a way we can make this script or EA available in Self service and when the users run the same from self service and output to be downloaded on the users desktop ?
+23What is the actual remediation? Do we just delete the jar files? A lot of the ones we uncovered were in IntelliJ IDEA and it's plugin for Gradle. IntelliJ says they are not vulnerable, but some of the Gradle 'caches' are showing vulnerable versions.
+1I'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
thanks for sharing this script for EA. it works for, but do you know if we can make this script available in self service so that users can get the path of the log4j.x.x as .txt file on the user desktop . which would be easier for the user to update
+3What is the actual remediation? Do we just delete the jar files? A lot of the ones we uncovered were in IntelliJ IDEA and it's plugin for Gradle. IntelliJ says they are not vulnerable, but some of the Gradle 'caches' are showing vulnerable versions.
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-2021-44228
+4You 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-2021-44228
@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.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.