Log4j CVE-2021-44228 Detection and Mitigation

Content Authoring
21

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

3 Likes
22

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!

2 Likes
23

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

2 Likes
24

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!!!

3 Likes
25

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

2 Likes
26

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

2 Likes
27

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.

2 Likes
28

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.

2 Likes
30

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")))

3 Likes
31

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

32

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: [LOG4J2-2109] Add property to disable message pattern converter lookups - ASF JIRA

1 Like
34

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

35

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 ?

36

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



2 Likes
37

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!

1 Like
38

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

2 Likes
39

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.

3 Likes
40

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

1 Like
41

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?

42

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.