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

31–40 of 70 posts

Re: Hijacking user sessions with the Heartbleed vulnerability

#31

Post by quasque »

danielweber wrote: post #28
quasque wrote: post #21

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.

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.

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 if they're OpenSSL-based), i.e. look for ord(pay[-4]) == 0x0E rather than at ord(pay[0]).

Re: Hijacking user sessions with the Heartbleed vulnerability

#32

Post by danielweber »

M4v3R wrote: post #5
pearjuice wrote: post #2

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

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.

Someone broke into my yahoo account a month or two ago to send spam. I changed passwords quickly enough.

It was low-priority, but looking at the passwords that people have captured from yahoo's servers, I used a very very common password theme. Also, a lot of Yahoo users were born between 1970 and 1975.

Re: Hijacking user sessions with the Heartbleed vulnerability

#33

Post by danielweber »

mey wrote: post #30
danielweber wrote: post #26

Earlier quoted context omitted.

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 ."

It's unlikely that anyone would be logging that these network requests would be made, let alone the raw input/output. This level of network logging is typically only turned on briefly for diagnostics.

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 the top and at the bottom of the list were the most interesting.

Re: Hijacking user sessions with the Heartbleed vulnerability

#34

Post by orblivion »

pearjuice wrote: post #2

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

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.

Re: Hijacking user sessions with the Heartbleed vulnerability

#36

Post by smtddr »

quasque wrote: post #31
danielweber wrote: post #28

Earlier quoted context omitted.

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.

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

Re: Hijacking user sessions with the Heartbleed vulnerability

#37

Post by 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.

Re: Hijacking user sessions with the Heartbleed vulnerability

#38

Post by jsmthrowaway »

mey wrote: post #30
danielweber wrote: post #26

Earlier quoted context omitted.

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 ."

It's unlikely that anyone would be logging that these network requests would be made, let alone the raw input/output. This level of network logging is typically only turned on briefly for diagnostics.

Hell, it's unlikely that a network beyond a specific size can even log flows, much less data.

Re: Hijacking user sessions with the Heartbleed vulnerability

#39

Post by MetaCosm »

danielweber wrote: post #33
mey wrote: post #30

Earlier quoted context omitted.

It's unlikely that anyone would be logging that these network requests would be made, let alone the raw input/output. This level of network logging is typically only turned on briefly for diagnostics.

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.

Re: Hijacking user sessions with the Heartbleed vulnerability

#40

Post by 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.

Post reply on HN