Thanks for the updated property with the hash checks I am getting results now. For the lines that don’t return “not matched” means “matched” without actually saying it. I compared the hash that was output compared to the list and it does match. Can you add a “Matched” for consistency?
1 Like
You can pull up the analysis in Web Reports and export to CSV to see all the results.
Another side of this vulnerability is the version of Java that is launching the log4j jar. From my understanding If the log4j jar file is launched from specific versions of java it remediates at least part of the vulnerability. Do you know of any way that BigFix can identify if the log4j jar is launched in memory and running and then gather what version of java executed it?
I don’t know a consistent way to get those details. I think the main utility of this analysis is to find where to begin looking.
Once identified, you might examine the individual applications’ configurations to know whether they are truly vulnerable.
If the line does match, the third field reflects which know. Log4j version it was matched against…I don’t know that I would want to lose that field.
Thanks for your work. I ran against AIX, Linux and some windows servers, output looks good so far.
2 Likes
Just writing here as a placeholder, I have made a few changes, the current version does not work on AIX or SunOS despite looking like “running”, or on any versions older then bigfix 9.0.
Mine now runs down to 8.2 and all tested, AIX and SunOS included.
Also confirmed current version works fine on centos, suse, oel, rhel, windows down to 2003 (not tested 2000… despite having some).
Hopefully get added soon to original fixlets and analysis, also I have added SHA1 ability for client versions less then 9.1 so can still compare for same versions via SHA1 value, may even have been smarter to use SHA1 for all to keep it simple? It is what it is for now.
Thanks @JasonWalker for this, saved me many hours of work on Saturday as I was about to start making my own before I saw this
2 Likes
Hi Jason,
it seems this task did not scan all file system on Linux system. I see the file with “Scan complete” but a directory under /opt has a file name log4j-1.2.17.jar
Please help and suggest what can be done to get complete list
Regards
Sunil
You could be opening a big can of worms potentially. There could be variations of names of Log4j, but Log4j afaik has many different packages.
Most security sites recommend scanning for the filter used here, which is the standard name convention.
Anyone of course can rename it, even to Log4j.jar for exampl, there is no end.
If you are wanting everything change the filter to
*log4j*.jar
1 Like
Sure that AiX works? find / -not is an unsupported switch (tested on AiX v7.2 & 7.4)
find / -not -fstype nfs -name log4j-core*.jar
find: bad option -not
As I put it there AIX and SunOS do not work, -not needs to be replaced with !
I submitted information with my updates, hopefully get updates here
NOTE: dont just replace it, it breaks everything else, need to specify AIX and SunOS separately
1 Like
Thanks Mario,
I am new to BigFix, where can I locate the script to change the filter?
I have used “https://bigfix.me/fixlet/details/26889” fixlet for scan and analysis to review results.
Regards
Sunil
I assume you are running back-level (8.2) agents to accommodate an older OS where agent support stopped at a prior level.
Could you upload your version to bigfix.me to share with others on the forum? I am sure @JasonWalker and the community would appreciate your enhancements to allow it to run on BigFix v8.2 clients.
Or just mention what elements needed the tweak so Jason can update his?
Was it more than just replacing: storage folder of client (9.0+)
1 Like
I’d welcome the syntax for the ‘find’ command on AIX and/or Solaris, especially if you know a working filter to avoid traversing NFS
1 Like
There was a little bit yeah
Scan task: https://bigfix.me/fixlet/details/26892
Analysis: https://bigfix.me/analysis/details/2998661
Changes to scan task:
- The scan can now run on AIX and Solaris servers, the syntax was incorrect, after modifications confirmed suse, rhel, oel, centos, aix and sunos and windows are returning results just fine
- Changes made so it runs on any client version 8.2+ to catch Windows 2003, RHEL3, etc etc, this has also been tested on old versions that the original did not pick up on, have many Win2000 boxes but didn’t confirm if it works on those yet…. ……
Changes to the analysis:
- Pick up the expanded range of computers now available, all tasks modified to suit 8.2+ relevance
- The last task that brings the SHA256 value and matching is updated also to return SHA1 hash on systems that are below 9.1 client version, I did NOT update the SHA1 values to match to, but they could easily be added if needed. Currently due to scale of the task, I am just manually doing this in excel and building a table, similar as to what this is doing.
I hope @JasonWalker if interested can put the updates in his tasks and analysis, the credit is all his.
Ill remove mine then.
1 Like
I did get a copy of the updates from Zane and will be incorporating, thanks so much for your help on improving this.
2 Likes
Aha, I wasnt sure if he sent them through yet, nice one!
I’ve updated the Task and Analysis at
Scan Task: https://bigfix.me/fixlet/details/26888229
Analysis parsing results: https://bigfix.me/analysis/details/2998657154
Changes:
- Better handling for scanning AIX, Solaris, and MacOS (thanks @Mario and @zanesand !)
- Add Analysis property to retrieve and compare sha1 hashes for detected files
- Modify Analysis to use ‘native file’ rather than ‘file’ inspector, when ‘native file’ is available, to handle potential Wow64 Redirection on 64-bit Windows.
- Shortened the “matched log4j version” result on the sha256 for brevity. For example the match “apache-log4j-2.15.0-bin/log4j-core-2.15.0.jar” is shortened to “log4j-core-2.15.0.jar”
6 Likes
Another update to the Analysis result, this time to replace the use of ‘storage folder of client’. This Property may not exist on very old versions of the BigFix client.
I’ve also just observed that the links on BigFix.me change when I add new versions, so I am updating the links in the first post with the latest versions, currently:
Scan Task: https://bigfix.me/fixlet/details/26893
Analysis Results: https://bigfix.me/analysis/details/2998663
7 Likes
Was there not a sync tool in the past that let the content stay up to date?