search

HynekPetrak / log4shell-finder

Fastest filesystem scanner for log4shell (CVE-2021-44228, CVE-2021-45046) and other vulnerable (CVE-2017-5645, CVE-2019-17571, CVE-2022-23305, CVE-2022-23307 ... ) instances of log4j library. Excellent performance and low memory footprint.
38 stars 14 forks source link

Please add support 3 CVE (log4j) #10

Open trust1345 opened 2 years ago

trust1345 commented 2 years ago
  1. CVE-2017-5645
  2. CVE-2021-42550
  3. CVE-2020-9488

It is especially important to detect CVE-2021-42550

Maybe in the documentation (readme) such a table will be useful

Detect CVE CVSSv3 Severity java lib from lib to lib fix
x CVE-2021-44228 10,0 Critical 8 2.0-beta9 2.14.1 2.15.0
- CVE-2017-5645 9,8 Critical 7 2.0-alpha1 2.8.1 2.8.2
x CVE-2021-45046 9,0 Critical 7/8 2.0-beta9 2.15.0 excluding 2.12.2 2.12.2/2.16.0
x CVE-2021-4104 7,5 High - 1.0 1.x nofix
x CVE-2021-44832 6,6 Medium 6/7/8 2.0-alpha7 2.17.0, excluding 2.3.2/2.12.4 2.3.2/2.12.4/2.17.1
- CVE-2021-42550 6,6 Medium - 1.0 1.2.7 1.2.8
x CVE-2021-45105 5,9 Medium 6/7/8 2.0-beta9 2.16.0, excluding 2.12.3 2.3.1/2.12.3/2.17.0
- CVE-2020-9488 3,7 Low 7/8 2.0-alpha1 2.13.1 2.12.3/2.13.2
HynekPetrak commented 2 years ago

@trust1345 CVE-2021-42550 is logback, not log4j vulnerability.

trust1345 commented 2 years ago

Yes, this is understandable, but I think that the scanner has almost everything ready to implement the search for this CVE. The actions to find this vulnerability are similar.Why not?

HynekPetrak commented 2 years ago

logback have different version numbers, different folder structure. I will check that later

HynekPetrak commented 2 years ago

@trust1345 added detection of CVE-2017-5645. It was rather complicated and may have broken detection of other vulnerabilities, please test carefully.

trust1345 commented 2 years ago

Hi @HynekPetrak version https://github.com/HynekPetrak/log4shell-finder/tree/95a52803f3cca82803e10600ef56a2f845abb209 falls into traceback with the all argument error_1.2120220118.txt In attached file first run with directory argument (successful launch), second with all argument drop into traceback.

Run task with samples these https://github.com/mergebase/log4j-samples

HynekPetrak commented 2 years ago

Fixed, please check

trust1345 commented 2 years ago

Thanks, I'm still checking out different options.

trust1345 commented 2 years ago

Tried to bring the table up to date. Last update 2022.12.25

log4J 2.x

detect CVE CVSSv3 Severity lib from lib to lib fix comment
x CVE-2021-44228 10,0 Critical 2.0-beta9 2.14.1 2.15.0
x CVE-2017-5645 9,8 Critical 2.0-alpha1 2.8.1 2.8.2
x CVE-2021-45046 9,0 Critical 2.0-beta9 2.15.0 excluding 2.12.2 2.12.2/2.16.0
x CVE-2021-44832 6,6 Medium 2.0-alpha7 2.17.0, excluding 2.3.2/2.12.4 2.3.2/2.12.4/2.17.1
x CVE-2021-45105 5,9 Medium 2.0-beta9 2.16.0, excluding 2.12.3 2.3.1/2.12.3/2.17.0
- CVE-2020-9488 3,7 Low 2.0 2.13.1/2.12.1/2.3.1 2.13.2/2.12.3/2.3.2

log4J 1.x

detect CVE CVSSv3 Severity lib from lib to lib fix comment
x CVE-2019-17571 9,8 Critical 1.2.0 1.2.17 nofix
x CVE-2021-4104 7,5 High 1.2.0 1.2.17 nofix
x CVE-2022-23302 8,8 High 1.0.1 1.2.17 nofix
x CVE-2022-23305 9,8 Critical 1.2.0 1.2.17 nofix
x CVE-2022-23307 9,8 Critical 1.0 1.2.17 nofix same as CVE-2020-9493
- CVE-2020-9488 3,7 Low 1.2.0 1.2.17 nofix

reload4j

Fork log4J 1.x reload4j (2022-01-12 - first release reload 4 about project 1.2.18.0 ) with the elimination of security vulnerabilities, released as a new version in the log4j 1 branch.x while maintaining backward compatibility (not considering hardening)

