Heartbleed Vulnerability in OpenSSL (CVE-2014-0160)
Since it hit the news on Monday, the technical support world has been scrambling to contain the damage from the Heartbleed vulnerability in OpenSSL, a piece of software that is widely used to provide encryption in web servers, VPNs and embedded devices. Any web site that connects as "https" is likely using OpenSSL. The vulnerability allows an attacker to gain access to memory on the server and to obtain the private key used for encryption on the server. With the private key, the attacker can then listen to encrypted conversations containing user IDs and passwords. With a password, the attacker can then log in as an authenticated user--potentially an authorized administrative user and get access to a variety of confidential information. If an attacker manages to get a private key while a system is vulnerable, the attacker will still be able to listen to conversations until both openssl is patched AND the private key and related certificates are replaced.
The vulnerability was present in released code for about two years before security researchers identified it. The vulnerability announcement is located at https://www.openssl.org/news/secadv_20140407.txt.
Actions for Managers
System administrators should update systems with the patched version of openssl immediately for web servers, routers and other devices that are vulnerable. SSL private keys and certificates will have to be replaced. Managers and executives should verify that this is happening.
Cisco has released an advisory for products that are vulerable; the advisory is located at http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed Check with your VPN vendor to determine whether or not your enterprise VPN software is vulnerable.
Even if your site was not vulnerable, you might consider updating your certificate as reassurance to your users--an issue date after 2014-04-07 is perhaps the only way to determine that your site is secure.
If your IT department has users of Cygwin (Windows) and Macports (OS X) Unix/Linux command shell and utilities, they will need to update software to get the patched version of OpenSSL, but these are not widely used as web servers. This list is just the start of the software that is affected by this vulnerability.
My hosting firm, ipage.com, updated all servers on Monday with the release of the patched code, but didn't restart the web server on my VPS until I checked with them on Wednesday. Small business owners should verify that their web hosting firms have done the necessary updates and re-boots. I'm not looking forward to the process of revoking my existing certificate and getting a new one.
Actions for Users on Internet Sites
Users should change all passwords AFTER verifying that the various web sites have installed the patch. Don't reuse passwords--you should get a password manager and use a different strong password for each web site. A security researcher/consultant in Italy wrote an exploit and installed it on his server to allow users to test web sites. There are web sites where you can test for the vulnerability before changing passwords:
- See http://filippo.io/Heartbleed/ This was the first site to be set up with significant publicity. It is run by a cryptography consultant and will probably be swamped in the coming days.
- McAfee has provided a site to test systems as well; http://tif.mcafee.com/heartbleedtest?cid=146327&ctst=1.
You should change passwords again (or for the first time) after sites have replaced their private keys and SSL certificates--the Certificate Authorities are probably swamped right now and are likely to be one of the choke points at fixing this vulnerability. To tell whether or not a web site's private key and cerificate have been replaced, click on the lock icon in your browser. It may take a few clicks, but you should be able to view the certificate issue date; look for an issue date after 2014-04-07. If this sounds like a serious pain, it is. I don't have suggestions for a way around it. There is an example below
Actions for Home Networks and Small Business Owners
The problem is not limited to web servers. Because OpenSSL is open source, it is widely used in embedded devices--especially Wi-Fi routers. OpenSSL can be used in the implemention of WPA encryption, and may be vulnerable. The https administration console may also be vulnerable. If a device has vulnerable firmware, but the manufacturer has does not issue an update, you may be able to salvage the device by installing an open source firmware like DD-WRT. Home owners and small business owners rarely update firmware, so the Heartbleed vulnerability is just one of many vulnerabilities on a typical Wi-Fi router.
Users of Cygwin (Windows) and Macports (OS X) Unix/Linux command shell and utilities need to update software to get the patched version of OpenSSL, but these are not widely used as web servers. This list is just the start of the software that is affected by this vulnerability.
Actions for Cell Phone Users
Some cell phones also have the vulnerable version of OpenSSL--Android 4.1.1 and some Blackberry iOS and Android applications in particular. Avoid using your device as a Wi-Fi hotspot until your phone's firmware has been updated. There may be other functions that are vulnerable.
Don't ignore this vulnerability.
Example of Checking a Certificate's Issue Date
To check whether or not a web site has replaced their private keys and has thus finished remediation of the Heartbleed vulnerability, check the issue date of their SSL certificates.
- First, click on the lock icon in the upper left corner of the URL for the web site. This is just to the left of https://www.google.com in the figure below. In the pop-up, select \"More Information\".
- Second, in the Page Info window, select the "View Certificate" button half way down on the right side.
- Finally, look at the "Issued On" date under the "Validity" section of the Certificate Viewer. Generally, this should be 2014-04-07 or later. A Google researcher was one of the ones who identified the Hearbleed vulnerability, so Google got a head start on remediating their systems. That is why they have certificate issue dates of 2014-04-02 instead of 2014-04-07.
