Attack on old OpenSSL/Debian vulnerability doesn't work on a vulnerable box

Question

DISCLAIMER: The vulnerable box that we are testing on belongs to us, and all the actions are under surveilence, hence we are not doing anything illegal here.

I'm testing a Ubuntu 8.04 box, it's known as having a vulnerability of weak OpenSSL keys. The script provided by Debian confirmed that the server is vulnerable:

$ perl dowkd.pl host X.X.X.X
X.X.X.X: weak key (OpenSSH/dsa/1024)
X.X.X.X: weak key (OpenSSH/rsa/2048)
summary: keys found: 2, weak keys: 2

I then use another script provided by http://itsecurity.net/ called debian_ssh_scan_v4.py to find the fingerprint and corresponding public/private key.

$ python debian_ssh_scan_v4.py X.X.X.X
X.X.X.X:22 sshd fingerprint 4795d53ae413531f78f4d45bbd6eb929 VULNERABLE (RSA 2048 bit key, pid 26571)

$ find rsa/2048/4795d53ae413531f78f4d45bbd6eb929*
rsa/2048/4795d53ae413531f78f4d45bbd6eb929-26571
rsa/2048/4795d53ae413531f78f4d45bbd6eb929-26571.pub

The private key (under rsa/2048) is get from the list of possible keys: http://www.exploit-db.com/sploits/debian_ssh_rsa_2048_x86.tar.bz2

However I was failed to login to the vuln box using that found key (note that ubuntu is a valid user on that box):

$ ssh -i rsa/2048/4795d53ae413531f78f4d45bbd6eb929-26571 -o PasswordAuthentication=no [email protected]
Public key 47:95:d5:3a:e4:13:53:1f:78:f4:d4:5b:bd:6e:b9:29 blacklisted (see ssh-vulnkey(1)); continuing anyway
Permission denied (publickey,password).

I also tried to bruteforce all the possible keys (which I extracted from the compressed file) using WarCat script and none of the key was able to authenticate.

With all those results, could I say that the box is safe, that said it's actually not vulnerable to the weak OpenSSL key bug ?

Answer 1

The "weak key" means that you can have a copy of the server's private key. This allows you to run a fake server and possibly do a Man-in-the-Middle attack on an authorized client, when he connects to the server. However, this does not allow you to log in "by yourself".

When using a public/private key pair with a client, you are sending that public key to the server and the server will authorize entry, or not, depending on whether that public key is in the $HOME/.ssh/authorized_keys of the target account. Here, you are sending as "client's key" a copy of the server's own public key, which is not authorized for client authentication, hence the result.

Not accepting his own key as correct authentication for a client is nothing special in SSH; client keys and server keys live in separate worlds. The server is not aware that you are trying to feed it with its own key; for the server, this is just "a public key which is not in the target authorized_keys file".

The box is still vulnerable; but there are other kinds of vulnerability than allowing connections out of the blue. MitM attacks are harder to put in action (you have to intercept an honest client's connection, usually with some variant on DNS poisoning) but are nonetheless very serious.

Answer 2

Inside /home/ubuntu/.ssh there should be an authorized_keys file that has the public key that is allowed to ssh log in to that account. If that key happens to be one of the weak keys, then you can get the private key that corresponds to it and log in as that user.

For example, see this but don't generate a key. Put a weak public key in authorized_keys, then you can use the corresponding private key to log in.