Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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 ubuntu@X.X.X.X
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 ?

share|improve this question
    
Are you sure about the username ubuntu ? –  user2790452 Jan 20 at 11:18
1  
Has the Ubuntu user authorized that key for login? –  mikeazo Jan 20 at 12:50
1  
@close votes: "Opinion based" - Surely not? Any incorrect answers may be opinion based as people attempt to try and solve the issue, but there will be a correct answer somewhere –  figlesquidge Jan 20 at 13:44
    
@user2790452: yes, there's username ubuntu –  Huy Phan Jan 20 at 14:24
    
I think your question is better off on IT Security. I'll migrate it there. –  mikeazo Jan 20 at 19:46
add comment

migrated from crypto.stackexchange.com Jan 20 at 19:47

This question came from our site for software developers, mathematicians and others interested in cryptography.

2 Answers

up vote 2 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.