Confirmed: Nasty Heartbleed bug exposes OpenVPN private keys, too

Private encryption keys have been successfully extracted multiple times from a virtual private network server running the widely used OpenVPN application with a vulnerable version of OpenSSL, adding yet more urgency to the call for operators to fully protect their systems against the catastrophic Heartbleed bug.

Developers who maintain the open source OpenVPN package previously warned that private keys underpinning VPN sessions were vulnerable to Heartbleed. But until Wednesday, there was no public confirmation such a devastating theft was feasible in real-world settings, said Fredrik Strömberg, the operator of a Sweden-based VPN service who carried out the attacks on a test server. An attacker carrying out a malicious attack could use the same exploit to impersonate a target's VPN server and, in some cases, decrypt traffic passing between an end user and the real VPN server.

Wednesday's confirmation means any OpenVPN server—and likely servers using any other VPN application that may rely on OpenSSL—should follow the multistep path for recovering from Heartbleed, which is among the most serious bugs ever to hit the Internet. The first step is to update the OpenSSL library to the latest version. That step is crucial but by no means sufficient. Because Heartbleed may have leaked the private key that undergirds all VPN sessions, updated users may still be susceptible to attacks by anyone who may have exploited the vulnerability and made off with the key. To fully recover from Heartbleed, administrators should also revoke their old key certificates, ensure all end user applications are updated with a current certificate revocation list, and reissue new keys.

To fully recreate a private key, Strömberg had to use the exploit code to query the vulnerable server over and over and collect an extremely large amount of leaked memory data that he declined to specify, except to say it was more than one gigabyte and less than 10 gigabytes. He was then able to comb through the data and reconstruct the key. In his Hacker News post, Strömberg, who is co-founder of a consumer VPN service called Mullvad, added:

Our exploit is decently weaponized, and while the code is an abomination that even Eris would be embarrassed to present, we believe it may severely impact those who have not already upgraded. Therefore, we will not be publishing the code. Nevertheless, you should assume that other teams with more nefarious purposes have already created weaponized exploits for OpenVPN. Just to be clear, we don't intend to use this exploit ourselves. We merely developed it to examine the practical impact on OpenVPN as part of our incident investigation.

The test server was running Ubuntu 12.04 that was virtualized using the KVM application, OpenVPN 2.2.1, and OpenSSL 1.0.1-4ubuntu5.11. He said he suspects just about any version of OpenVPN that relies on a vulnerable version of OpenSSL is similarly susceptible.

One bright spot for some smaller organizations using OpenVPN is that the exploit won't work against systems that have TLS authentication enabled as long as all the end users connecting are trusted. That's because TLS authentication uses a separate private key to encrypt and authenticate the TLS traffic. He said the authentication is less of a protection on services with large numbers of users since each one has access to the private key used in the separate authentication step. Strömberg also reiterated assurances provided last week by OpenVPN officials that the risk to users of the OpenVPN Connect Clients is minimal.