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

update ssh2john to support all algs from openssh #5430

Open
noraj opened this issue Jan 25, 2024 · 3 comments
Open

update ssh2john to support all algs from openssh #5430

noraj opened this issue Jan 25, 2024 · 3 comments

Comments

@noraj
Copy link

noraj commented Jan 25, 2024

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

john/run/ssh2john.py

Lines 41 to 45 in 173b562

'AES-128-CBC': {'cipher': AES, 'keysize': 16, 'blocksize': 16, 'mode': "AES.MODE_CBC"},
'DES-EDE3-CBC': {'cipher': DES3, 'keysize': 24, 'blocksize': 8, 'mode': "DES3.MODE_CBC"},
'AES-256-CBC': {'cipher': AES_256, 'keysize': 32, 'blocksize': 16, 'mode': "AES.MODE_CBC"},
'AES-192-CBC': {'cipher': AES, 'keysize': 24, 'blocksize': 16, 'mode': "AES.MODE_CBC"},
'AES-256-CTR': {'cipher': AES_256, 'keysize': 32, 'blocksize': 16, 'mode': "AES.MODE_CTR"},

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" "[email protected]" "aes192-cbc" "aes192-ctr" "aes256-cbc" "aes256-ctr" "[email protected]" "[email protected]")
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

john/src/ssh_fmt_plug.c

Lines 375 to 384 in 173b562

} else if (cur_salt->cipher == 3) { // EC keys with AES-128
unsigned char key[16];
AES_KEY akey;
unsigned char iv[16];
memcpy(iv, cur_salt->salt, 16);
generate_key_bytes(16, (unsigned char*)password, key);
AES_set_decrypt_key(key, 128, &akey);
// full decrypt
AES_cbc_encrypt(cur_salt->ct, out, cur_salt->ctl, &akey, iv, AES_DECRYPT);

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

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

noraj commented Jan 25, 2024

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants