Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hijacking user sessions with the Heartbleed vulnerability

mattslifebytes.com

Post reply on HN
Print view View original

51–60 of 70 posts

Re: Hijacking user sessions with the Heartbleed vulnerability

#51

Post by lockes5hadow »

sinak wrote: post #40

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…

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.

Re: Hijacking user sessions with the Heartbleed vulnerability

#52

Post by apendleton »

sinak wrote: post #40

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…

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.

Re: Hijacking user sessions with the Heartbleed vulnerability

#53

Post by apendleton »

MetaCosm wrote: post #39
danielweber wrote: post #33

Earlier quoted context omitted.

Maybe, maybe not. If you are paranoid enough to have this attack in your toolbelt, how paranoid are you that your victim will be watching his traffic and/or request logs? If you have that kind of inside knowledge about your target you probably wouldn't need a tool like this. For fun and for research purposes, in the past I've set up SSL dumps that just log all the TLS commands and sort them by frequency. The ones at…

Exploit hording is counter-productive. Exploits only have value when used, they have no defensive or other value. Their half-life is not in your control, at any time they can stop being usable. Therefore the best course of action when you get an exploit is to use it whenever you can until it gets fixed.

There are limited circumstances when hording them might make sense; rumors are that there's been hording of XP vulnerabilities in anticipation of the support period ending, as using them pre-support might have meant that MS would have patched them, whereas saving them would presumably keep them unpatched forever.

But yes, generally you're right, and this circumstance is obviously different from that one.

Re: Hijacking user sessions with the Heartbleed vulnerability

#54

Post by bri3d »

peterwwillis wrote: post #49
bri3d wrote: post #47

Earlier quoted context omitted.

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 HT…

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.

Re: Hijacking user sessions with the Heartbleed vulnerability

#55

Post by erichurkman »

peterwwillis wrote: post #49
bri3d wrote: post #47

Earlier quoted context omitted.

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 HT…

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.

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?

Re: Hijacking user sessions with the Heartbleed vulnerability

#57

Post by patio11 »

mixedbit wrote: post #42
sinak wrote: post #40

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…

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.

That's a bit unworkable, particularly as you can get many sites to load a user into memory by putting a post-auth URL into an IMG tag anywhere on the Internet. Your browser will obediently GET that URL, passing along the session cookie to the legitimate server, where it will then be exfiltrated via heartbleed.

Basically: this vulnerability must be patched, or the server must be taken offline, and that needs to happen everywhere.

Re: Hijacking user sessions with the Heartbleed vulnerability

#58

Post by bri3d »

erichurkman wrote: post #55
peterwwillis wrote: post #49

Earlier quoted context omitted.

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.

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.

Re: Hijacking user sessions with the Heartbleed vulnerability

#59

Post by axisK »

smtddr wrote: post #36
quasque wrote: post #31

Earlier quoted context omitted.

Thanks for the information. I modified the script to request a different number of bytes. It seems that 16384 is too much and causes the server to abort sending, but lower amounts work to successfully dump memory. EDIT: The other thing is that it seems better to check for "Server Hello Done" at the end of the handshake message as some servers seem to send all submessages within one handshake message (though not sure…

For those that don't python and/or don't know where to edit. hb = h2bin(''' 18 03 02 00 03 01 40 00 ''') See that "40 00" there? That's hex and 0x4000 = 16384. Change it to something like "02 00", so it's 0x200 = 512, or 0x400 = 1024 ...or whatever you want.(But keep it at a power of 2... I assume). http://en.wikipedia.org/wiki/Power_of_two

As long as it's valid hex it should be fine, there seems to be a lower bound at which point servers don't respond but I didn't play around for too long with that part. Most articles also mention 64kb which the script can do with some small modifications.
Post reply on HN