Heartbleed and Oh Shit - this is important to everyone.

MyrmidonMyrmidon Baron von PuttenhamCalifornia
edited April 2014 in Internet & Media

So, as of less than 24 hours ago, this is a thing:

http://heartbleed.com/

This is exceedingly important - about 66% of the web uses openssl.

Now, correct me if I'm wrong (I don't want to fearmonger), but this effectively means if you have ever signed on to a secure website (https, not http... or, in fact, if you've ever passed info over TLS), there is about a 66% chance that this vulnerability existed on that server. And since it's been around for A FEW versions of openssl (1.0.1 was released March 14, 2012 according to my server), it's likely a couple folks have been heartbleeding servers for a long time.

So... your passwords? There is an EXTREMELY good chance that many of your passwords have been leaked in plaintext. Not to mention any security questions - basically anything you've ever typed into a secure webform since this heartbleed bug went into effect is very suspect. A cursory google search suggests steam has been affected by this (though I didn't read any of the posts, just the headlines).

What this means for you right now is a lot, but the consequences may not appear until down the line:

  1. Any of your passwords that were scooped up by a heartbleeding eavesdropper are now likely part of a dictionary (not Websters', the kind used just before brute-force cracking).
  2. The next time a big corporation (i.e. target) loses their customer's hashed password table, someone's going to attempt to test all known passwords using those dictionaries.

Ergo, next time there's a big corporation hack, your shit will be out in the open within the day.

I would give it about three days - I figure in at MOST three days, every important secure server will have patched openssl (most of them have already done so, I hope). At that point, I'm going to change every password on every website I know of. I would urge you to do the same.

If someone who knows more about security than I do can debunk this, PLEASE do so. I don't want to stir shit up because I understood things wrong.

EDIT: Fixed the date of openssl 1.0.1

ANOTHER EDIT: If you've put any personal info into a secured server at all in the last 24 hours, you're pinning your hopes and dreams on the server admin having updated openssl. It's a safe bet that now that people know the heartbleed bug is available, they're using it anywhere they can in the hopes that a server admin is slow. Don't login, don't logout, just don't do anything that will pass authentication information anywhere for a little bit.

Also, silver (ish) lining... Since this has been out for three years, it's likely that if you weren't hacked in one of the myriad number of security fiascos in the last few years, your stuff wasn't leaked (this bug probably wasn't too well-known until recently). Of course, saying 'I haven't been hacked yet, so my info probably wasn't lifted' is a big bag of security through obscurity... and we all know how that goes down. Change your shit.

tl;dr Wait a few days and change every web password and security question you've ever had. Also, get a password manager.

oni_delsPirateNinjaLincGHoosdumBobbyDigicolaRahnalH102JBoogalooErrorNullTurnipPinkBandrikGargtrooster89RyanFodderBasil
«1

