Linked by Thom Holwerda on Tue 8th Apr 2014 22:06 UTC
Privacy, Security, Encryption

Heartbleed, a long-undiscovered bug in cryptographic software called OpenSSL that secures Web communications, may have left roughly two-thirds of the Web vulnerable to eavesdropping for the past two years. Heartbleed isn't your garden-variety vulnerability, so here's a quick guide to what it is, why it's so serious, and what you can do to keep your data safe.

Serious.

Thread beginning with comment 586720
To read all comments associated with this story, please click here.
I found a better link covering the attack
by Priest on Wed 9th Apr 2014 01:12 UTC
Priest
Member since:
2006-05-12

It's available here: http://arstechnica.com/security/2014/04/critical-crypto-bug-exposes...

At first I thought Heartbleed or CVE-2014-0160 was just about being able to decrypt SSL messages without needing a man in the middle on the session but that's not the case.

It allows an attacker to return data from the servers memory that could be ssl keys or data like user/passwords of users communicating with the server.

Most importantly: It does not require being able to intercept a users traffic to obtain their login credentials.

I could exploit an unpatched server and it will freely offer up user/pass combos of people communicating with it. It is a much much more serious vulnerability than simply allowing me to decrypt traffic I had to capture on the wire.

Reply Score: 3

Lennie Member since:
2007-09-22

I could exploit an unpatched server and it will freely offer up user/pass combos of people communicating with it. It is a much much more serious vulnerability than simply allowing me to decrypt traffic I had to capture on the wire.


Euh... well, it's a bit more complicated than that.

You can't tell the server what data you want.

The library on the server copies a part of memory of the same process and sends it to the client.

So you can't predict what you get and you might not even know what you got. It's just some a random block of data.

Now let's take some examples, a PHP-website. On the server we have 3 types of installations if they use nginx or Apache.

nginx or Apache with FastCGI like PHP-FPM would mean that all the data of the application isn't in the server process. So it should be pretty safe.

The webserver process might contain small chunks that are being send to users (which could contain a session-IDs) if you are using nginx or an Apache threaded/worker model (no prefork).

In the case of Apache with prefork and maybe mod_php, probably the only data the process has is for your own connection (read: boring information).

So if you look at these examples username/password isn't very likely. Session-ID maybe, SSL-private key maybe. Maybe even just a part of it and would you be able to recognize it ? As a key is just a blob of random data. Most likely just some random boring memory.

Should server operators patch: Yes, should they replace SSL certificate keys ? Yes.

Did bad things happen ? We don't know.

Reply Parent Score: 5

Priest Member since:
2006-05-12

A couple of people published that they were able to successfully fetch usernames and passwords from yahoo mail. There is a screenshot of one of the examples in the link I posted.

Because login/password are known fields you would be able to query the server in bulk and grep through the data for those strings knowing the data after it would be the actual credentials.

Here is an example of what I mean: http://i.imgur.com/GL2J8O8.png

You could build a database of user/pass combos with some fairly simple shell scripts.

Edited 2014-04-09 20:38 UTC

Reply Parent Score: 3