Last Monday, a new vulnerability in OpenSSL version 1.0.1 called “Heartbleed” was announced. This vulnerability is of particular concern as it could permit a remote attacker to extract up to 64 KB of information from any remote server running OpenSSL software. Unfortunately, this data leakage could include login credentials, private keys and other sensitive information.
Based on the software’s release history, this vulnerability has existed for approximately two years. Further, the attack leaves behind no tell tale log signatures to identify that an attack has taken place or what sensitive information may have been leaked. In many ways, this vulnerability represents the perfect storm in Internet security, as OpenSSL is considered the most popular way to secure web browser sessions.
The best way to protect yourself is to reset the passwords on all of your Internet-based accounts that are accessed via a web browser. First, however, the company managing the server needs to take steps to correct the issue. If they have not yet properly corrected the problem on their end, logging into your account could actually put you at additional risk, as tools to exploit this flaw are now freely available.
Here’s how to check to see if it is safe to reset your password:
Public Disclosure
Check to see if the company has posted any information regarding their response to “Heartbleed” or “CVE-2014-0160”. This could be via a blog entry, news feed, or email distribution, varying depending on the organization. What you want to see is that either they were never vulnerable because they don’t use OpenSSL, or that they have both patched their server and cycled the private key used for SSL/TLS communications.
If the vendor was never vulnerable, there is no need to take additional steps. If the vendor has patched and cycled their private keys, you should immediately change your password. If the vendor has not publicly disclosed their response, you’ll need to do a bit of research.
Does The Site Run OpenSSL?
Most non-Windows systems run OpenSSL to secure web server traffic. So if you can identify the operating system used by the web server, you can get a pretty accurate read on whether the site had to deal with this vulnerability. Netcraft’s Site Report is a great tool for identifying the technology behind a given Web server. Again, if it’s a Windows based server, then you should be safe. If it’s a Linux or BSD based system, you should do additional testing.
Is The Site Patched?
It can be difficult to identify what version of OpenSSL is running on a remote system. Luckily, there are public websites that can quickly identify if a specific web server is vulnerable to Heartbleed. You can leverage one of these tools to test your remote vendor, but just ensure that you point it at the server you use to login to the service. This may not necessarily be the company’s main website.
Has The Site Deployed a New Private Key?
Because Heartbleed has been in the wild for so long, it’s impossible to tell what information nefarious actors have been able to retrieve. If they have been able to grab a copy of the server’s private key, they will be able to decrypt all traffic going to and from that server even after patches are applied. A complete fix requires the company managing the site to regenerate the server’s digital certificate.
This is where things get a bit complex as it’s possible to update a private key without creating a new digital certificate. So you can’t just look at the digital certificate and see if it has been issued since April 7th.
So your only option is to trust the vendor when they identify whether or not they have issued new private keys. Typically, if they have taken this additional security precaution, they are going to convey this to their customers. If they don’t mention it, chances are they did not take this additional step.
So what are the risks if the vendor has not cycled their private key? It can be argued that they are pretty minimal. Someone would have had to have attacked the server prior to the patch being installed, and included in the random information extracted from the server would need to be a copy of the private key. So from a risk perspective, this could be considered possible, but not likely.
At Dyn, we decided to err on the side of caution by cycling our private keys. This way, there is no question that we are safe moving forward.
If All Checks Are Good, Change That Password!
If your vendor passes all of the above checks, you can now safely login to the system and change your password. This should secure your account from this point forward.
By Chris Brenton, Director of Security at Dyn
About the Author
The opinions expressed in this post belongs to the individual contributors and do not necessarily reflect the views of Information Security Buzz.