Comments

  • That's funny, it requires patching openssl AND reissuing a new set of keys. Hell of an oops.

    There is no way in hell all the servers running apache, and other suites that use openssl are going to get patched with reissued keys for each cert within any sort of reasonable amount of time. A lot of server admins are simply going to patch OpenSSL and not replace the secret key because lazy or didn't read the memo or see an opportunity.

    More arguments to use 2 step auth with any service that is critical to you so you don't hijacked. Regarding people getting their hands on your credit cards / whatever ... I just operate under the assumption that people already have my identity and money, and all I can do is monitor it.

    SignalLincGargBasil
  • edited April 2014

    Okay, a bit of perspective on this.

    1. Just because 66% of the web uses openssl does not mean 66% of the web has this vulnerability. It only exists in a specific range of openssl versions. Notably RedHat 5.x series (and by extension CentOS 5) has a version of openssl that does not have this bug. A LOT of servers out there still run CentOS/RHEL 5.x due to the fact that it is still supported and corporations tend to upgrade very slowly. For instance, none of the public webservers I'm responsible for were affected by this and only a couple internal webservers had the bug.
    2. This bug just came to light, and there has been NO proof of concept that actually demonstrates the ability to steal the SSL key from a running server (last I checked). Yes, you can cause SSL to leak data, but the way it leaks data, from what I've read, would make it very hard if not impossible to steal the SSL key (you can cause data that is stored in memory AFTER the buffer pointer to be leaked, but because of the way memory is typically allocated, the SSL key should only be in memory locations BEFORE the pointer that this bug affects). Everyone is saying that you should replace all certificates out of an overabundance of paranoia only. That said, I would still recommend replacing the key and certificate on any server which had this bug.... but it's not an OMG the building is burning down and all is lost situation. Yet.

    EDIT: So, the skepticism about the PoC and actually being able to steal the key isn't quite as solid as I originally thought. This is a bad bug, but I'd still argue that nobody should panic just yet. There is not an "extremely good chance your passwords have been leaked in plaintext". That possibility is pretty small at this point, but it exists, and will grow over time for sites that don't patch. The possibility is much higher that your password for Icrontic was leaked in plaintext since it doesn't run SSL at all though! You can read more about the bug here: http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

    BandrikGarg
  • The problem with writing things in managed languages, however, is that you then have to contend with bugs in the language itself which you have no way of knowing about or fixing. For instance, java constantly has exploits that we have to wait on Oracle to release fixes for. If a critical system library like OpenSSL had to wait on a corporate entity to get around to patching it's sandbox environment in order to address a bug like this, we'd have much bigger problems than we do right now.

    That said, I completely agree that we need to audit things like OpenSSL and I would gladly contribute to a fund to do so (and encourage my employer to contribute a huge chunk of change as well).

    Garg
  • @ardichoke said:
    The problem with writing things in managed languages, however, is that you then have to contend with bugs in the language itself which you have no way of knowing about or fixing. For instance, java...

    That said, I completely agree that we need to audit things like OpenSSL and I would gladly contribute to a fund to do so (and encourage my employer to contribute a huge chunk of change as well).

    Well yeah, I mean .. Java isn't the best. C++ with garbage collection though? But yes, I agree with your argument about the language itself having issues. I feel like it is a worthy trade off for human error regarding memory management.

    I also think companies that make money hand over fist off of OpenSSL should help support it, but try explaining that to a CFO that doesn't understand how the Internet works. From what I understand there needs to be incentive, like how Google pays the Mozilla Foundation millions each year and in return the default FireFox homepage is a Google landing page. Maybe the cert selling companies should be the ones funding OpenSSL since there is a direct and visible money trail there. It's a good conversation to have for fun, but even with big security derps like this happening every once in a while I don't see big changes coming around because there is not enough incentive and it is too technical for most people to understand.

    Garg
  • @PirateNinja said:
    C++ with garbage collection though?

    This is pretty much exactly why I was hoping D would catch on. I even started learning it at one point. Never seemed to go anywhere though :/

  • LincLinc Bard Detroit

    FWIW, Icrontic's server is not vulnerable. We run CentOS 5 and I've confirmed we're not using a vulnerable version of OpenSSL.

    JBoogaloomertesnGnomeQueen
  • @Lincoln said:
    FWIW, Icrontic's server is not vulnerable. We run CentOS 5 and I've confirmed we're not using a vulnerable version of OpenSSL.

    You also don't serve Icrontic over HTTPS, so you're sending everything in the clear anyway. Even if you had a problem version of openssl, it wouldn't have made a difference.

    JBoogaloo
  • LincLinc Bard Detroit

    @ardichoke said:
    You also don't serve Icrontic over HTTPS, so you're sending everything in the clear anyway. Even if you had a problem version of openssl, it wouldn't have made a difference.

    I understood the issue to be that it would serve up those memory chunks regardless of whether you were actually serving over HTTPS. I actually have valid certs and asked for them to be installed but it appears something is wrong with them.

  • MyrmidonMyrmidon Baron von Puttenham California
    edited April 2014

    @ardichoke said:
    Okay, a bit of perspective on this.

    1. Just because 66% of the web uses openssl does not mean 66% of the web has this vulnerability. It only exists in a specific range of openssl versions. Notably RedHat 5.x series (and by extension CentOS 5) has a version of openssl that does not have this bug. A LOT of servers out there still run CentOS/RHEL 5.x due to the fact that it is still supported and corporations tend to upgrade very slowly. For instance, none of the public webservers I'm responsible for were affected by this and only a couple internal webservers had the bug.
    2. This bug just came to light, and there has been NO proof of concept that actually demonstrates the ability to steal the SSL key from a running server (last I checked). Yes, you can cause SSL to leak data, but the way it leaks data, from what I've read, would make it very hard if not impossible to steal the SSL key (you can cause data that is stored in memory AFTER the buffer pointer to be leaked, but because of the way memory is typically allocated, the SSL key should only be in memory locations BEFORE the pointer that this bug affects). Everyone is saying that you should replace all certificates out of an overabundance of paranoia only. That said, I would still recommend replacing the key and certificate on any server which had this bug.... but it's not an OMG the building is burning down and all is lost situation. Yet.

    EDIT: So, the skepticism about the PoC and actually being able to steal the key isn't quite as solid as I originally thought. This is a bad bug, but I'd still argue that nobody should panic just yet. There is not an "extremely good chance your passwords have been leaked in plaintext". That possibility is pretty small at this point, but it exists, and will grow over time for sites that don't patch. The possibility is much higher that your password for Icrontic was leaked in plaintext since it doesn't run SSL at all though! You can read more about the bug here: http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

    1. I have a hard time believing that the 66% of the web using this didn't run aptitude update/upgrade (or whatever other package manager update script) in the last three years. When you say none of your webservers you were responsible for were affected, what exactly were you running that you were not affected? Old versions of software? Or just not openSSL (in which case you're part of the 33%)?

    2. Sounds like you've already taken a look at this one - if I'm using the exploit, I'm going to look at as many heartbeats as I can - 64K per hearbeat adds up data fast. Real fast. And like you said in your edit, yes, there IS in fact proof of concept. Furthermore, your password is not getting leaked in 64K - but if enough information to reconstruct the private key IS, then all future communication with the server - including your password, IS.

    EDIT: phrasing

  • MyrmidonMyrmidon Baron von Puttenham California

    @PirateNinja said:
    That's funny, it requires patching openssl AND reissuing a new set of keys. Hell of an oops.

    There is no way in hell all the servers running apache, and other suites that use openssl are going to get patched with reissued keys for each cert within any sort of reasonable amount of time. A lot of server admins are simply going to patch OpenSSL and not replace the secret key because lazy or didn't read the memo or see an opportunity.

    More arguments to use 2 step auth with any service that is critical to you so you don't hijacked. Regarding people getting their hands on your credit cards / whatever ... I just operate under the assumption that people already have my identity and money, and all I can do is monitor it.

    ...Shit. You're right about them probably not going to change the key. OH GOD MY TINFOIL HAT REFLEX

    RahnalH102
  • @Lincoln said:
    I understood the issue to be that it would serve up those memory chunks regardless of whether you were actually serving over HTTPS. I actually have valid certs and asked for them to be installed but it appears something is wrong with them.

    The data is only getting tossed in to insecure memory when openssl is processing it. I don't know, but my guess would be OpenSSL does nothing in regards to standard http requests. Maybe make sure you have the https port configured on your server properly re: ssl_error_rx_record_too_long

  • @Myrmidon‌ - It's not enough just to run updates, most major distros freeze the major version of their applications and libraries and only backport security fixes. This vulnerability was only present in the 1.0.1 branch of openssl. RHEL/CentOS 5 provides the 0.9.8 branch. Same for Debian Squeeze (aka Debian 6). RHEL/CentOS 6 and Debian Wheezy (7) have openssl 1.0.1, which is vulnerable. It even lists right on the heartbleed site a number of distros that shipped the bad version and some of the ones that didn't.

    Since CentOS/RHEL 5 is still being maintained until 31 March 2017, and the only way to upgrade major versions of CentOS/RHEL is to reinstall... and you have to make sure any in-house code is compatible with the new versions shipped with the newer major release, which takes time... many shops don't update until closer to EOL of the old release. In this case, that saved us from having to deal with this particular major flaw.

    As for number 2, just because you get the private key, doesn't mean you magically can read all traffic going to the site. You ALSO have to execute a man in the middle attack to intercept the encrypted data in order to decrypt it. So this bug alone isn't going to expose everyones password and burn the Internet to the ground. It's a serious bug, and people should be concerned, but we don't need to resort to hysterics.

    @Lincoln‌ - Considering the error it's serving on https, I'd say the certs aren't configured properly. If it's not loading the right certs and keys, then this bug couldn't have exposed that data (it can't send data that is never loaded into memory)

    PirateNinjaJBoogalooBasil
  • MyrmidonMyrmidon Baron von Puttenham California

    @Ardi implying I'm resorting to hysterics is only mildly offensive. Passwords were compromised from an unknown number of services. Many people use unsanitized password schemes. Is this skmehow not worth changing passwords over?

    I'm also aware of the version mismatch between distros. So yes, to be fair, not the entire 66% that uses openssl is compromised, forgive me for being inaccurate in that respect. But its still a significant number. So what percentage of compromised servers do you feel like would warrant worrying about this as opposed to taking a blase "there's a slightly lower chance of trouble than this suggests therefore don't bother worrying even a little" stance?

    Also, good thing that man in the middle is extremely uncommon. Right?

    This doesn't expose EVERY PASSWORD on the internet. I never said it did. I gave the links you could look at for more info and a brief synopsis for those that didn't want to.

  • Straight_ManStraight_Man Geeky, in my own way Naples, FL

    I will just drop this here, decent summary of the problem:
    US CERT's take, as of today.

  • The only hysterical person here is Lincoln, who is ripping off a combined coffee and bourbon high. The last we heard of him, he was arguing with Ivan in bathroom about the pros and cons of switching Icrontic over to full time SSL.

    Ardi was just saying in general that you are right, people should be concerned -- but they shouldn't shit the diaper because there is a fair amount of work involved in gathering usable hacked data even with exploits as widespread as this.

    TushonJBoogaloo
  • Your original post is laced in hysterics. Nowhere did I say people shouldn't change their passwords, nor did I suggest people shouldn't use proper password policies (different, complex, passwords for every site people!). I have seen zero reports of passwords being compromised due to this bug thusfar. Passwords get compromised for other reasons all the time (brute force, poor security practices, sites not securing their logins with SSL, backups leaked, SQL injection, and any number of other reasons). I just said we don't need to blow this way out of proportion and say things like:

    So... your passwords? There is an EXTREMELY good chance that many of your passwords have been leaked in plaintext.

    That's just not accurate. There is a SLIGHT chance that SOME passwords may have been intercepted and decrypted if you have used them VERY recently AND been subject to a MitM attack. If you typically just log into things at home or at work, there's a pretty damn low chance this has happened to you (unless you have wide open wifi at home and/or an incompetent/malicious IT team at work). If you frequently use public wifi, the chances are higher, but still reasonably low given that, while MitM attacks aren't uncommon, they're not happening with the kind of frequency that you seem to think.

    basically anything you've ever typed into a secure webform since this heartbleed bug went into effect is very suspect.

    There has been no evidence that this has been exploited prior to the bug being publicly disclosed today. Unless we see evidence of a large uptick in peoples data being stolen, without some other explanation for why (i.e. - the people being exploited all having a certain company/site in common, suggesting that site was breached) then this is overstating the risk.

    For those of you who want a more down to earth view of this, here's what I'd suggest.

    1. If you do any online shopping in the coming days, do it from a safe location (ie - work or home, preferably on a wired connection).
    2. Keep a close eye on your bank accounts on the VERY UNLIKELY chance that your data does get intercepted.
    3. It wouldn't be a bad idea to change any passwords you've used recently from a public location (or just take this time to rotate any passwords you haven't changed in a long time). If you don't already use unique passwords, get LastPass, 1Password or KeePass (my personal recommendation) set up and change your passwords to unique ones. This is a general security practice that you should be using REGARDLESS of this bug.
    4. Use 2-factor authentication whenever possible.
    5. If you REALLY want to be paranoid, there are already tools out there which can test a site for this bug, run one or more on a site before logging in or inputting any data. If it's vulnerable, don't use that site until it is fixed. Some test methods:

    In short, the sky is not falling. Security on the 'net is not dead because of this bug. This is serious, but news reports are blowing this way out of proportion. Be a little more careful about sticking to security best practices and you will likely be just fine.

    JBoogalooStraight_ManGnomeQueen
  • MyrmidonMyrmidon Baron von Puttenham California
    edited April 2014
    1. Leaked, not intercepted. Said what I meant.

    2. Suspect, not OH SHIT THEY'RE GONE. The latter being hysteric, the former not.

    3. Nobody knows whether or not anything was compromised via heartbleed. There aren't any audit tools in wide use for the TLS heartbeat.

    You're right, you didn't say nobody change their passwords. But if you're going to use reductio ad absurdum on my argument, shouldn't I be allowed to use it on yours?

    I appreciate the rest of the useful information in your last response, though, that's very helpful.

  • d3k0yd3k0y Loveland, OH

    @Myrmidon said:
    reductio ad absurdum

    I know what this means from Big Bang Theory, you'd expect the four years of Latin I took to help.

    RahnalH102
  • LincLinc Bard Detroit

    Bruce Schneier: https://www.schneier.com/blog/archives/2014/04/heartbleed.html

    "Catastrophic" is the right word. On the scale of 1 to 10, this is an 11.

    Tushon
  • LincLinc Bard Detroit

    Obligatory XKCD: https://xkcd.com/1353/

  • LincLinc Bard Detroit

    It's breached "worth confusing/scaring my mom" territory. I've sent her a text to change her passwords.

  • MyrmidonMyrmidon Baron von Puttenham California
    edited April 2014

    EDIT: thought better of posting

    TeramonaCanti
  • CantiCanti =/= smalltime http://www.youtube.com/watch?v=y9K18CGEeiI&feature=related

    Three things I got from this thread.

    1. It's not about a new status effect in WoW like I assumed it was.
    2. Ardis gonna choke.
    3. I ain't even scurred.
    RahnalH102GnomeQueenGHoosdum
  • MyrmidonMyrmidon Baron von Puttenham California

    So, this just in, there was a type of server auditing heartbeats entirely by luck. They went back through their logs to see if any Heartbleeds had been attempted (trying to gauge whether or not the exploit has been used since it's been out, or if nobody noticed it).

    http://www.seacat.mobi/blog/heartbleed

    Heartbleed attacks have been sighted as far back as March. Effectively there is mounting evidence that passwords HAVE been leaked through this (Ars Technica at least), passwords CAN be leaked through this (proof of concept was Yahoo Mail), and the exploit was known about by some people for some time before it was made public.

    So if you can't remember the last time you've been in a Starbucks and logged into a secure server (because now there's proof that this has been going on for at least a few months, albeit likely on a small scale), YES, you SHOULD change your passwords.

    (DISCLAIMER) Just, you know, don't get hysteric about it.

    TushonRyanFodderPirateNinja
  • TushonTushon I'm scared, Coach Alexandria, VA

    I agree, @Myrmidon‌ :)

This discussion has been closed.