In the Internet we Trust. At least we used to. Given today’s announcement that the “Heartbleed” bug exposes vulnerabilities in the mechanisms that we’ve relied upon for protecting sensitive information on the web (think passwords, credit card numbers, ANYTHING that is entered on a website), it is cause for immediate concern. In layman’s terms, this vulnerability allows for an attacker to parse (capture) the memory of the web servers running particular versions of OpenSSL, a cryptographic software library, potentially exposing the very data that OpenSSL was supposed to protect in the first place. The scary thing about this vulnerability is that gone un-addressed, there is no way to know if an attacker has compromised sensitive information from the web server. This post provides information to help organizations, as well as consumers, better understand and address this issue.
What is OpenSSL and Why do I Care?
OpenSSL is an open-source implementation of SSL and TLS, the protocols that secure much of what you see on the web. Whenever you are on a website entering sensitive information (passwords, credit cards, etc.), you often get that warm fuzzy of thinking your data is secure because you can see “HTTPS” in the URL box and sometimes you can see a graphical depiction of a lock. Recently, a researcher from Google discovered a bug in several versions of OpenSSL that can allow anyone on the Internet to possibly retrieve names, passwords, and other sensitive information that you thought were going to a seemingly secure website.
Think of OpenSSL being part of the “landing zone” in the ecosystem of what happens to your data when you enter passwords or other information on a website. Once your information is entered on a website, it traverses its way to a back-end application server and/or back-end database server. This vulnerability is only associated with that “landing zone” and not where your data is being stored on the back end (hopefully in a secure manner).
Are ALL Websites Vulnerable?
Heck no. OpenSSL is an open source tool that is used on approximately two-thirds of all websites. Not ALL versions of OpenSSL are vulnerable – according to the NIST site (which is a great technical source of data pertaining to vulnerabilities, albeit a very technical one, so not a good read for those who don’t live in the trenches of InfoSec), this “Heartbleed” vulnerability impacts OpenSSL version 1.0.1 through 1.0.1f and 1.0.2beta. (Note that the exploitability sub-score is a 10, which is as scary as it gets.) I have spoken with several of our clients and business partners, and many of them use technologies to load balance their web servers (i.e., if you do a lot of business on the web, you usually use an appliance to distribute the load against several web servers, not just one). In most cases, the version of OpenSSL embedded within the load balancer was not affected by the bug.
Consumers – Don’t Panic Just Yet
First of all, know that most reputable companies were either not vulnerable to this bug or they are (hopefully!) actively working on a fix. It won’t do you any good to change your password because if the vulnerability exists on that web server, an attacker could just pick up your new password when you enter it, so it is best to just ride this one out.
Here are some things to consider:
- Be on the lookout for suspicious activity on any of your accounts. You should always keep an eye out for that, but even more so now.
- Pay attention to any emails from companies with whom you do business to see if they mention any issues/vulnerabilities on their sites.
- Check your bank account balances more frequently.
- Review your credit card statements more closely.
- Whatever you do, do NOT click on any links from any companies, friends, etc., who are trying to socially engineer you into changing passwords, etc. In the event that you receive a notification from a company to change your password, just go directly to the website of the company/business to do so (those social engineers are getting smarter and smarter).
- Limit your time performing e-commerce and financial transactions, and be wary whenever you enter your username and password. This will blow over once companies have fixed their systems, which will be sooner than later.
- If you have way too much time on your hands, and if you have the technical wherewithal, you can in theory perform a vulnerability scan against the web server that you are trying to access to fingerprint which version of OpenSSL that web server happens to be running. There are a few good tools out there that are FREE and easy to use, including Tenable Security/nessus (http://www.tenable.com/8194.html) and the OpenSSL scanner provided by Qualys SSL Labs (https://www.ssllabs.com).
- Compliments of one of Barak Engel, “Chief Geek” at Eammune (one of our partners), for those folks not quite as zealous, if you are using Chrome as your browser, do this right now:
- Go into “settings” (you can find that in that little button to the top right of the address bar, that looks like three horizontal lines on top of each other).
- Scroll down to the bottom of the page, and click on “show advanced settings.”
- Scroll further down until you get to the sub-header titled “HTTPS/SSL.”
- Check the box “Check for server certificate revocation” (it is not checked by default).
Business – Don’t Miss a Heartbeat
If you are an organization that runs a website and it involves any sort of sensitive information (including passwords), it is incumbent upon you to address this vulnerability. If you are not sure what version of OpenSSL you’re running, you can get with your System Administrator to check the version. You can also partner with a security organization to give your web server a thorough review. Keep in mind that older versions of OpenSSL are not affected. Organizations running affected versions of OpenSSL should upgrade to 1.0.1g (if running 1.0.1) or 1.0.2 (if running 1.0.2beta). If you have a load balancer or a service that terminates your SSL connections, ensure that it is not vulnerable to this.
If you ARE running a vulnerable version of OpenSSL (and you don’t have mechanisms in place to protect you), you should run, don’t walk, through the process of applying the most recent OpenSSL fix. Keep in mind, if you ARE running a vulnerable version of OpenSSL, you should:
- Pull down the appropriate bug-free version.
- Go through your emergency change control processes and test (quickly) in your lab.
- Apply to your web server.
- Consider purchasing a new SSL certificate for your web server since it is possible that the old one was compromised.
- Inform your customers that they should change their credentials.
- Remember, you will have no way of knowing if any of this information was compromised, but luckily the vulnerability was only recently discovered, so chances are that no breaches have taken place. Yet (until you apply the fix).
- Lifehacker is a cool site – they provided some decent advice about what the average user can do.
If You’re an Investor
- Based on this info, there will probably be an uptick in purchases of SSL certificates. It’ll be interesting to see how GoDaddy’s and Symantec’s stock prices fare…
These events just go to show you that in the world of infosec, there is never a dull moment. Businesses and consumers alike need to exercise constant vigilance to be aware of the latest vulnerabilities and threats. I guess that’s what keeps things interesting…
As most folks know, Microsoft’s flagship operating system, Windows XP, is going end-of-life as of April 8. Given the fact that about one out of every three computers runs this OS, there may be some strong ramifications for those who opt for the “do nothing” alternative. If you are running this operating system, you may not be vulnerable the day that it goes end-of-life, but as soon as there is a known vulnerability and if you HAVEN’T done anything to … Continue reading
As most of the world is aware by now, the recent credit card breach at Target (between November 27 and December 15) netted the attackers 40 million credit and debit cards, as well as personal information, such as phone numbers and addresses, of as many as 70 million more. For a few very long weeks, there was scant information about the attack vector and the malware involved with the attack. This posting is a follow-up to my recent posting where … Continue reading
← Older posts