Hijacking user sessions with the Heartbleed vulnerability

[pearjuice]

This is one of these things of which you think "Ah, what are the odds of me being affected?" but quickly changing to "This is pretty bad..." and finally to "FUCK FUCK FUCK, WHY?".

Two years is a long time, people. If ordinary people can write proof of concepts in less than 24 hours after it is publicly disclosed, what to think of those getting paid to find and abuse such bugs? I mean, what are the odds this bug was not abused in production environments the past two years?

[M4v3R]

It might be a coincidence, but last month I received an alert that someone tried to sign in to my hosting control panel using a correct password (which was long and random), but was blocked by a geo-filter (which blocks requests outside of my country) fortunately. I do not know up to this day how my password did leak, and that's one possible candidate cause.

[orblivion]

Really I can only assume that there are plenty of other bugs out there. It's just a matter of how few people know about any of them. I dunno, keep your secrets close. PGP. Meh.

[AaronFriel]

There seems to be some confusion about the vulnerability on the client side, which I think should be clarified. The Heartbleed vulnerability seems to only affect OpenSSL clients and servers. The buffer overrun is only known to be in OpenSSL, so other SSL clients should be unaffected.

Client web browsers are not affected because:

Firefox uses NSS on all platforms.

Chrome uses NSS on Linux or platform libraries for SSL or uses NSS on all platforms for SSL, and then uses the system libraries for other cryptographic operations and certificate validation.

Platform-specific browsers (IE, Safari) likely use their platform's SSL code.

Almost every other mainstream browser is a derivative of one of the four mentioned so far.

Edit: As another commenter pointed out, client-side consumers of the OpenSSL library are likely affected as well. That means web spiders and server-side code that uses web APIs are likely affected. That may or may not be concerning, depending on the networks that traffic travels over and the method of authentication.

[bri3d]

While client browsers aren't generally affected, other clients may be. If you have some form of web spider, or especially a web hook or callback service which can accept an arbitrary URL, you could be exploited relatively easily. This applies to language runtimes, too.

[sinak]

Recovery process for this seems like it would be:

- All affected sites need need to update OpenSSL, reissue certs, tell users to update their passwords.

- All users need to reset their passwords, using a unique password for each site if possible. If they can't feasibly use unique passwords for each site, they need to make sure they don't use their new password on sites that aren't fixed yet.

That's pretty crazy, and getting anything close to 100% compliance is going to require a ton of visibility.

Someone should make a browser extension as quickly as possible to tell users if they're visiting a yet-unfixed site.

[mixedbit]

The problem is also that as long as a vulnerable site is not fixed, users should not attempt to login or interact with such site while logged in. Such interactions increase chances that users' cookies or passwords will be in servers memory.

[lockes5hadow]

And how would a browser extension do that reliably? Someone who has exploited a Bleeding Heart server would have their cert and could then impersonate the server using a patched OpenSSL.

[apendleton]

Recovery should also probably include nuking all current sessions, as any session key created prior to updating is potentially compromised and would remain so after the update.

[barrecan]

There is already an extension for chrome called "Chromebleed", https://chrome.google.com/webstore/detail/chromebleed/eeoekj...

[blantonl]

Wow, just piping the output from this proof of concept python script through grep and searching for the string "pass" shows that on a number of sites that are vulnerable it is that easy to pull a logged in user's username and password.

Scary...

[danielweber]

Although there are no guarantees there, what you are likely getting is people logging in very recently because their POST request is still in memory. If you were just logged in with an old session from a few hours ago, it's unlikely your PUSH request will still be in memory.

But every time you connect you are sending a cookie which allows for session hijacking.

[gatehouse]

Yeah, up until very recently it would be possible to make a script that would log you into a random yahoo mail account. For vulnerable servers right now it would be better to just block port 443, forcing regular HTTP is safer.

[willvarfar]

A malicious server can also read the memory of a client using the same heartbleed vulnerability.

