The BigFix team is very pleased to announce the release of version 1.0 of BigFix Log4j Scanning Fixlets.
This Fixlet enables organizations to quickly scan their device ecosystem and gain visibility and measurability into where vulnerable versions of Log4j exist on their devices. The Fixlets will scan through various places where Log4j can be found, including .jar files as well as in java archives. Regardless of which of the scans methods you execute, BigFix can retrieve the results in a single analysis.
These Fixlets will enable you to:
Better discover, track, and understand your Log4j affected assets
Quickly identify, prioritize, and prioritize issues by having the dependency context of your devices
This task will:
Download a platform specific JRE or JDK
Download a log4j-scan utility JAR file from Logpresso
Run the log4j-scan utility JAR with the platform specific JRE or JDK
Save results to a file. Results available in an analysis
Delete the platform specific JRE or JDK when the scan is completed.
The following platforms are currently excluded:
Windows 2012 or older, Windows 8 or older
Linux Z and Linux PowerPC Big Endian
HP-UX
Important Notes:
This Fixlet relies on an underlying open-source component from LogPresso, a vendor of security solutions. Please ensure that your organization approves using open-source technology from this vendor. HCL Software/BigFix is NOT responsible for the integrity or safety of the LogPresso technology. If you do not want to use the component from LogPresso, do NOT use this Fixlet.
The scan should not be deployed all at once on all systems due to potential impact to shared network and disk resources.
The scanner will try to avoid common network file shares and will not follow symlinks to help prevent common potential problems, but this is not a guarantee that all cases are covered. If you know you need to exclude specific paths, those can be added in the field below.
A BigFix task that can also do mitigation of Log4j vulnerabilities using the same technology is available if you contact us or unofficially through the BigFix community
Published Content:
BES Inventory and License Site version 193
It’s… Potentially Vulnerable, which I know isn’t a great answer, but with the Log4j 1.x vulnerabilities it depends on how the application is using Log4j, specifically whether it uses the JMSAppender function.
You should contact SolarWinds or check their support bulletins to determine whether the jmxterm plugin is vulnerable or whether update is available.
I also noticed that the downloaded files dont appear to be removed from the bigfix client directory on the clients?
I thought most things were purged after 24hrs?
My inventory scan found infozip on a few hundred servers which made me look.
C:\Program Files (x86)\BigFix Enterprise\BES Client__BESData\BES Inventory and License__Download
After 4 days i still see:
jre.zip
logpresso-log4j2-scan.jar
unzip.exe
Is there a process to clean this out automatically or on demand?
We haven’t set up deletion content, expecting most customers would set up recurring scans. I think we can build something pretty easily though, look for it in the next week or two.
Apologies, I think I misunderstood the question to begin with.
You’re referring to these files?
Directory of C:\Program Files (x86)\BigFix Enterprise\BES Client\__BESData\BES Inventory and License\__Download
01/03/2022 09:57 AM <DIR> .
01/03/2022 09:57 AM <DIR> ..
01/03/2022 09:56 AM 39,046,089 jre.zip
01/03/2022 09:56 AM 639,740 logpresso-log4j2-scan.jar
12/19/2021 12:11 PM 204,800 unzip.exe
3 File(s) 39,890,629 bytes
Commonly, we do not manually delete the files from the per-site __Download directory. The directory is automatically cleared when the BES Client is restarted, or when another Action with downloads is taken from the same Site. That’s not unique to this Fixlet, but it might be less noticeable in other sites like “Patches for Windows” where we either have multiple Actions with downloads (each new Action deleting the previous Actions’ downloads), or where the action is usually followed by a system reboot (where the downloads are deleted when the BES Client service is stopped).
In this case, the action isn’t usually followed by a reboot, and this could be the only fixlet with downloads in the “BES Inventory and License” site…so yes I agree we should update the content to manually delete our own downloads after we extract them. I’ll start the process to make that change, we have a few other updates to make as well on providing Remediation and Backout fixlets.
Since the scan fixlet downloads and puts a JRE in the utility cache. As a refresher, how often is the utility cache reset? (Is it every client restart, like the general downloads?)
The Utility cache is meant for longer-term storage of things that will be reused by multiple actions. We generally use it for things like “unzip.exe”. The Utility cache is very small by default, but we usually recommend increasing it to around 250 MB.
Once a file is in the Utility cache, it stays there until the cache size is exceeded, then the least-recently-used file is removed from the cache; if it’s referenced in another Action, it gets downloaded again. The Utility cache is persistent across client restarts or system reboots.
The files in the Utility cache are named for their sha1 value and have no extension, so they aren’t usable directly without renaming them. You can find them under __BESData/__Global/__Cache/Utilities :
Can they be reasonably expired? Regardless of mitigating factors, piggybacking a JRE into the cache invites a new set of vulnerability/remediation concerns.
Hi All,
I’m pretty new new, and was reading up on the log4j scanner/fixlet. Could someone point me to where I can download the latest Logpresso v2.6.3 and upload it to BF for use. Is there a link some where that detail the install and how to use?
