Hacker News Reader

Comment by fnsa | Hacker News Reader

This is scary:

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

View on HN

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.

This isn't my area, but why would Yahoo even have plaintext passwords in the first place? Shouldn't they only have hashes?

In this attack, data from the server process's address space is sent back to a malicious client.

Yahoo hopefully/presumably store only password hashes at rest, but just as in almost any system the user's real, clear password has to be sent from the user to the server to hash and verify against the database in order for the user to log in. Yahoo were following best practices by sending this password encrypted over HTTPS, but this vulnerability is a particularly insidious one because it actually punishes sites for doing the right thing in the form of encrypting traffic.

Because of the particular memory read using this attack and the memory layout Yahoo's service ended up with, other users' decrypted login traffic would get sent back to malicious clients with high frequency.

If I remember correctly, a browser add-in using TOTP could remove this as a viable attack method. By the time the user's one-time-encrypted login token is sent to the server it's been invalidated after login, and a new token is required, so siphoning off durable creds from memory becomes useless. However, you can still skim sessions.

Session skimming is definitely still viable, and is especially bad if the compromised service doesn't require an escalated / different session to disable 2FA.

Additionally, there's a chance an attacker could compromise the TOTP secret as well as it will probably be in memory around the same time (unless the system is using a keyserver or HSM). At that point, the whole setup is blown and the user's credentials could presumably be replayed.

If I understand it all correctly, wouldn't the secret key exchange have been potentially exposed as well? It had to traverse some medium from server to client (or in reverse) at some point, so an attack could plausibly have account information as well as TOTP secrets to perform full two-factor authentications in perpetuity, no?

It's worse than that. Since the server has to use the TOTP key/secret to generate the token for validation, there's a very high chance the secret will be in the server's process memory at around the same time as the first-factor credentials are, unless a separate keyserver or HSM is in use. This applies on every login, not just during the initial TOTP exchange / setup process.

Thus, the key exchange doesn't need to be exposed for heartbleed to have a good potential to leak TOTP/2FA secrets.

Well I suppose you're right, if you're using your bastion host as the TOTP operation service provider, but I wouldn't recommend that for a whole host of reasons - the main one being that the bastion host is always the first host exploited, so you shouldn't be running anything from there but a proxy.

You should be able to simply move the TOTP operation to an authentication server on a more secure network and have your web-application server query it with the user's token. The web app will get back the result of the operation and never expose the secret key to the bastion host.

Say I'm logging into flickr.com with my Google account - what's at risk in that case?

The data being read is the plaintext password being sent from the client. The standard login procedure goes like this:

1.) Client sends Plain text user/pass over SSL -> 2.) Server reads that info to memory -> 3.) Server hashes password and tests hash -> 4.) Server discards plaintext memory.

Whats happening here with heartbleed, is you are reading the RAM of the server, so before Yahoo even has the chance to hash the password, this exploit allows you to read the password.

Remember, even though Yahoo may only store the hashes in the database, your password (for any service) is still being sent effectively as cleartext.

The passwords did not come from the database (which should only have hashes stored) but from the http request send by the client during login (originally this was transmitted encrypted but leaked out due to the bug).

Give grep's -C option a try!

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.

seems to be patched now

yup it seems to have been patched soon after I posted, however quite a few from here are still vulnerable:

  https://github.com/musalbas/heartbleed-masstest/blob/master/top1000.txt

Reply on news.ycombinator.com