As you can see, we raised the INFOCon level to yellow. The main idea behind INFOCon is to protect the Internet infrastructure at large, and the development on automated scripts exploiting key based SSH authentication looks like a real threat to SSH servers around the world (any SSH server using public keys that were generated on a vulnerable Debian machine – meaning – the keys had to be generated on a Debian machine between September 2006 and 13^th of May 2008).

Note: 'Debian' in the above paragraph refers to any Debian-based Linux distribution including Ubuntu.

Scripts that allow brute forcing of vulnerable keys (see this as rainbow tables for SSH keys) are in the wild so we would like to remind all of you to regenerate SSH keys ASAP.

Please keep in mind that SSL certificates should be regenerated as well. This can be even more problematic if you had your certificates signed since you'll have to go through this process again (and possibly pay money again).

Update 2310 UTC: The new Debian package for SSH (ssh_4.3p2-9etch1) also applies a package called  "openssh-blacklist".  After this update, your  SSH server will refuse  keys from the compromised set.  The package also installs a new tool called "ssh-vulnkey" that can help in hunting down key files that contain weak keys.   Note that in combination with the existing ssh-keyscan, ssh-vulnkey can be used to easily identify servers that use weak host keys, so while these Debian patches help those who patch, they also make attacks easier against those who did not yet patch.

More information is available in our previous diaries:

http://isc.sans.org/diary.html?storyid=4420

http://isc.sans.org/diary.html?storyid=4414

Couple of days ago Swa posted a diary about a critical Debian/Ubuntu PRNG security vulnerability.

Today Matt wrote in to let us know that H D Moore posted a web page containing all SSH 1024, 2048 and 4096-bit RSA keys he brute forced.

It is obvious that this is highly critical – if you are running a Debian or Ubuntu system, and you are using keys for SSH authentication (ironically, that's something we've been recommending for a long time), and those keys were generated between September 2006 and May 13th 2008 then you are vulnerable. In other words, those secure systems can be very easily brute forced. What's even worse, H D Moore said that he will soon release  a brute force tool that will allow an attacker easy access to any SSH account that uses public key authentication.

But this is not all – keep in mind that ANY cryptographic material created on vulnerable systems can be compromised. If you generated SSL keys on such Debian or Ubuntu systems, you will have to recreate the certificates and get them signed again. An attacker can even decrypt old SSH sessions now.

The Debian project guys released a tool that can detect weak keys (it is not 100% correct though as the blacklist in the tool can be incomplete). You can download the tool from http://security.debian.org/project/extra/dowkd/dowkd.pl.gz.

 
The bottom line is: this is very, very, very serious and scary. Please check your systems and make sure that you are both patched, and that you regenerated any potentially weak cryptographic material.

UPDATE

There have been some questions if this is related to the increase of SSH attacks we reported about couple of days ago (see http://isc.sans.org/diary.html?storyid=4408). At this point in time we think it is just a coincidence. In any case, you can help us by checking your logs – if the attackers are brute forcing password logins then the attack has nothing to do with this, but if you are seeing key authentication attempts then it is red alert.

The situation with web certificates is even worse – the public key is really that: public. So, for a weak key generated on Debian, an attacker could derive the private key and construct a Man-In-The-Middle attack without any problems in the browser! Very very scary. Makes one wonder how many people used Debian to generate their SSL keys.

As Swa said, there are basically 2 scenarios:

• the public key is known publicly -> no brute force needed, the attackers walk in private key in hand
• the public key isn't found -> brute force of some 260K keys needed.

--

Bojan