By now even Joe Average has heard about Heartbleed, and possibly even was told something accurate.
Well and good, but there's one thing missing: how does Joe know that it's time to change all of his passwords? The Register sums things up thusly:
But to fully clean up the problem, admins of at-risk servers should generate new public-private key pairs, destroy their session cookies, and update their SSL certificates before telling users to change every potentially compromised password on the vulnerable systems.
I have logins and passwords on probably 50 to 75 sites. To date not one has e-mailed me to say "Hey, it's all fixed, change your password!" Likewise none of them seems to have posted a similar notice on their log-in page. Does anyone else feel like they're left hanging?
Related Stories
Ars Technica reports that four weeks after its disclosure huge swaths of the Internet remain vulnerable to Heartbleed. The article suggests that over 300,000 servers remain vulnerable.
What steps have you taken to protect yourself from this bug? What browser addons have you installed? Have you checked/updated the firmware on your home router? If you work in IT, what has the reaction been? Has your site been compromised? Has vulnerable code been updated, new keys genned, new certificates obtained, and old ones revoked?
Since the OpenSSL library is now undergoing a security review and a fork of it is underway as LibreSSL, it is possible that other vulnerabilities will be discovered. Then what? How likely is it that we will need to repeat this cleanup effort?
(more after the break)
(Score: 2, Interesting) by tomp on Monday April 14 2014, @01:38AM
Schneier called in "catastrophic". I believe him. I've read the XKCD comic [xkcd.com]. Both [xkcd.com] of them. I still haven't seen a good explanation on how reading a random 64K of memory from a server with many Gigs leads to a "catastrophic" compromise. Even when repeated many times. I don't doubt Schneier, I just don't get it.
Passwords without matching user accounts doesn't seem useful. Trying to match a stack of potential passwords with a stack of potential user names, seems noisy. Noisy enough to draw attention to any potential attackers.
I get the private keys. Precisely 2k of seemingly random bytes may stick out. However that's a server/ca issue, not a user issue. Leaking memory is bad. Very bad. But is it really *this* bad?
(Score: 0) by Mr Dave on Monday April 14 2014, @01:40AM
With the private keys an attacker can impersonate your site and users will believe it is you.
(Score: 3, Informative) by The Mighty Buzzard on Monday April 14 2014, @01:46AM
My rights don't end where your fear begins.
(Score: 4, Informative) by frojack on Monday April 14 2014, @02:16AM
In a recent test, CloudFlare [engadget.com] had a difficult time actually using the heartbleed flaw, so the opened it up to all users on a special server.
It was broken in a day by someone using a script to generate 2.5 million hits. So its not as easy as you might be lead to believe to use this vulnerability, unless you are running a server farm that wouldn't notice 2.5 million increased hits.
Most Banks in the US have STILL not posted any advisory about this, and we don't know how many of them are affected. Most older versions of openssl are not affected, and the principal reason to move to newer versions was to obtain new functionality, which many sites don't need.
So I believe the panic is overblown for most people. And changing your password too soon, before being notified that they upgraded their openssl version plays right into the hands of any current attackers.
The best thing to do is nothing at all. If your password wasn't in memory at the time the attacker last compromised any given site that you visit, then the only risk you have is that the entire site will be powned. And changing your password won't prevent that. Wait till notified before changing anything.
US banks will indemnify you against any loss anyway. And they are pretty savvy about these security threats and were quite likely to be using something other than Openssl. They tend to favor commercial security solutions.
I have so few accounts where it matters, that I really don't worry about it, but will change all my passwords eventually, if any site notifies me they its advisable.
No, you are mistaken. I've always had this sig.
(Score: 3, Informative) by stormwyrm on Monday April 14 2014, @04:16AM
Trouble is, it isn't just passwords and SSL certs that are open to possible compromise. There's also session cookies. So if you were to visit a vulnerable site while logged in, you open yourself up to session hijacking [mattslifebytes.com].
Numquam ponenda est pluralitas sine necessitate.
(Score: 1) by jcm on Monday April 14 2014, @05:40PM
No, you are wrong: 2.5 million hits is the number of total attacks (remember that 3 teams won this contest).
We still don't know how much hits were sufficient to get the key, but it's a magnitude lower.
(Score: 2) by FatPhil on Monday April 14 2014, @08:29PM
"""
The first was submitted at 4:22:01PST by Fedor Indutny (@indutny). He sent at least 2.5 million requests over the span of the challenge, this was approximately 30% of all the requests we saw. The second was submitted at 5:12:19PST by Ilkka Mattila of NCSC-FI using around 100 thousand requests.
"""
https://www.cloudflarechallenge.com/heartbleed
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 3, Informative) by tynin on Monday April 14 2014, @02:16AM
Indeed. At some point, if the attacker was consistent enough, churning through all of the output from a constant attack, they would likely find a login, user/passwd combo of an administrator to the system. Now they have broken through the first layer. Here they can search through logs and perhaps get lucky and find more passwds in history. Or they can redeploy the same attack internally, waiting for the next person to have their login cred freed in a random 64kb block of memory.
This entire attack could be automated. Attacking each perimeter, searching through these 64kb blocks, and in finding new holes (private keys, passwords, etc), pushing recursively deeper, finding better targets further escalating your privileges. You could write all this up and stick a Hollywood UI on it, going on to hack the Gibson. Hell, you could hack the planet.
(Score: 4, Informative) by frojack on Monday April 14 2014, @03:58AM
First thing you want to do is avoid any site where the administrator is even ALLOWED to log in via anything tool that uses openssl. First rule of Unix is NEVER allow root login from anything but the console.
You may SU to root after logging in as Joe User, but that doesn't use SSL. Admins should not be logging in over a web interface. Period.
No, you are mistaken. I've always had this sig.
(Score: 3, Informative) by maxwell demon on Monday April 14 2014, @08:16AM
I think getting root after being remotely logged in as normal user is quite common. In which case you are almost certainly not at the console of that computer (indeed, if it is a headless server, it may not even have a console, and if it is a rented server, the owner is unlikely to let you in the server room every time you need to become root).
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by frojack on Monday April 14 2014, @11:46PM
So what?
If you have a lick of sense, you logged in under SSH, not SSL.
SSL isn't used for SSH.
No, you are mistaken. I've always had this sig.
(Score: 2) by maxwell demon on Tuesday April 15 2014, @12:07AM
It's not uncommon that your shell account and your mail account share the same username/password. And the latter is very likely protected by SSL.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by FatPhil on Monday April 14 2014, @08:31PM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 1) by Ken_g6 on Monday April 14 2014, @01:57AM
OpenSSL decided to create their own version of malloc. For speed, it repeatedly pulls memory from a relatively small memory pool. So the size of the server's full set of RAM doesn't matter.
(Score: 2) by stormwyrm on Monday April 14 2014, @02:24AM
No, it's not actually "reading a random 64K block of memory on a server with many gigs". What happened here is that the OpenSSL team wrote its own malloc/free that re-used memory from several pools in lieu of using system malloc/free for performance reasons, so the bug allowed the display of ostensibly "uninitialised" memory that most likely contained stuff from perhaps unrelated activities that the server previously performed, perhaps containing extremely sensitive information, such as the usernames and passwords of people who logged in previously, or their session cookies. If OpenSSL instead used system malloc/free the bug would have led to at most a denial of service: the server daemon would then segfault as it tried to read memory outside of the allocated block, which while bad would not have been anywhere near as catastrophic. This is what Theo de Raadt [soylentnews.org] seems to have been grousing about.
Session hijacking [mattslifebytes.com] has been demonstrated using this attack.
Numquam ponenda est pluralitas sine necessitate.
(Score: 2) by FatPhil on Monday April 14 2014, @10:31PM
However, this issue confirms that OpenSSL is written by monkeys. https://www.peereboom.us/assl/assl/html/openssl.h
The bug was written and reviewed by a monkey (who must share responsibility).
Even the patch was written by a monkey (magic numbers repeated everywhere).
I'm trying to work out which is the biggest security (s/w) gaff of our time, both this and the Debian keys bug are vying for that accolade.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 1) by Beige on Monday April 14 2014, @02:50AM
To make a long story short, the bug can result in SSL encryption becoming ineffective for a particular web site or mail server. The web/mail/etc service has to be able to associate your login with the password so anyone sniffing your traffic will be able to do the same. This in turn could result in an adversary (ab)using your credentials, tampering with your online services and maybe even compromising your computer (by MITM). They could even use your account to try to convince your friends, co-workers etc to open a malicious program, and so on.
When you consider that pretty much all e-commerce depends on SSL for security it is a significant problem overall. There's also a fair bit of compromised Internet infrastructure out there (everything from backbone routers to insecure LANs) so maintaining reliable encryption is definitively recommended for pretty much anything you do online :-)
(Score: 1) by cwadge on Tuesday April 15 2014, @02:54AM
(Score: 0) by Anonymous Coward on Monday April 14 2014, @02:36AM
No. You see, I take special care of my scrotum. I respect it.
(Score: 4, Funny) by c0lo on Monday April 14 2014, @03:36AM
Possible reactions:
D'you care to share your experience further?
Pick whatever you like
(also feel free to mod this post as OT, even if I was aiming for funny... but I know myself as not necessarily the best joker on the block).
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by krishnoid on Monday April 14 2014, @05:15AM
They have their own per-site checker [lastpass.com] as well as one that will check all sites in your 'vault' if you keep your passwords in LastPass. In addition, there's a Google Chrome extension [lifehacker.com] that will show you when you visit a site that was hit and hasn't been updated (but I haven't tried this personally).
(Score: 2) by oodaloop on Monday April 14 2014, @02:44PM
Came here to say this. I love that site. The scurity check pointed out 5 sites that had patched the vulnerability and where I hadn't changed my password yet.
Many Bothans died to bring you this comment.
(Score: 2) by c0lo on Monday April 14 2014, @06:14AM
https://www.commbank.com.au/blog/what-you-need-to
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 5, Informative) by maxwell demon on Monday April 14 2014, @08:28AM
Now that is an inconsistent page ...
First they state:
OK, so they had the bug, and patched against it. Time to change the passwords.
But then they state:
Wait, what? If they did not use OpenSSL, then what exactly did they patch against the "Heartbleed" bug?
A bit later they write again:
So they were affected by the bug? But then, customers do need to change the passwords.
In short: Not everything states on that page can be true. That doesn't necessarily mean they're lying, but it does make me doubt their competence.
BTW, I don't find the comments section ... maybe I would have to enable JavaScript to see that.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by WizardFusion on Monday April 14 2014, @12:13PM
With that cluster-fuck of inconsistency, I would change all my passwords and secrets for that bank. Then look at changing banks.
As for the comments, I too couldn't find then until I disabled Ghostery.
(Score: 1) by crutchy on Monday April 14 2014, @12:28PM
the likelihood that commbank uses openssl is three fifths of fuck all
what's more likely is that the dipshit pr guy who prepared that press release didn't know a patch from his wife's privates
(Score: 1) by Woods on Monday April 14 2014, @03:00PM
It appears that the large majority of comments state the same questions you had, one commenter down the row says:
"Since NetBank appears to be built with ASP.NET, it runs on Windows Servers that use schannel for TLS, not OpenSSL."
The presumably automated moderator keeps responding to people with this scripted message:
"Hi @user, you do not need to change your NetBank password. We are patched against the Heart Bleed bug. We are dedicated to ensuring our data and that of our customers is safe and secure. We take matters of security very seriously and our security teams are always up to date with all of the latest security developments so that we can continually strengthen the protections we have in place."
(Score: 1) by andersjm on Monday April 14 2014, @06:56AM
For most of those websites, you've already sent your password over the internet in the clear.
Take slashcode for an example: Sure, you can read it over https, but do you, consistently? I know I don't: I read soylent through the RSS feed, and the RSS feed contains only http: links, even if you retrieve it over https. Ondoubtedly the RSA already has my password, and who knows who else?
So it's really up to the individual to decide which sites you need to log on to securely. Figure that out, and change the password for those.
(Score: 3, Informative) by lhsi on Monday April 14 2014, @07:34AM
I logged onto my bank the other day. After signing in they had a message saying essentially "Heartbleed has been in the news recently. We were not affected. You do not need to do anything".
Followed by a check-box saying "I have read and understood this".
Outside of SoylentNews I haven't heard any other password changes that I need to do. I figure there is no point in changing password on a service that was either never compromised or might still be compromised, so will wait for each individual one to say one way or the other.
(Score: 2) by WizardFusion on Monday April 14 2014, @08:46AM
Every bank I use (three of them) in the UK all mentioned that they weren't affected by this. One then went on to say about general security and changing passwords regularly, etc.
(Score: 1) by opinionated_science on Monday April 14 2014, @04:09PM
I would like to point out a few facts that have emerged.
1) Bruce Schneier was right.
Any private information leaked from a server is bad. Leaking the private key is a calamity, especially through the passive route this exploit allows.
2) The liability is poorly understood
PIN numbers can be stolen, and that is contentious. If customers have their accounts cleaned out, how exactly do you prove it?
3) Security is a process not a state
This is a case study for that.
4) The bad guys might get caught too.
it is now a race to see how much damage this bug can do
(Score: 2) by nightsky30 on Monday April 14 2014, @12:43PM
I did see a message popup on http://www.memoryexpress.com/ [memoryexpress.com] when viewing an article on the WRT1900AC. I don't have an account with them, but they still stated that they were not/are not susceptible to heartbleed. I think that is better than nothing. Bravo to them for notifying users somehow and staying secure if the note is indeed true.