Recovering your VPS from the OpenSSL Heartbleed vulnerability

There are a lot of great resources out there with regard to the Heartbleed (CVE-2014-0160) vulnerability, but let’s look at what this means specifically for anyone who operates their own VPS.

We’ll determine whether this bug directly applies to you, if you are affected, how to recover from the vulnerability, and what to do after the vulnerability has been patched.

Does it apply to you?

First, you have to check whether this applies to you. You will most likely be affected by this vulnerability if you:

1. Run a Linux server like Red Hat or CentOS.
2. Use the server as a web server running something like Apache or Nginx.
3. Have an SSL certificate installed (self-signed or purchased) that’s used externally.

Are you affected?

Second, you have to check whether you are impacted by the vulnerability.

The easiest way to tell if you are at risk is to use an online heartbleed test. Put in your website that uses https and see what the result is.

To be on the safe side, you can also manually check this on your server. Login via SSH and check to see which version of OpenSSL you’re running by typing in openssl version in Terminal:

[root@vps ~]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

If you’re running any OpenSSL version between 1.0.1 and 1.0.1f, then you’re vulnerable. If you’re running anything below 1.0.1, like 0.9.8 or 0.9.7, then you’re good. If you’re running the latest version 1.0.1g, then you’re also good.

Another surefire way to check is whether you already have the patch downloaded. Simply run:

rpm --query openssl --changelog | grep CVE-2014-0160

This will check to see if you have the patch. If you do, you’ll see something like this:

- fix CVE-2014-0160 - information disclosure in TLS heartbeat extension

If not, it’ll be blank.

How to fix the vulnerability?

Third, once you determined that you are affected, you have to patch the vulnerability.

By now, there should be a patch available on a mirror close to you. You’ll want to make sure that you get one of the updated packages. In my case, it’s going to be 1.0.1e-16.el6_5.7 as described on Red Hat’s website.

You can check your current version and what’s available by typing in yum list openssl in Terminal:

[root@vps ~]# yum list openssl
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.osuosl.org
 * epel: ftp.osuosl.org
 * extras: ftp.osuosl.org
 * remi: mirror.awanti.com
 * updates: ftp.osuosl.org
Installed Packages
openssl.x86_64                              1.0.1e-16.el6_5.7
Available Packages
openssl.i686                                1.0.1e-16.el6_5.7

If there is an update available for your architecture, go ahead and update now. You can either update everything on the server with yum update, or only update OpenSSL with yum update openssl. Since I already updated, nothing is available to me:

[root@vps ~]# yum update openssl
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.osuosl.org
 * epel: ftp.osuosl.org
 * extras: ftp.osuosl.org
 * remi: mirror.awanti.com
 * updates: ftp.osuosl.org
Setting up Update Process
No Packages marked for Update

Don’t forget to restart Apache (httpd) or Nginx (nginx) once you’ve updated.

[root@vps ~]# service httpd restart

Next steps?

Fourth, and this is just as important, you have to replace your SSL certificates, regardless of whether they were generated using OpenSSL or not, because the private key ultimately lives/lived on the vulnerable server.

Replace SSL certificates

Considering this bug has been out there for two years, it’s not inconceivable that someone has obtained your private key, which would allow them to decrypt any communications even after the patch has been applied. Since there is no sure way to tell if someone has obtained your key, it must be replaced.

If you purchased an SSL certificate, you need to get in touch with the company that issued it and ask them if they can issue you a new one and revoke the old one. In light of recent events, some may do this for free, some may charge a fee, but either way, it needs to be done.

If this is a self-signed certificate, you can simply issue a new one yourself and then remove the old one. There are many tutorials online on how to do that.

Update account passwords

Last, but not least, since you can’t be sure that any data that was transmitted over https in the last two years was actually secure, any accounts with passwords need to be reset. If you have customers or clients, I would reach out to your customers, then, if you can, invalidate all existing passwords, and then let them know to reset it.

Conclusion

If you have your own VPS for fun or use it to host a few clients, these steps should be a pretty straightforward. Bigger companies, such as banks and email providers, will have to plan and execute these steps at a much larger scale, but everyone is in the same boat.

If you have any questions or comments, feel free to leave them below.

Featured image by Christopher Beloch.