ARN

How to avoid the Debian SSH key attacks

It only took two days, but viable, simple attacks against the weak Debian SSH key generation flaw have surfaced

If you are running a Debian-based Linux system and haven't already caught up with the announcement that there was a major flaw with the generation of SSH, OpenVPN, DNSSEC, SSL/TLS session keys and X.509 certificate key material, you might want to update your system to address the problem.

This doesn't just affect Debian, but Debian derivatives as well, such as Ubuntu.

The flaw was the removal of most of the entropy (randomness) from the key generation process in OpenSSL in September 2006, and wasn't picked up on until just last week.

This means that any keys you have generated since that time should be regenerated as the only entropy present was the pid (Process ID) of the currently running process that generated the key.

This means that there are only 32,767 possible keys for each key length and there are a number of resources starting to appear that are targeting the weak key issue. One of the tools, developed by Markus Mueller, claims to defeat a 2048 bit RSA SSH key in less than 20 minutes.

H D Moore, the founder of Metasploit, points out that there are several features of Debian that make the process of brute forcing a key even simpler, given that a lot of Debian systems use sequential pid allocation and most keys are likely to have been user generated with a pid between 500 and 10,000 (which effectively reduces the keyspace to 9,500 keys).

Systems being developed at the moment are focussing on brute forcing the weakened keys and are being released as people finish creating the complete set of each key length.

If you thought you were safe by using a key length of more than 2048 bits, that isn't the case, as tables of 8192 bit RSA SSH keys have begun to appear (as well as lengths below that).

Keys created with GnuPG or GNUTLS are reported as not being affected by this issue. If you are not in the position to update your system (which you should really be doing), you should look at limiting the number of SSH login attempts to less than one per minute.

SSH brute forcing login attempts (using a set of assumed weak keys) have been a problem plaguing most systems with an exposed SSH port for a long time. Now that attackers have ready access to the complete keyspace for affected Debian systems it is guaranteed that they will gain SSH access if there is nothing set up to limit login attempts.

Some of the best means to limit login attempts include limiting the number of attempts per minute from all sources, blacklisting IPs that fail 2 or more login attempts, or only permitting whitelisted IPs to attempt SSH login (and trusting that those IPs are not compromised themselves).

While these measures will not prevent a successful brute force attack from working, it will mean that a successful attack won't take 20 minutes, it may take many hours or days to succeed.

Page Break

All SSH servers could be affected

There are several ways in which the weak entropy can show itself. One that is causing significant concern from a security point of view is that if a key is generated on a system while it was affected, it will remain weak even after the security fixes have been applied.

People also tend to spread keys around across systems they have access to. This means that if a user creates a key and then installs it on a remote machine, that user's account on that machine is now vulnerable in the same way.

Debian and Ubuntu have now released a blacklist of affected keys which are not allowed to login, and this blacklist is used on up to date Debian and Ubuntu machines. Other systems, such as SUSE, currently do not have a blacklist.

If administrators want to check for weak keys on their system, there is now a script that lets you quickly verify whether some of your keys are vulnerable on the Debian advisory.