detect CVE CVSSv3 Severity lib from lib to lib fix comment
x CVE-2019-17571 9,8 Critical none none 1.2.18.0
x CVE-2021-4104 7,5 High none none 1.2.18.0 (JMSAppender) fixed by hardening the components
x CVE-2022-23302 8,8 High 1.2.18.0 1.2.18.0 1.2.18.1 (JMSSink) - fixed by hardening the component
x CVE-2022-23305 9,8 Critical 1.2.18.0 1.2.18.1 1.2.18.1 (JDBCAppender) - fixed by using JDBC PreparedStatement which are invulnerable to SQL injection
x CVE-2022-23307 9,8 Critical 1.2.18.0 1.2.18.0 1.2.18.1 same as CVE-2020-9493, (Chainsaw) - fixed by hardening the component
- CVE-2020-9488 3,7 Low 1.2.18.0 1.2.18.2 1.2.18.3

Other CVEs

Other CVEs require the same approach (search and parse) as log4j just contained in other products.

detect CVE CVSSv3 Severity product name lib from lib to lib fix comment
- CVE-2020-9493 9,8 Critical Apache Chainsaw 2.0 2.1.0 2.1.0 this vulnerability does not apply to log4j, it is a Apache chainsaw vulnerability
- CVE-2021-42550 6,6 Medium logback 1.0 1.2.9 1.2.10 this vulnerability does not apply to log4j, it is a logback vulnerability
HynekPetrak commented 2 years ago

added support for CVE-2019-17571 (9.8)

HynekPetrak commented 2 years ago

note CVE-2017-5645 is already supported.

HynekPetrak commented 2 years ago

added support for CVE-2022-23307 (8.1)

trust1345 commented 2 years ago

logback have different version numbers, different folder structure. I will check that later

Maybe this will help https://github.com/logpresso/CVE-2021-44228-Scanner/commit/79ab0e5e0eaf04fd37888feabf610cb07060240a

trust1345 commented 2 years ago

In all cases that I have been able to check, the latest version works well. I think we need to make a release.

PS. Updated the information in the table above

trust1345 commented 2 years ago

Fix CVE-2020-9488 place in the table (move to log4j 2.x).

HynekPetrak commented 2 years ago

added detection of CVE-2022-23305 (8.1)

HynekPetrak commented 2 years ago

With release I would rather wait for me fixing the false positives on reload4j:

[+] [CVE-2019-17571 (9.8), CVE-2021-4104 (7.5), CVE-2022-23307 (8.1)] Package /home/hynek/war.bak/reload4j/reload4j-1.2.18.1.jar contains Log4J-None <= 1.2.17 [+] [CVE-2019-17571 (9.8), CVE-2021-4104 (7.5), CVE-2022-23305 (8.1), CVE-2022-23307 (8.1)] Package /home/hynek/war.bak/reload4j/reload4j-1.2.18.0.jar contains Log4J-1.2.18.0 <= 1.2.17

HynekPetrak commented 2 years ago

added detection of CVE-2022-23305, CVE-2022-23302 and proper handling of reload4j.

Detection of CVE-2022-23307 is equivalent to CVE-2020-9493

@trust1345 test on your dataset, please. I'm ready to make a release.\

My test case:

[-] [OLDSAFE]  Package /home/hynek/war.bak/reload4j/reload4j-1.2.18.2.jar contains reload4j-1.2.18.2
[-] [OLDSAFE]  Package /home/hynek/war.bak/reload4j/reload4j-1.2.18.1.jar contains reload4j-1.2.18.1
[+] [CVE-2019-17571 (9.8), CVE-2021-4104 (7.5), CVE-2022-23302 (6.6), CVE-2022-23305 (8.1), CVE-2022-23307 (8.1)]  Package /home/hynek/war.bak/reload4j/log4j-1.2.17.jar contains log4j-1.2.17
[+] [CVE-2022-23302 (6.6), CVE-2022-23305 (8.1), CVE-2022-23307 (8.1)]  Package /home/hynek/war.bak/reload4j/reload4j-1.2.18.0.jar contains log4j-1.2.18.0
[+] [CVE-2022-23302 (6.6), CVE-2022-23305 (8.1), CVE-2022-23307 (8.1)]  Folder /home/hynek/war.bak/reload4j/reload4j-1.2.18.0/org/apache/log4j contains log4j-1.2.18.0
[-] [OLDSAFE]  Folder /home/hynek/war.bak/reload4j/reload4j-1.2.18.2/org/apache/log4j contains reload4j-1.2.18.2
[-] [OLDSAFE]  Folder /home/hynek/war.bak/reload4j/reload4j-1.2.18.1/org/apache/log4j contains reload4j-1.2.18.1
trust1345 commented 2 years ago

[-] [OLDSAFE] Package /home/hynek/war.bak/reload4j/reload4j-1.2.18.2.jar contains reload4j-1.2.18.2 [-] [OLDSAFE] Package /home/hynek/war.bak/reload4j/reload4j-1.2.18.1.jar contains reload4j-1.2.18.1

https://reload4j.qos.ch/ Снимок экрана от 2022-01-24 16-51-11

