- April 8, 2014
- Posted by: Jake McAleer, CISA, CCNA
- Category: IT Audit & Security
OpenSSL vulnerability announced (CVE-2014-0160)
Every time you visit a secure website (something that starts with https://), you expect that the data is safe by using a concept called encryption. This past Monday (April 7th, 2014), a large flaw in OpenSSL was announced. Many servers use OpenSSL to manage the encryption methods to protect the data exchanged between computer systems all over the world, including when you surf to websites such as your bank on your personal laptop.
What’s the issue?
The details are rather technical, but basically the bug allows people to gain access to sensitive information on the server, including the private key. Why do we care? When you visit a website, the server and your browser (or other application) communicate using a concept called public-key cryptography. Your computer and the server encrypt the data using a public key that anyone can know. The data may only be decrypted by the private key, which is supposed to be securely stored on the server you’re communicating with so it, and only it, may decrypt what you send it. See the following image for an illustration of how public-key encryption works.
If someone else were to get that private key and had access to the messages you exchange, they could decrypt the messages and read them. This is not the only information that may potentially be leaked; the bug allows access to information in the server’s memory, and so if other sensitive information such as usernames, passwords, or API keys are there, those may be shared inadvertently as well. Please visit CVE-2014-0160 if you want to know more of the technical details.
How do I know if my servers are impacted?
There are many types of servers that use OpenSSL, including Linux and FreeBSD servers. Applications such as Apache and nginx also use OpenSSL. The vulnerable versions of OpenSSL are 1.0.1 through 1.0.1f. OpenSSL 1.0.0 branch and 0.9.8 are not vulnerable to the issue.
Testing a website
You can use 3rd party tools such as http://filippo.io/Heartbleed/ to see if the site you’re about to visit is still susceptible to the issue. We should note that at the time of this article (April 8th, 2014), the website was experiencing a technical issue and you should try running the test multiple times as sometimes it reports false results that a site is safe when it actually is not.
What can I do?
Luckily, there’s an easy fix. The makers of OpenSSL were told about the issue before it was revealed to the public, and the announcement was delayed until OpenSSL had a chance to fix the problem and release a patch. If your company hosts websites or applications that are possibly impacted, you should investigate the best way to update your systems ASAP. You should also update your keys to something new once you’ve patched the systems (since you don’t know if someone already obtained the old private keys between April 7th and when you patched your systems) while also removing and revoking your old certificates since they are possibly now compromised.
If you’re truly concerned about user access, you may also want to force users to change their API keys and/or passwords. This is probably overly cautious due to the limited time the bug has been known to the public and the fact the snooper must have access to the user’s data. The final decision lies with your organization and should be based upon likelihood and impact.
If secure websites you regularly visit (such as your bank or credit card company) haven’t been updated according to a test website such as the one listed earlier in this article, then we suggest you refrain from using them and contact their customer support line to express your concerns.
How do I limit issues like this in the future?
Maintaining a regular patch management program and processes will help to ensure issues like this are mitigated as quickly as possible. This issue has caught a great deal of attention due to the large number of systems it impacts, but vulnerabilities like this one are announced daily. Rather than being reactive, organizations should be proactive by patching on a regular and frequent cycle. Many patches are quietly released without much attention or technical detail, but they often fix very real security risks and should be installed as quickly as possible.
Where can I learn more?
You can learn more about the issue and how to address it by visiting http://www.heartbleed.com.