« previous 1 2

Tools and lists

If you want to find vulnerable keys, you have a wide range of tools and blacklists to choose from. The only problem is that none of the tools finds all vulnerable keys. Blacklists are currently only available for a select group of key types and lengths – generally those for standard settings. You therefore cannot depend on security blocks based on these approaches. You will need to regularly add updated, extended lists to your scans. Below, we provide a summary of the data available on June 2. We will try to add the latest developments in the next few days, though we cannot provide any guarantees.

The most important test program is the official Debian Perl script to find vulnerable SSH keys – dowkd.pl. It can analyse individual files, search user directories, and inspect SSH servers remotely. It now supports the authorized _keys2 file, though it still has a blind spot: it only takes into account the two default key links, RSA-2048 and DSA-1024.

Fortunately, the script can be extended. A private web site provides additional lists that, once decompressed, can be attached to the script, such as with bzip2 -cd rsa-4096-le.blacklist.bz2 >> dowkd.pl. In addition, line 126 in the Perl script has been changed so that it does not rule out additional bit lengths from the outset. Unfortunately, dowkd.pl cannot be used to test other key types because its blacklists are limited to SSH keys.

Blacklist packages

For Debian-based systems, the packages openssh-blacklist, openvpn-blacklist and openssl-blacklist are available. The packages for openvpn and openssl also contain the test programs openvpn-vulnkey and openssl-vulnkey to check local key data. The test program ssh-vulnkey for SSH keys is part of the current openssh-client package. Apart from the option of testing SSH servers remotely, ssh-vulnkey has basically the same functional scope as dowkd.pl. The openssl-blacklist package is currently only available in the Ubuntu repository. However, Debian admins can take advantage of a specially adapted version.

The blacklists all cover various key types and lengths. For OpenSSL case, there are lists for RSA-1024 and RSA-2048; the list for OpenVPN keys (Preshared Keys) only covers the default format, RSA-2048. SSH blacklists are good for keys in the formats DSA-1024 and RSA-2048. The test tools for OpenSSL and OpenVPN can only check individual local files. Users will have to write scripts that look for vulnerable keys across entire systems themselves.

If you want to improve the detection rate for SSH keys, you can install additional blacklist files – such as for keys with 4096 bits or keys created on Big Endian and 64-bit processors – from an extended openssh-blacklist package. ssh-vulnkey, and hence the SSH server, then also detects the additional variants of keys.

However, the new blacklists still have to be put into the right format. The following commands complete the task:

# cd /etc/ssh
# wget
# http://love.hole.fi/atte/openssh-blacklist/openssh-blacklist_0.3.tar.gz
# tar zxf open*gz cp black* open*/ cd open* cat *DSA-1024* | sed -e
# 's/.*\(....................\)$/\1/g'	\
    | grep -v ^\# | sort -u >../blacklist.DSA-1024
# cat *RSA-1024* | sed -e 's/.*\(....................\)$/\1/g'	\
    | grep -v ^\# | sort -u >../blacklist.RSA-1024
# cat *RSA-2048* | sed -e 's/.*\(....................\)$/\1/g'	\
    | grep -v ^\# | sort -u >../blacklist.RSA-2048
# cat *RSA-4096* | sed -e 's/.*\(....................\)$/\1/g'	\
    | grep -v ^\# | sort -u >../blacklist.RSA-4096

Conclusion

There is really only one piece of advice for conscientious administrators: revoke all certificates created on Debian variants from September 2006 to May 2008 as soon as possible and create new ones. It is hard to say how much time you have to do this. We are currently not aware of any tools for attacks on OpenVPN, IPSec and Co. But you can rest assured of one thing: somebody somewhere is working on them.

In contrast, action must be taken immediately for SSH servers, which are already under attack. Everyone who operates an SSH server and is not completely sure that no one has entered a Debian key should look for and block the keys in the lists currently available.

(cr)

See also:

• DebianWiki on SSLKeys

« previous 1 2