2021-01-21 - Release of reload4j 1.2.18.2 • CVE-2022-23305 (JDBCAppender) - fixed by using JDBC PreparedStatement which are invulnerable to SQL injection. Thanks to the remarkable work of Vladimir Sitnikov JDBCAppender now interprets the SQL expression on the fly so as to insert new events using PreparedStartement instances. Note that the table column types are restricted to those types compatible with Java's String.

PS. Updated the information in the table above. I tried not to forget anything. Maybe I missed something.

trust1345 commented 2 years ago

@trust1345 test on your dataset, please. I'm ready to make a release.\

Checked the latest version from git, something went wrong I think.

sample2.zip

1 2 3 4 5
CVE-2021-44832 (6.6), CVE-2021-45105 (5.9), NOJNDILOOKUP /opt/virtual/download/log4j/sample/add/fp/log4j-core-2.17.1.jar contains log4j-core-2.17.1 == 2.16.0, JndiLookup.class not found 2.17.1 log4j-core
OLDSAFE /opt/virtual/download/log4j/sample/add/com.oracle.ocm_1.0.0.0.jar contains Oracle OCM 1.0 Fri Feb 20 19:26:55 EST 2009-1.0.0.0 1.0.0.0 Oracle OCM 1.0 Fri Feb 20 19:26:55 EST 2009
OLDSAFE /opt/virtual/download/log4j/sample/add/emocmutl.jar contains log4j-1.x 1.x log4j
OLDSAFE /opt/virtual/download/log4j/sample/add/log4j-boot.jar contains JBoss [Trinity]-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=20 4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=20 JBoss [Trinity]
CVE-2021-44832 (6.6), CVE-2021-45105 (5.9), NOJNDILOOKUP /opt/virtual/download/log4j/sample/add/fp/elasticsearch-sql-cli-6.8.23.jar contains log4j-core-2.17.1 == 2.16.0, JndiLookup.class not found 2.17.1 log4j-core
HynekPetrak commented 2 years ago

2021-01-21 - Release of reload4j 1.2.18.2 • CVE-2022-23305 (JDBCAppender) - fixed by using JDBC PreparedStatement which are invulnerable to SQL injection. Thanks to the remarkable work of Vladimir Sitnikov JDBCAppender now interprets the SQL expression on the fly so as to insert new events using PreparedStartement instances. Note that the table column types are restricted to those types compatible with Java's String.

They actually fixed the CVE-2022-23305 already in 1.2.18.1 by removing the JDBCAppender completely. In version 1.2.18.2 they brought it back hardened. So they way I'm reporting it, I believe, is correct.

HynekPetrak commented 2 years ago

@trust1345 I've possibly reworked the detection logic, still need to test before release. Please test on your side, if possible.

trust1345 commented 2 years ago

They actually fixed the CVE-2022-23305 already in 1.2.18.1 by removing the JDBCAppender completely. In version 1.2.18.2 they brought it back hardened. So they way I'm reporting it, I believe, is correct.

OK, I agree

trust1345 commented 2 years ago

Updated the table according to 2021-01-24 - Release of reload4j 1.2.18.3 add CVE-2020-9488 to log4j 1.x and reload4j

trust1345 commented 2 years ago

@trust1345 I've possibly reworked the detection logic, still need to test before release. Please test on your side, if possible.

I doubt that

(log4j-1.x) From my previous comment ( https://github.com/HynekPetrak/log4shell-finder/files/7926399/sample2.zip ) do not contain CVE from the table. It seems illogical that they have the status of OLDSAFE.

HynekPetrak commented 2 years ago

Why illogical? OLDSAFE is meant for log4j 1.x with no CVE. By definition

trust1345 commented 2 years ago

Why illogical? OLDSAFE is meant for log4j 1.x with no CVE. By definition

For example, it says here (CVE-2022-23302) https://lists.apache.org/thread/bsr3l5qz4g0myrjhy9h67bcxodpkwj4w

Description: JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to. The attacker can provide a TopicConnectionFactoryBindingName configuration causing JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104.

I think that just no one wants to dig into the old code to find out the details. As for example with CVE-2020-9488, which did not appear in log4j 1.x until reload4j began to touch the code

But at the moment I have not found such information in the descriptions on reliable sources. Perhaps you should leave it like this, waiting until the analysis from nist is over

HynekPetrak commented 2 years ago

CVE-2021-4104 is a bug of JMSAppender class - in your example there is no JMSAppender, so it's not vulnerable to CVE-2021-4104. For every CVE I'm trying to identify the vulnerable piece of code and the patch applied in order to empirically check, whether that particular instance of log4j is vulnerable or not.

trust1345 commented 2 years ago

In all cases that I have been able to check, the latest version works well. I think need to make a release.

trust1345 commented 2 years ago

Updated the table (nvd.nist.gov) CVSS CVE-2022-23302 CVSS 6,6 -> CVSS 8,8 CVSS CVE-2022-23305 CVSS 8,1 -> CVSS 9,8 CVSS CVE-2022-23307 CVSS 8,1 -> CVSS 9,8