Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sha256sum hashes #8

Open
whenselm opened this issue Dec 16, 2021 · 18 comments
Open

sha256sum hashes #8

whenselm opened this issue Dec 16, 2021 · 18 comments

Comments

@whenselm
Copy link
Contributor

Nice work, but I am missing vulnerable JndiLookup.class sha256sum hashes. Can anybody checkin to this project? Did not find anything on the net (there are hashes for log4j-core-xx.jar files, however available from the Apache repository), but it is pointless here to test on a .class level

2.You might not want to execute the hashing on the production machine /VM (cpu load), so I suggest to add some possibilties to check on a local machine and access the webserver only via ssh and pulling the .jar files to test. This might also circumvent where the webserver is blocked by a firewall for outgoing requests (either wget or curl).

@rubo77
Copy link
Owner

rubo77 commented Dec 20, 2021

Please check if this is solved

@stefan123t
Copy link

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
Copy link

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
Copy link
Owner

rubo77 commented Dec 21, 2021

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

@whenselm
Copy link
Contributor Author

whenselm commented Dec 26, 2021 via email

@stefan123t
Copy link

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
Copy link
Owner

rubo77 commented Dec 29, 2021

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
Copy link

@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
Copy link
Owner

rubo77 commented Dec 29, 2021

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
Copy link
Contributor Author

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
Copy link
Owner

rubo77 commented Jan 12, 2022

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

they were added at 2e55b73

@stefan123t
Copy link

stefan123t commented Jan 12, 2022

@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
Copy link
Owner

rubo77 commented Jan 12, 2022

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

@whenselm
Copy link
Contributor Author

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
Copy link
Owner

rubo77 commented Jan 13, 2022

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
Copy link
Contributor Author

whenselm commented Jan 13, 2022

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
grafik
for comparison, this is the corect sha-256 hash for version 2.5
grafik

@stefan123t
Copy link

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

@rubo77
Copy link
Owner

rubo77 commented Jan 14, 2022

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

I will merge the lines anyway ...

rubo77 added a commit that referenced this issue Jan 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants