sha256sum hashes about log4j_checker_beta

[rubo77]

It will have no effect on speed, since the hash-file is truncated anyway with | sort | uniq

I will merge the lines anyway ...

[rubo77]

Please check if this is solved

[stefan123t]

Thanks this seems to work for me. I.e. hashes for the complete JAR files of the susceptible 2.x versions are in hashes-pre-cve.txt.
If found the following two lists of hashes on the net:
scstanton: https://github.com/scstanton/log4j-hashes/blob/main/sha256sum.txt
mubex: https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes/blob/main/sha256sums.txt

while mubex has been referenced by lunasec.io's thread on how to detect the original exploit here:

the scstanton also includes sha256 hashes for the 1.x versions too.

Apart from that I do not know if it would be better to check for the actually relevant JndiManager.class which in turn imports the JndiLookup.class. I have seen e.g. log4j-finder to check only for the class inside the JAR file.
@rubo77 I do not know if it would be feasible to generate md5 / sha256 hashes of the JndiManager.class inside the JARs ?

Regarding @whenselm 2. I do not know if this is really necessary. The script itself is executable together with the hashes-pre-cve.txt or whatever other hashes you supply. Though I do like the approach of the log4j-finder to include the hashes within the script itself, either using a here-doc or something similar as a safe default to be overwritten by a hashes file argument.

[stefan123t]

Checked the source code, you can call the script with any of the above URLs as parameter and it will download the hashes via wget / curl.
Now if there would be a third option besides wget & curl, you could call it with a local file instead of a remote URL that would allow to run it without internet connection.

[rubo77]

You could add a pull request, that checks if the local file exists and use it only then

[whenselm]

thanks for providing hashes for the class files itself, I saw the mentioned jar archive's hashes before, did not work for me. 2.It's fine 4 me to download the jar file from a source or local file. Next step I would like to do is to check the files locally and not the production machine by downloading it first via ssh. So I will not have A) the cpu load for hash calculation on a virtual machine and B) circumvent the https/sftp/ pull requests for the machine under test which will be blocked by the firewall. So I do not have to upload anything on remotre machines under test

…

On Mon, Dec 20, 2021 at 8:01 PM Ruben Barkow-Kuder ***@***.***> wrote: Please check if this is solved — Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AW6GTHTICXZS37SWMUERBBLUR54P5ANCNFSM5KF2SWLA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[stefan123t]

I do not understand how you would gain less impact on the VMs you are about to analyse when you A. download the JAR files via a secure/encrypted protocol like ssh which will do its own hashes to do encryption and checksums and B. It is neither mire performant nor less than SFTP and the like. So either you do it remotely with the hashes copied or included or you may need to write a nice rsync script to pull all the relevant JAR files for local analysis.
YMMV

[rubo77]

You could add a pull request, that checks if the local file exists and use it only then

I added a check if the parameter is a URL, if not it uses a local file now. See README.md

[stefan123t]

@rubo77 thanks for the latest addition, you even added some of the JNDIContextSelector.class hashes to the prepackaged hash file. Thanks a lot.
I have one further question which I did not figure out from the code:
Given an EAR file a.ear containing amongst others eg. a WAR file b.war which again contains a JAR file named c.jar which may contain a repackaged / rebundled version of the susceptible JndiLookup/JndiContextSelector.classes will your script recurse into a.ear to unpack b.war and then c.jar to generate the hashes for comparison of the class files ?
Ie. does your script run a recursive, depth-first search to find log4j or the suspected Class files in any packaged EAR/WAR/JAR combination our fellow developers came/come up with when developing and adding dependencies to their application stack of libraries ?
Though should I add a separate issue for such a deep inspection ?

@whenselm Regarding 2. I dunno if this is really feasible or useful doubting the impact of calculating the hashes locally vs. the overhead of transferring the classes and calculate hashes remotely.

[rubo77]

should I add a separate issue for such a deep inspection ?

new issue: #21

The best would be if you would provide a pull request to the issue, because I won't have time for this this this.

[whenselm]

I have one question: Why are the provided hashes for "JNDIContextSelector.class" and not for "JndiLookup.class"?
We got patches for our embedded systems, AFAIK they only removed "JNDILookup.class" from the .jar files (2.0) . But I still get vulnerable results when running the script. In general, this issue can be closed. Performance/CPU load is now ok, when not running in verbose mode

[rubo77]

@gmoniker : maybe you can say something about the hashes?

they were added at 2e55b73

[stefan123t]

@whenselm
I have compared the SHA256 Hashes with those in other tools before and afair they matched the log4j-core-x.jar or the JndiLookup.class file in general, i.e. those lines with the log4j version at the end.
These are both in the scstanton and mubex lists I referenced above.

There is only two hashes for the JNDIContextSelector.class
I believe this is for 1.x and 2.x maybe @gmoniker can comment on my assumption.

[rubo77]

@stefan123t did you notice the commit, where I added two more hashes?

[whenselm]

a lot of (~half )provided hashes are doublettes. Should be concatenated to improve scan speed (add corresponding version on right side rather than one hash per version). I do not know how to comit a change ...
so line 2,4,8,10,16,19,21,22,24,25,27,28,31,31,33,34,35,37,40,41,42,44 are doubletes.
@stefan123t , I see in the mubex list other hashes from the complee libraries, not the classfile itself? Did you generate /compare it?

[rubo77]

Just click the edit button here on GitHub on the top right when you view the hash file.

It leads to a pull request

[whenselm]

I checked now the hashes of my embedded system. The script reports false positives because it checks as mentioned JndiContextSelector.class rather than the JndiLookup.class, which was removed from the embedded system
here version 2.5

for comparison, this is the corect sha-256 hash for version 2.5

[stefan123t]

Dear @whenselm,
No I did not compare it thoroughly enough. Your assumptions are right. I guess though that the JndiContextSelector.class hashes have been added to also catch cases of the ctx: / context vulnerability detected later as CVE-2021-450346 and fixed in IMHO 2.17 or even 2.17.1 respectively.
Therefor you may want to scan also those hashes.

Regarding the duplicate hashes that were seen I agree that they should be merged into one unique line. Is the second column used eg for output ? If yes it should contain a list of the affected version numbers to display.

Kind regards,
Stefan