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

61–70 of 70 posts

Re: Hijacking user sessions with the Heartbleed vulnerability

#61

Post by peterwwillis »

bri3d wrote: post #58
erichurkman wrote: post #55

Earlier quoted context omitted.

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

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.

Re: Hijacking user sessions with the Heartbleed vulnerability

#62

Post by smtddr »

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.

This isn't true in the home videogame console scene. I know for a fact in the Sony PSP hacking scene, the main hackers had a handful of kernel exploits but are very careful about using them since SONY usually released patched firmware less than 48hrs after the exploit is public.

They hope exploits carry forward into newer firmwares so that they can use them to find newer exploits introduced in that firmware so when they use the previous exploits, they can use the news ones when SONY patches the older and explore what SONY did to fix it; learn more about how SONY's devs think.

Re: Hijacking user sessions with the Heartbleed vulnerability

#63

Post by shock-value »

patio11 wrote: post #57
mixedbit wrote: post #42

Earlier quoted context omitted.

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…

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

No one is arguing against that. The point is that from the user's point of view, they shouldn't interact with a server at all if it is still vulnerable to this attack.

Re: Hijacking user sessions with the Heartbleed vulnerability

#64

Post by voltagex_ »

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.

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

Re: Hijacking user sessions with the Heartbleed vulnerability

#65

Post by kevjiang »

willvarfar wrote: post #37

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.

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

Re: Hijacking user sessions with the Heartbleed vulnerability

#66

Post by barrecan »

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…

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

Re: Hijacking user sessions with the Heartbleed vulnerability

#67

Post by jessriedel »

barrecan wrote: post #66
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…

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

Would it need to "access your data on all websites"?

Re: Hijacking user sessions with the Heartbleed vulnerability

#69

Post by mikeash »

tjohns wrote: post #44
mikeash wrote: post #7

Earlier quoted context omitted.

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

StartCom is the only site I know of that uses them for user authentication. The biggest problem is that the client-side UI is rather confusing, and you still need a separate authentication system in case the user loses their certificate (or switches devices).

You're right, I actually have an account with them and remember setting up the client-side certificate. I completely forgot about it afterwards. I would say that "rather confusing" is a deep understatement. The process, at least on the Mac, is atrocious and makes this method only suitable for the most advanced users, and even then only if you're willing to take on only the most enthusiastic.

Re: Hijacking user sessions with the Heartbleed vulnerability

#70

Post by 2bjorn »

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

you might also want to use [1] xmpp, starttls, proxy support with valid tls records, custom palyoad and stuff.. configurable via cmdline options.

[1] https://gist.github.com/tintinweb/10411753 | hb-test.py aka heartbleed.py

Post reply on HN