Open JStevens1855 opened 2 years ago
@JStevens1855 Scanner does mark log4j 2.16.0 as vulnerable.
cmd> java -jar logpresso-log4j2-scan-2.8.1.jar d:\tmp2\log4j-core-2.16.0.jar
Logpresso CVE-2021-44228 Vulnerability Scanner 2.8.1 (2022-01-27)
Scanning directory: d:\tmp2\log4j-core-2.16.0.jar
[*] Found CVE-2021-45105 (log4j 2.x) vulnerability in d:\tmp2\log4j-core-2.16.0.jar, log4j 2.16.0
Scanned 0 directories and 1 files
Found 1 vulnerable files
Found 0 potentially vulnerable files
Found 0 mitigated files
Completed in 0.25 seconds
If you tries to fix it, scanner will refuse it like this:
cmd> java -jar logpresso-log4j2-scan-2.8.1.jar --force-fix d:\tmp2\log4j-core-2.16.0.jar
Logpresso CVE-2021-44228 Vulnerability Scanner 2.8.1 (2022-01-27)
Scanning directory: d:\tmp2\log4j-core-2.16.0.jar
[*] Found CVE-2021-45105 (log4j 2.x) vulnerability in d:\tmp2\log4j-core-2.16.0.jar, log4j 2.16.0
Cannot fix CVE-2021-45105, Upgrade it: d:\tmp2\log4j-core-2.16.0.jar
Scanned 0 directories and 1 files
Found 1 vulnerable files
Found 0 potentially vulnerable files
Found 0 mitigated files
Fixed 0 vulnerable log4j2 files and potentially vulnerable log4j1 files
Completed in 0.09 seconds
Which scanner version do you use?
So I apologize I must have been mixing up my reports. the 4105 was on an older scan and wasn't identified as potentially vulnerable using 2.7.1 scanner, however I do have files what were scanned with the 2.1.1 jar that come back with 44228 as Potentially_vulnerable. I would think that if the jndi class was removed, then this file would change to mitigated rather than potentially vulnerable. Could it be that it can't determine the version for validation (maybe why it's showing n/a instead of a version). It looks like I have quite a few of these for 44228. Log4j 2 | N/A | CVE-2021-44228 | POTENTIALLY_VULNERABLE | | 1/30/2022 3:21 I am going to rescan with 2.8.1 to see if it it comes back different. I thought i had already updated the scanner version for windows but I guess I only updated the Linux scanner version. ****By the way thank you for all the work you have put into this project. The work really is amazing and appreciated.
Yeah not sure why but rescanned with 2.8.1 and the file came back with "Log4j 2","N/A","CVE-2021-44228","POTENTIALLY_VULNERABLE","","2022-02-01 10:39:40" Is this the behavior if it can't identify what the log4j version is?
@xeraph - I need to cross reference some of these apps that i'm seeing this on but I'm thinking maybe some were remediated by setting the Log_level to off. Would that scenario be a reason that it might show potentially_vulnerable rather than vulnerable or mitigated?
@JStevens1855
Yeah not sure why but rescanned with 2.8.1 and the file came back with "Log4j 2","N/A","CVE-2021-44228","POTENTIALLY_VULNERABLE","","2022-02-01 10:39:40" Is this the behavior if it can't identify what the log4j version is?
Yes. If scanner cannot detect log4j 2 version, it print potentially vulnerable.
@xeraph - I need to cross reference some of these apps that i'm seeing this on but I'm thinking maybe some were remediated by setting the Log_level to off. Would that scenario be a reason that it might show potentially_vulnerable rather than vulnerable or mitigated?
IMHO, false positive is better than false nagative. I will resolve this issue with md5 detection.
@JStevens1855 Would you test v2.9.1 release? I added 55 MD5 hashes to resolve this issue. It accurately detect Log4j 2.x version without pom.properties file.
Unfortunately after scanning with 2.9.1 the results were the same. I attached a screenshot of the csv details, hopefully it comes through for you It looks like we have at minimum 3 applications on numerous servers that are coming up "Potentially_Vulnerable" for CVE-2021-44228. I'm not sure why it's not able to identify the Log4j version still but I was able to get ahold of new relic instructions for temporary "remediation" they did for the new relic application and i'm guessing that it just likely wouldn't be able to identify that it we remediated. Here is the temporary remediation, but i'm guessing because of the method for remediation it probably just be a false positive going forward. You can set your Java agent logging level to OFF to remediate CVE-2021-44228. To do this, use any of the following options:
Modify your local agent configuration file (search for the log_level parameter) (no restart is required) Define the newrelic.config.log_level=OFF system property (restart required) Set the NEW_RELIC_LOG_LEVEL=OFF environment variable (restart required)
@JStevens1855 Would you send me that newrelic.jar file? you can change file extension to zip and upload here, or box.com sharing link.
@xeraph I got still N/A for one file, maybe you can add the MD5 to on of the next versions.
$ sudo /usr/lib/check_mk_agent/bin/log4j2-scan --scan-logback --scan-log4j1 /usr/share/java/log4j-1.2-1.2.17.jar
Logpresso CVE-2021-44228 Vulnerability Scanner 2.9.1 (2022-02-03)
[?] Found CVE-2021-4104 (log4j 1.2) vulnerability in /usr/share/java/log4j-1.2-1.2.17.jar, log4j N/A
@thl-cmk Oh, I missed hash for log4j 1.2.17 version. thank you!
@JStevens1855 Found newrelic.jar from https://download.newrelic.com/newrelic/java-agent/newrelic-agent/current/newrelic.jar and added md5 hash. Would you test v2.9.2 release?
@xeraph works now for me THX!
$ sudo /usr/lib/check_mk_agent/bin/log4j2-scan --scan-logback --scan-log4j1 /usr/share/java/log4j-1.2-1.2.17.jar
Logpresso CVE-2021-44228 Vulnerability Scanner 2.9.2 (2022-02-06)
[?] Found CVE-2021-4104 (log4j 1.2) vulnerability in /usr/share/java/log4j-1.2-1.2.17.jar, log4j 1.2.17
@JStevens1855 Found newrelic.jar from https://download.newrelic.com/newrelic/java-agent/newrelic-agent/current/newrelic.jar and added md5 hash. Would you test v2.9.2 release?
@xeraph Thanks for all of your effort on this one. I am glad you were able to find a current copy of the newrelic.jar, however I re-ran 2.9.2 one one server and it still came back as potentially vulnerable. Unfortunately I don't believe we will get approval to upload the various newrelic.jar files and I believe what we are going to see is that they might not all be the current version and I would imagine different versions would have unique md5 hashes. We currently have 500+ instances of New.relic.jar in various applications. For the time being we will accept them as false positives and work with the application owner to verify remediation and upgrade path. I appreciate your quick response and investigation. I might have to see if I can make an additional step to identify the MD5 hash or checksum of these jar files. There might be a way to match them to a newrelic jar version.
I was hoping you might be able to clarify for me what would make CVE-2021-45105 show potentially vulnerable rather than vulnerable or mitigated if it has Log4 2.16.0? I didn't think there were classes that could be removed to mitigate that CVE.
This came up when inspecting some of the results so I wanted to clarify what cases would fall into that bucket.