1 2 next »

A beginner's guide to OpenSSL

Christiane Rütten, Jürgen Schmidt

An overview of risks, tools, and steps

In the wake of the problems Debian has had with OpenSSL, administrators are unaware what to do about the increasing chaos. Some are even panicking. In addition to risky update procedures and tools thrown together overnight that produce unreliable results, administrators are having to deal with incomplete, and sometimes even incorrect, information. Here, heise Security provides you with an overview of the latest findings.

Let's start with the potential risks. All systems using keys that OpenSSL can create are affected regardless of the operating system. In particular, SSH, OpenVPN, IPsec, mail and web servers with SSL (https) and DNS servers with DNSSEC/DK are vulnerable. Although only Debian derivatives create unsafe keys, systems sold by other vendors are also vulnerable if a Debian user releases a key from his Debian system for a login. For instance, if a vulnerable key is listed on a Suse Linux server in the file ~/.ssh/authorized_keys, the Suse admin will have a problem.

SSH

SSH servers are particularly vulnerable at present. HD Moore used a few tricks to generate all vulnerable SSH keys and has made them available for downloading. These keys can be used in brute force attacks on SSH access – such attacks may already be happening. Fortunately, these attacks are quite complicated to carry out. While such tools as openssl-vulnkey will find a server with a vulnerable host key, that does not mean that you can log onto the system. It only means that attackers can decode any encrypted network traffic they can sniff. And they can do so at their leisure.

To get proper access to an SSH server, attackers have to try to log in as root via public-key authentication. If the admin has released an unsafe key, it must be found by trial and error. Attackers will then generally have to test several thousand keys, but they can realistically expect to succeed in a fairly short time.

Therefore, every administrator of an SSH server – regardless of the operating system used – should use the tool dowkd.pl via

# perl dowkd.pl user

to see whether any users have released a vulnerable key. If so, that key should be blocked just to be on the safe side. Unfortunately, finding nothing doesn't mean you are safe. The current lists of critical keys are anything but exhaustive, and the tool has a least one blind spot (see the overview of tools).

If you operate a Debian server, you will want to install the latest update via

aptitude update
aptitude dist-upgrade

to make sure that you have all the packages you need. Merely updating openssl is not sufficient. The update also seals off your server by blocking login using vulnerable keys on a blacklist. The SSH server then logs failed login attempts in /var/log/auth.log:

sshd[26085]: Public key a3:80:be:45:83:71:38:dd:7f:06:77:70:c9:83:29:7a blacklisted (see ssh-vulnkey(1))

But be careful – if you set up your system so that you can only log in with one of these keys, you may have just locked yourself out during this update. You will want to review your keys beforehand in case you need to change some.

Other services

The danger is not as great with other services that use SSL certificates or keys. At least no collection of keys has been published yet. On the other hand, it is often very difficult, if not completely impossible, to localise vulnerable certificates and block them individually. For instance, Ubuntu provides openvpn-vulnkey in the openvpn-blacklist package, but the tool can only test static pre-shared keys. What's worse, it doesn't even test to see whether it is looking at one. If it has an RSA key from an X.509 certificate, for example, it simply gives the green light:

$ openvpn-vulnkey ju-key.pem
Not blacklisted: 82857...  ju-key.pem

In contrast, the openssl-vulnkey tool can test X.509 certificates and their keys. But first, the (RSA) key has to be available as a PEM file, and you have to have the password to open it. And even then, the current lists only contain 1024- and 2048-bit keys. Yet the PKI tool TinyCA creates 4096-bit keys by default. While these keys are also vulnerable if the critical OpenSSL library from Debian's package is used, no such vulnerable keys have yet been found.

1 2 next »