openwall / john

John the Ripper jumbo - advanced offline password cracker, which supports hundreds of hash and cipher types, and runs on many operating systems, CPUs, GPUs, and even some FPGAs
https://www.openwall.com/john/
Other
10.36k stars 2.11k forks source link

update ssh2john to support all algs from openssh #5430

Open noraj opened 10 months ago

noraj commented 10 months ago

It's not about John itself but one of the companion tool provided with it: ssh2john.

https://github.com/openwall/john/blob/bleeding-jumbo/run/ssh2john.py

ssh2john supports a very limited set of algorithms

https://github.com/openwall/john/blob/173b5629e8dd6873819a94e2d3b3509ceffdfa38/run/ssh2john.py#L41-L45

Whereas most of the algs supported by openssh are not supported by ssh2john.

The following script can be used to generate a key for each alg and try to ssh2john it for each. You'll see a lot are not supported even if they are supported by John.

algs=("3des-cbc" "aes128-cbc" "aes128-ctr" "aes128-gcm@openssh.com" "aes192-cbc" "aes192-ctr" "aes256-cbc" "aes256-ctr" "aes256-gcm@openssh.com" "chacha20-poly1305@openssh.com")
for alg in "${algs[@]}"
do
    ssh-keygen -o -N test12345 -t ed25519 -Z $alg -f test_$alg 1>/dev/null
    ssh2john test_$alg > hash_$alg.txt
done

For example, EC with AES 128 looks supported but John but not by ssh2john

https://github.com/openwall/john/blob/173b5629e8dd6873819a94e2d3b3509ceffdfa38/src/ssh_fmt_plug.c#L375-L384

➜ ssh-keygen -o -N test12345 -t ecdsa -Z aes128-cbc -f test_ec+128
Generating public/private ecdsa key pair.
Your identification has been saved in test_ec+128
Your public key has been saved in test_ec+128.pub
The key fingerprint is:
SHA256:XIRSO83q23eYVERJDn7lBJ74bRm4tVWVw8LJcKL53lA noraj@norarch
The key's randomart image is:
+---[ECDSA 256]---+
|       ....o=+*oB|
|      . .=o.oX+O.|
|       .oo+ oE*o+|
|       . +. .o+.=|
|        S  o o.oo|
|       .  . +  . |
|        .  o +   |
|         o  + .  |
|        . .. .   |
+----[SHA256]-----+

➜ ssh2john test_ec+128
Traceback (most recent call last):
  File "/usr/bin/ssh2john", line 225, in <module>
    read_private_key(filename)
  File "/usr/bin/ssh2john", line 157, in read_private_key
    raise Exception('Unknown encryption type')
Exception: Unknown encryption type

ssh2hon from John the Ripper 1.9.0-jumbo-1+bleeding-173b5629e8 2024-01-18 00:08:42 +0100 MPI + OMP [linux-gnu 64-bit x86_64 AVX AC]

solardiz commented 10 months ago

Thank you @noraj! Is this something you'd like to work on? We'd appreciate a pull request. (Assuming that your analysis here is correct. I did not verify.)

noraj commented 10 months ago

@solardiz What would you expect? ssh2john supporting all possibilities supported by john only or all possibilities supported by ssh-keygen?

Also, in the light of #4564 and #5255 and many others, wouldn't it be good to separate all the tools from /run in a different repository? It would allow faster release for those tools than JtR slow lifecycle. Also both code are completely independent.

I don't think I'm able to PR, I dont't understand what combination of key size, key type, encryption type, etc. would lead to a hash type and why. Having blocksize in the dict seems useless. It sounds like a partial re-write of the tool would be beneficial. I'm also extremely bad at C so it's hard for me to understand what exactly john is supporting.

solardiz commented 10 months ago

What would you expect? ssh2john supporting all possibilities supported by john only or all possibilities supported by ssh-keygen?

Perhaps first make ssh2john support everything in john. As to the rest, it can also be added - with a separate commit/PR, and perhaps printing a warning that it "may not yet be supported by john" or such.

wouldn't it be good to separate all the tools from /run in a different repository?

This was suggested and I thought of it, and my current opinion is that no - it's better to keep them in here. We do need to release more often and to clean things up, but a separate repo and having to make separate releases isn't the way there.

It sounds like a partial re-write of the tool would be beneficial.

I agree. Perhaps we could get rid of our own numeric cipher types and include the info in "hashes" with less re-processing. However, I have no idea who would do that and when. So adding support for what's missing first is reasonable.