Log4j CVE-2021-44228 Detection and Mitigation

[manny]

So far so good Jason. Your scan/analysis has accurately uncovered some positives. Thanks so much mate!

[fermt]

We have run the fixlet on more than 3k servers and we will go trough the results to validate them.

Special thanks to @JasonWalker for delivering this very quickly!

[JasonWalker]

It’s in a folder relative to BES Client; by default at C:\Program Files (x86)\BigFix Enterprise\BES Client\BPS-Scans\CVE-2021-44228.txt

[EMPOWER]

Slow rolled lab/test and once confirmed no issues successfully ran on ~10k nix and ~3k win servers. Lots of work to do now contacting app owners. Huge thanks to @JasonWalker!!!

[jbruns2017]

What about Bigfix products themselves? Are any affected by CVE-2021-44228?

[PShirmey]

I had some false negatives on servers that did not have the version in the filename, so I removed the last - before the * in the file matching pattern. log4j-core*.jar instead of log4j-core-*.jar

[JasonWalker]

Thanks very much for checking, I’ve updated the copy of the scan task at https://bigfix.me/fixlet/details/26889

The Analysis should report “potentially affected” for any of the log4j-core.jar files as they do not specify their version.

[atlauren]

FWIW, I’ve added exists folder "BPS-Scans" of storage folder of client to the analysis’ relevance, just so that it only slurps in machines that have previously run the scan.

[atlauren]

exist (folder "BPS-Scans" of storage folder of client) whose (exists (file "CVE-2021-44228.txt" of it) whose ( exists (if exists property "locked lines" then locked lines of it else (lines of it)) whose (it does not start with "SCAN_COMPLETE")))

[cjwolford]

I remember fumbling through it before, but what’s my easiest way to export the paths to excel instead of just multiple results?

[Austin4778]

I opened a support case on this one. The only products currently discovered as vulnerable are BFI and RC. Waiting on confirmation on the rest. Quote from case:

We have received your case regarding your concern with the discovered vulnerability in log4j. Currently, the products that show Log4j being used are BFi and Remote Control but we are still confirming with other products if they could also be affected by the issue.
Hypothetically anything that uses JVMs is vulnerable. The current workaround is as follows:
find the jvm.option file for the product you are using, update with -Dlog4j2.formatMsgNoLookups=true on a separate line in the file. Restart server This is the workaround until we get the updates out for all the effected products. From https://isc.sans.edu/diary/28120 :
due to exploitation being relatively simple, we would suggest that you try to apply one of the workarounds as soon as possible: A new log4j library has been released, version 2.15.0 that fixes the vulnerability. This is, of course, the best fix, but it might require recompilation and redistribution of packages
If you are using version 2.10.0 you can set a property called formatMsgNoLookups to true to prevent lookups. This can be passed as a parameter too.
For older versions you will need to modify logging patterns as specified here: https://issues.apache.org/jira/browse/LOG4J2-2109

[nicksberger]

Great work so far, anyone have the code to determine if the workaround config has been applied ?

[ifreeman]

This is great! Some of my servers are reporting for the pathname analysis even though the folder/file exists with text in it. Any suggestions on how to figure out why they are reporting ?

[Jstev]

Any thoughts about gathering the hash of the matched files so that they can be compared against the affected hash files?

mubix/CVE-2021-44228-Log4Shell-Hashes/blob/main/md5sum.txt

mubix/CVE-2021-44228-Log4Shell-Hashes/blob/main/sha1sum.txt

mubix/CVE-2021-44228-Log4Shell-Hashes/blob/main/sha256sums.txt

[JasonWalker]

I like that idea quite a bit, but I wasn’t looking forward to building this list of hashes, so thanks very much for posting them!

[JasonWalker]

The BigFix Team has published a KB article on affected BigFix components and workarounds. Please see https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0095486

I’ve opened an additional Forum thread for discussion specific to the BigFix components at CVE-2021-44228 Log4j impacts on BigFix

[JasonWalker]

I’ve updated the Analysis at https://bigfix.me/analysis/details/2998660 to take this into account.
There is a new property that shows the pathname of the detected log4j-core JAR file, the sha256 hash of the file, and the matching Apache hash version (if any).

That can be important in cases where we mitigate the problem by replacing an older log4j .JAR file with the newer 2.15.0 version, but need to keep the old version’s filename for compatibility – like we are recommending in BigFix Compliance. The Analysis can tell us the file named log4j-core-2.14.0.jar is actually the 2.15.0 file based on its hash value.

[Jstev]

I had modified the analysis to collect the hashes then used webreports to compare them but this is better. Thanks.

[bobdennedy]

For for clarity, this means if a device shows a result for “potentially vulnerable” and not for the new hash property, we would consider it not vulnerable. It might have applied a similar mitigation as BigFix Compliance?

Or maybe said another way, if a device has a result for the new hash property that is not , it is a better indicator of having the vulnerability?

[JasonWalker]

It may be that the computer hasn’t yet reported back for the hash property. I would expect every result from the “Log4j file paths” entry to have a matching Hash result property.