Log4j CVE-2021-44228 Detection and Mitigation

Content Authoring
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.

43

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
44

You can pull up the analysis in Web Reports and export to CSV to see all the results.

45

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?

46

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.

47

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.

48

Thanks for your work. I ran against AIX, Linux and some windows servers, output looks good so far.

2 Likes
49

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
50

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

51

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
52

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

https://www.ibm.com/docs/en/aix/7.2?topic=f-find-command