Ten days ago, a Debian Security Advisory (DSA-1571-1) was released that detailed a flaw in the OpenSSL cryptographic libraries that affects both Debian and other Linux distributions derived from Debian.
Unlike a buffer overflow or many other vulnerabilities, this flaw wasnt introduced through insecure programming -- quite the opposite. In fact, the programmer was using Valgrind to debug applications in an effort to prevent security flaws. But two lines of code from the OpenSSL libraries caused Valgrind to complain, which prompted the programmer to take them out after an inquiry and short discussion on the OpenSSL development mailing list.
The removal of those two lines of code resulted in two years' worth of weakened cryptographic key creation (both SSH keys sand SSL certificates) on Debian-based systems. It reduced the amount of entropy, or randomness, introduced in the key generation process. This limited the number of keys that could be generated to 32,767 key pairs per key size, type, and architecture.
In other words, all 32,767 cryptographic keys could now be generated ahead of time, enabling an attacker to quickly use brute force access to penetrate an SSH server or decrypt SSL-protected Web transactions. All communications that had been perceived as "secure" for the past two years -- and into the unforeseeable future -- could now be compromised if their encryption was based on the flawed keys and certificates.
Within a day of the Debian security advisory, HD Moore of the Metasploit Project generated several full sets of vulnerable public and private key pairs, as well as tools to create the keys. He also offered links to several tools that could use his keys to detect vulnerable systems and access them via brute force. (See Debian OpenSSL Predictable PRNG Toys.)
Depending on how you view HDs work, it can be either good or evil. But after monitoring mailing lists over the last week, I believe his efforts have greatly assisted many organizations in finding vulnerable systems on their networks.
The Debian team has an excellent wiki page about the vulnerability which lists 31 different applications affected, but that list really only scratches the surface. Unfortunately, we will never know the true impact and reach of this vulnerability because of the large number of Linux distributions derived from Debian.
The keys and certificates generated on the affected systems also have the ability to proliferate into other operating systems -- including Windows -- as well as a multitude of cross-platform applications and even network devices that can use SSH keys and SSL certificates.
Upon close examination, the vulnerability actually has potential to help both attackers and IT security professionals. Organizations using network forensic solutions that capture all traffic on their network now can go back and decrypt any of the traffic that was secured by vulnerable keys.
On the other hand, attackers could do the same thing. Users whove set up their accounts to use a public and private key for authentication to a SSH server may now be at greater risk of brute force attacks than those who use a simple secure password, because there is a finite number of possible SSL keys that can be used to login.
The Debian and Ubuntu security folks reacted very quickly to the flaw, creating fixes and tools to help secure systems and find vulnerable keys. When Debian systems are updated to the current patch level the fixed OpenSSL and related packages are installed, and OpenSSH is forced to create new a new keypair. Additionally, blacklists are installed that prevent OpenSSH from accepting insecure keypairs.
In addition, Hubert Seiwert has created a very fast scanner for checking remote host SSH keys that works well for detecting vulnerable servers. However, user keys also need to be checked, whether theyre stored on a Debian-based system or not.
While the Debian team has produced the dowkd.pl tool for finding vulnerable user and host keys, Ive had more reliable results from Ubuntus ssh-vulnkey and openssl-vulnkey tools. Dowkd.pl may be more cross-platform compatible, since it's written in Perl, but the Ubuntu tools offer some clear advantages.
For example, user keys can be checked using Ubuntus ssh-vulnkey. Such checks should be run by all systems administrators who have users that use SSH keys, since those keys could have been created on a vulnerable system and copied over. SSL certificates used for services such as Apache and OpenVPN can also be checked with openssl-vulnkey.
In the end, all vulnerable keys need to be deleted, and new ones must be generated to replace them. If you don't go through this process attackers can access SSH servers using vulnerable keys, and man-in-the-middle attacks can take place against traffic that is thought to be secure.
The greatest irony? All of these problems were caused by an attempt to make the software more secure two years ago.
Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.