In the wake of widespread media coverage of the Internet security debacle known as the Heartbleed bug, many readers are understandably anxious to know what they can do to protect themselves. Here’s a short primer.
The Heartbleed bug concerns a security vulnerability in a component of recent versions of OpenSSL, a technology that a huge chunk of the Internet’s Web sites rely upon to secure the traffic, passwords and other sensitive information transmitted to and from users and visitors.
Around the same time that this severe flaw became public knowledge, a tool was released online that allowed anyone on the Internet to force Web site servers that were running vulnerable versions of OpenSSL to dump the most recent chunk of data processed by those servers.
That chunk of data might include usernames and passwords, re-usable browser cookies, or even the site administrator’s credentials. While the exploit only allows for small chunks of data to be dumped each time it is run, there is nothing to prevent attackers from replaying the attack over and over, all the while recording fresh data flowing through vulnerable servers. Indeed, I have seen firsthand data showing that some attackers have done just that; for example, compiling huge lists of credentials stolen from users logging in at various sites that remained vulnerable to this bug.
For this reason, I believe it is a good idea for Internet users to consider changing passwords at least at sites that they visited since this bug became public (Monday morning). But it’s important that readers first make an effort to determine that the site in question is not vulnerable to this bug before changing their passwords. Here are some resources that can tell you if a site is vulnerable:
https://www.ssllabs.com/ssltest/
http://heartbleed.criticalwatch.com/
https://lastpass.com/heartbleed/
As I told The New York Times yesterday, it is likely that many online companies will be prompting or forcing users to change their passwords in the days and weeks ahead, but then again they may not (e.g., I’m not aware of messaging from Yahoo to its customer base about their extended exposure to this throughout most of the day on Monday). But if you’re concerned about your exposure to this bug, checking the site and then changing your password is something you can do now (keeping in mind that you may be asked to change it again soon).
It is entirely possible that we may see a second wave of attacks against this bug, as it appears also to be present in a great deal of Internet hardware and third-party security products, such as specific commercial firewall and virtual private network (VPN) tools. The vast majority of non-Web server stuff affected by this bug will be business-oriented devices (and not consumer-grade products such as routers, e.g.). The SANS Internet Storm Center is maintaining a list of commercial software and hardware devices that either have patches available for this bug or that will need them.
For those in search of more technical writeups/analyses of the Hearbleed bug, see this Vimeo video and this blog post (hat tip once again to Sandro Süffert).
Finally, given the growing public awareness of this bug, it’s probable that phishers and other scam artists will take full advantage of the situation. Avoid responding to emailed invitations to reset your password; rather, visit the site manually, either using a trusted bookmark or searching for the site in question.
I’ve sometimes said … if it goes outside the computer, it’s not secure.
Computer security in general – internet security in particular – depends on trusting software and hardware that you have absolutely no control over.
But it’s not even necessary to go outside of the computer when you’re dealing with exploit code that can ‘reach in.’ 😉
Do these Heartbleed test sites only verify that the openSSL code was patched, or do they also verify the presence of new certificates? The job is not done until (1) the openSSL code is patched, (2) new certificates are acquired and installed, and then (3) users are forced to reset passwords, pins, and other security related data — in this order.
I read that you can get new certificates but keep the same dates as the old so only the system administrator knows for sure.
http://filippo.io/Heartbleed/faq.html#falsesense
I’m also concerned about OldGnome’s point. I’ve been looking at some of the ‘fixed’ sites’ certificates and they are still using certs issued before the bug was announced. Also it should be pointed out that a new secret key should be generated for the new cert, and the old key revoked (even though revocation doesn’t work well in practice). Granted fixing the openssl hole is the most urgent task and closes the most serious flaw, but one must still assume that server keys were compromised. The job should not be considered done until new keys and new certs are in place.
Cloudflare had an early notification if I remember (and had to sign an NDA.. so the security corp could market the bug release) and I have yet to see any sites replace their certs that for sure could have been stolen. This was wide open from 2012-now so we should assume everything was compromised.
However I also assume all certs are compromised, considering the sad state of CAs. Look up Moxie Marlinspike’s Blackhat 2011 talk about CAs, he found signing certs just randomly laying around unprotected drives and anybody can buy a trust-root cert to sign away any fake site they wish.
If possible people should install KeePass (KeePass2 in most linux distros) and use that password db to generate unique passwords for every site they use, then you just need to remember 1 password.
You’re so right, some people think an AV (and often they mean a free one) is all you need plus your critical downloads but passwords, nah! I’ve used the premium option of LastPass as it runs on my two PCs and smart mobile. It may cost $12 a year but, to use phrase ‘I’m worth it’!
You can re-key a certificate without changing the date. A certificate vendor might prefer this approach, for obvious financial reasons. Some buyers may prefer it as well, if for no other reason than to avoid disturbing important records while things are more or less in an uproar.
robin segglemann.
stephen henson.
would really hate to be one of these two people right now. apparently had good intentions. but inadvertent coding with inadequte review, resulting in catastrophic worldwide long-term consequences.
http://m.smh.com.au/it-pro/security-it/man-who-introduced-serious-heartbleed-security-flaw-denies-he-inserted-it-deliberately-20140410-zqta1.html
Anyone take a look at TOR? Especially the donated/contributed virtual instances?
I’m sure there’s a ton of embedded off-port cases that are going to be difficult to identify until some agency and/or criminal exploits this. Hell, I have to look at my own embedded devices.
Tor also had a problem. Of course, it warns you when you launch it. You will need to update to 3.5.4. The usual process of saving off your latest, bookmarks-.json file, then importing it into the latest version applies, for people who are not familiar with it.
Regarding embedded devices, the story is not so simple. In very many cases, a Heartbleed attack is not required, as private keys from over six thousand hardware/firmware combinations have been publicly available since 2011. This list has surely grown since then. In that data, ‘VPN’ appears 534 times. The embedded space is in sorry shape.
http://fubarnorthwest.blogspot.com/2014/04/heartbleed-will-be-with-us-for-long-time.html
A good piece of material, but I think it can be even better. Certain methods, like the two step sign in, are not mentioned here. I think it’s good for people to know as many methods as possible. I have listed 6 methods and have provided explanation for each one in this article http://glipho.com/christianreese/5-ways-to-protect-yourself-from-the-heartbleed-bug
I contributed an essay that helps application server owners understand what was put at risk and what not.
OpenSSL Heartbleed bug: what’s at risk on the server and what is not.
http://www.hbarel.com/openssl-heartbleed-bug
From Hagai Bar-El’s post, though it doesn’t mention it explicitly, it occurs to me that it would also be prudent to expire all cookies issued prior to the web server being patched, particularly those related to login, session or state that may allow an attacker access to an account.
You are certainly right.
If you add a comment on the original post, I will add this.
I have tested my online banking site and out of five validation sites, three gave a green light while two did not.
Ssllabs evaluated two servers at my bank and said for the second one, “Warning: Inconsistent server configuration” and noted, “Certificate not valid for domain name” The first server received an A-
Lastpass returned:
Server software: Apache
Was vulnerable: Likely (known use OpenSSL)
SSL Certificate: Possibly Unsafe (created 3 months ago at Dec 30 00:00:00 2013 GMT)
Assessment: Wait for the site to update before changing your password
Today my bank has a new notice on their web site saying, “Our current research and analysis indicates that [their online banking] and affiliated programs are not affected by this vulnerability.”
I am confused by all this.
Completely agree with OldGnome on his/her assertion and approach. The problem is that the “man/woman/child on the street” will have no possible way of knowing whether a given site has executed the defined mitigation sequence, thus providing some assurance that a password change will be effective.
AND, now WSJ is reporting this morning that Cisco and Juniper have acknowledged that this vulnerability is prevalent in many of their commercial grade products, including routers, switches and firewalls. A Cisco spokesperson was quoted saying “dozens” of products have been identified with more investigation underway – likely meaning that MORE products will be identified.
Remediation of THESE devices will be even more complicated than remediation for servers. This is NOT good news.
Toby Pennycuff is correct in asserting that the “man/woman/child on the street” will have no possible way of knowing whether a given site has executed the defined mitigation sequence. The IT staff must manage this part of the process. When all cleanup steps are successfully completed, user passwords should be expired. This is how the “man/woman/child on the street” will know the proper mitigations are in place. Web site users would be forced to provide new passwords, and hopefully they will be advised to change any additional pertinent data after they are logged in with new credentials. A nice touch of “due diligence” would be to inform users that login and related security data will NEVER be solicited via email.
http://online.wsj.com/news/articles/SB10001424052702303873604579493963847851346?mod=WSJ_hpp_MIDDLENexttoWhatsNewsForth&mg=reno64-wsj&url=http%3A%2F%2Fonline.wsj.com%2Farticle%2FSB10001424052702303873604579493963847851346.html%3Fmod%3DWSJ_hpp_MIDDLENexttoWhatsNewsForth
WSJ: Heartbleed Bug Found in Cisco Routers, Juniper Gear
http://www.nytimes.com/2014/04/11/business/security-flaw-could-reach-beyond-websites-to-digital-devices-experts-say.html
New York Times: Cisco also posted a list of products it had examined for the vulnerability, which it was updating as it continued inspecting its equipment.
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed
Well… no surprise, this:
“Hackers Posting Massive Lists of Vulnerable Domains”
http://blog.easysol.net/2014/04/10/heartbleed-hackers-posting-massive-lists-of-vulnerable-domains-huge-account-takeovers-more-likely-over-time/
Yeah, hackers are industrious, aren’t they?
Now a word from Cloudflare.com over this issue:
“Heartbleed may not allow access to those private keys after all. In two weeks of testing, the company has been unable to successfully access private keys with Heartbleed, suggesting the attack may not be possible at all. “If it is possible, it is at a minimum very hard,” researcher Nick Sullivan writes. “And we have reason to believe… that it may in fact be impossible.” If true, it makes Heartbleed much less dangerous than many had feared, offering a saving grace for compromised sites. “Heartbleed still is extremely dangerous,”
http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed
Well that was a careful use of the ellipsis when quoting Oregano — here is a better edited version that changes the meaning of what Cloudflare was saying:
” and the modified version of NGINX that we use, that it may in fact be impossible.”
They aren’t claiming it may be impossible in general, but only specifically in the way their systems are configured.
A claim for an exploit in a contrived situation, but one which seems reasonable, is shown here:
https://twitter.com/1njected/status/453797877672706048
Are you likely to get the private key from a system that has been up and running? No. It is probably quite unlikely.
Timing is critical. Let’s take the plethora of Ubuntu boxes that run their system daily crontab at 6:25 am on the system time. One of those is the security updates, with a 30 minute window during which a random timer is used to reduce the load on the update servers.
So an attack that hammered the heck out of a vulnerable server from 6:25-6:55 on days that an Apache or other security patch that will result in web server being restarted is scheduled to be distributed by Ubuntu is going to be much more likely to succeed in revealing the private key then randomly checking the server at other times of the day or week.
You could do other variations on this attack — such as trying to overwhelm a server to the point the Sysadmins just reboot it to see if it fixes the problem, and attacking it with the Heartbleed as it comes back up.
How likely? I’m not sure. But the Cloudflare conclusion that their systems may be invulnerable to revealing the private keys doesn’t mean that everyones systems are equally unlikely.
Passwords are irretrievably broken. Get two factor authentication for your banking site.
2 Years x (NSA + Heartbleed) = Not Surprised
http://mobile.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html
http://m.huffpost.com/us/entry/5134813
Maybe ask if Snowden can confirm? lol
Wish there were a way to search comments to make sure I didn’t miss if this question was already asked…
I’ve been checking a few sites with the links listed but haven’t had any luck. Am I supposed to use the https:// address? Or just the www. Address? I keep getting a message that something went wrong from the 1st link ‘fillipo.io’ and the the rest of the links I just get a message asking if I made a typo. ??? What am I doing wrong?
Try this:
http://www.bing.com/search?q=Qualys+SSL+Check&FORM=R5FD
You may have to allow scripts, but I don’t remember having to do that over there. They are one of the best.
Pardon me, I was taking a break from my taxes, and got in a hurry; this is what I meant to link.
https://www.ssllabs.com/ssltest/index.html
if you’re in canada, you may want to check if the tax e-filing netfile is still not safe because of heartbleed.
Good advice! I thought of that and did just that – both sites were OK.
a teenage 19-year-old university student was arrested for allegedly being responsible for the heartbleed attack on the official Canada tax website. yet another idiot kid who was probably bored with too much time on his idle hands itching to do nothing good.
http://grahamcluley.com/2014/04/heartbleed-hacker/
Thank you JCitizen I got the same message I had before ‘unable to resolve domain’ don’t know if that’s a good thing or just means I’m not doing it right :-/
I have been swiping the entire address, copy/paste – that is weird! I have all cookies and even 3rd party cookies enabled – also put Qualys on the trusted list. Maybe it is just the browser settings?
I’m using Safari on my iPhone, could that be the problem? I don’t have a desktop.
All browsers have some security settings that can interfere with some sites. Ordinarily I’d suggest downloading Chrome for iOS, but as of 2012 that was just Safari in Chrome clothing. I’m not sure if Mozilla(Gecko) or Google have been fully permitted in the Apple store or not. Sorry I’m not an Apple head – I wish I could be of more help.
You could always go to a Library, or a friends Android, to check your critical sights to see if they are in compliance. As long as they are, your iOS based phone would be just as safe; provided iOS has no Heartbleed vulnerabilities, and I’m pretty sure it would have been patched by now, if it ever needed it.
lisa, just put in the domain name address.
example: domainname.com
don’t have to put in https:// or www
the filipio site, the lastpass site, etc. all work fine for me on my iphones.
Tried and failed with the site I was concerned with Perhaps it’s a good sign that it is not vulnerable?
I got an email from Lastpass that suggested running their built in security checker; and it came up with a handy list of sights that are vulnerable – so wait on password update, sites that were updated with date of update, sites that you can go to and change your password. I didn’t cross check for veracity, but then, for the regular joe sixpacks I run with, that is pretty good advice!
when they say change password, are they referring to the password you use to log into a specific site, e.g., Instagram or your email password? I thought the problem originated with yahoo email.
I am very strong believer in every secure website that deals in money transfer or banking should be using some type of two factor authentication (2FA) in the log-in process and or to verify payments by the end user.
In the below article it states clearly ” And while it wouldn’t have made heartbleed less of a bug, it would have made any passwords harvested by means of the bug much less useful, perhaps even useless.”
I rest my case !
“Heartbleed” – would 2FA have helped?
http://nakedsecurity.sophos.com/2014/04/12/heartbleed-would-2fa-have-helped/
Thanks for such nice information for sharing with users.I got early morning message from pinterest.com to change passwords due to heartbleed bug.Although their systems are not affected at pinterest .I will be more cautious for my website http://www.thewebthinkers.com now.
I am beginning to wonder with all the crap that goes on anymore
If I would be better going back to the old way of doing things,
Paying bills by mail, no online purchases or banking and last but not least
Using cash for all purchases like I did years ago.
Yes the web is convenient but the risk is fast becoming a royal pain
In the ass, at my age “67” I really don’t want to keep changing passwords
And worrying if someone emptied out my bank account.
Yeah I know my social security comes electronically. I just need to keep
Smaller balances in checking. A lot of seniors I know do nothing on computers,
Maybe they are the smart ones.
Many of my clients weren’t even online when the Target breach happened. Their bank accounts and credit cards were affected none-the-less. You can run, but you can’t hide – because all the banks and brick-n-mortar store ARE online!
Ether way you can get pwned now days!
Since Tor is being mentioned here, the current version of Tails is safe:
“If you’re using an older OpenSSL version, you’re safe.”
openssl version: 0.9.8o-4squeeze14
https://blog.torproject.org/blog/openssl-bug-cve-2014-0160
For those using TBB, consider switching to Tails:
https://tails.boum.org/
CHECKING ACCOUNT BREACHED
I haven’t seen any reports on checking accounts being breached by electronic transfers. Just found 3 fraudulent transfers out of my checking account. The thief used Capital One and Comenity Bank.
Also PayPal for 2 very small deposits into the account. I had the account closed, but wonder how safe any new checking would be. Also how prevalent are checking account breaches. Could this be an aspect of Heartbleed?
Do you reuse logins/passwords? If so, it’s quite possible that they used your login/password from a different website and tried it on your banking website.
If you still need guidance on what you need to do to best safeguard your data, this video gives good tips on checking site safety and picking new passwords- give it a watch!
“Heartbleed Flaw: Best Practices for End Users”: http://hub.am/1kSQjAz
Some great advice here, thanks for sharing.
This is a distressing piece of news: As many as 50 million #Android devices may be vulnerable to #Heartbleed #Google http://t.co/3E3zPO7wdA
I wonder if iPhones will be next…
No, iPhones were never affected. Not saying anything more.
Great advice here, thanks for sharing.
For all you people that think the heartbleed bug is such a shock and want to use it to bash OEM’s and software engineers. Stop and really think about it you can’t protect your data on your devices. Go run the Belarc Advisor on your devices, laptops and desktops. Learn how android in particular has a known vulnerability that has been in place since its very beginning and how it hasn’t and will never be patched. I tkunk the best way to really protect your self is migrate to a Ubuntu device (most US carriers declined to support it). It is by far the safest and most stable OS bar none.
We seem to be spiraling around the effect of the issue, which is easily understood as a reaction. However as a quality/security engineer I keep asking the question “What was the root cause of how the code make it to deployment without sufficient testing?” If the code was checked in, it must have a requirement. Was sufficient testing agasint the requirement performed for [1] what it was suppose to do AND [2] what it wasn’t required to do?