So the -NSA-mafia can go get the private key from a vulnerable server, MitM its clients, and attack those clients too.

Nasty stuff. And in the last day, even those agencies that didn't know about the vulnerability beforehand have likely spidered the entire web scraping everyone's keys just-in-case.

[justincormack]

Anyone seen any evidence of attempts to do this, or set up honeypots?

[kevjiang]

In fact, an attacker doesn't even need to steal the private key.. Heartbeats can be sent before certificate authentication takes place.

[fnsa]

This is scary:

  # ./hb-test.py mail.yahoo.com |grep -A3 -B3 pass

[bri3d]

What's potentially scarier than plaintext passwords leaking out is that key material leaks as well.

64k of random memory is bad, 64k of OpenSSL's state is worse.

Also, why haven't Yahoo taken down their login service yet? I really don't see how leaving your users' passwords leaking in plaintext is ever better than downtime. Someone had to have made that call, and I really don't think it was the right one. Will be interesting to see how the media treats this over the next few days.

EDIT: Looks like Yahoo is finally fixed. Wonder how many accounts were compromised in the interim, and if their cert and private key were compromised as well. Does not look like they've re-issued yet.

[praseodym]

Give grep's -C option a try!

[3JPLW]

Scary indeed. Has anyone created a status-board kind of site to show which major servers were affected and which are still affected?

I'd like to start changing passwords, but it doesn't do much good until things are fixed.

[rabino]

seems to be patched now

[rbobby]

Dollars to donuts the NSA has had this hack in its bag of tricks.

[higherpurpose]

Maybe it will be easier to look through the Snowden documents for this, now that we know about it, and see if they had it.

[danielweber]

But using it would reveal it if anyone was capturing traffic of SSL requests. "Why in the world did they do a heartbeat test . . . hey, what's all that stuff . . . OHMIGOD."

[quasque]

Is the vulnerability, or this script to exploit it, platform-specific? I tried this script against a Raspberry Pi running Raspbian with an unpatched OpenSSL library, but received an unexpected EOF.

[danielweber]

If your webserver has the vulnerable version of the OpenSSL library, then your server will return some extra bytes, from someplace in memory.

It may turn out that the space in memory it's returning from is useless. Or, like yahoo, you may be giving out plain-text ASCII passwords to complete strangers who can type a command line. Which of these two extremes you get is largely based on luck.

[Bootvis]

For SSH it's common to use private keys to communicate securely with servers using public key cryptography. This is convenient and protects against key loggers.

What are the possibilities of using public key cryptography in the browser? For example, I upload my public key to some website, create an account which is locked to my private key. I get the convenience of not having to log in manually and some extra safety.

[dfc]

It is possible and has been for some time. Like many other PKI systems it is a pain in the ass to configure on the server (atleast it was with apache) and teaching/getting users to generate keys is a nightmare.

[mikeash]

I believe what you're describing is encompassed by SSL client certificates. They're supported, but roughly nobody uses them for some reason.

[joshfraser]

python heartbleed.py okcupid.com |grep -C3 username=

[mykhal]

on some servers you can even get the credentials themselves :)

[Cthulhu_]

TRWTF is how Jira doesn't apparently check if the session id is coming from the same computer (a simple ip address check for example). Pretty sure most sites are secure against cookie (and thus session) takeovers.

[danielweber]

What tool is he using for editing his cookies?

[kaeruct]

EditThisCookie extension: https://chrome.google.com/webstore/detail/editthiscookie/fng...

[sinak]

Running the exploit and all I see are session IDs. Has anyone seen any passwords being output?

[axisK]

On my first run today I saw some passwords going to the admin section on our staging servers so it really depends on what you're targeting.

[labguy10001]

It's not a vulnerability. It's a BACKDOOR.

[choult]

I don't believe there's any evidence on that yet, so please cool your jets. One dev wrote that line of code but anyone could have made that mistake.