
Hijacking user sessions with the Heartbleed vulnerability - sullivanmatt
https://www.mattslifebytes.com/?p=533
======
pearjuice
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 not abused in production environments the past two years?

~~~
M4v3R
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.

~~~
danielweber
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.

------
AaronFriel
There seems to be some confusion about the vulnerability on the client side,
which I think should be clarified. The Heartbleed vulnerability seems to only
affect OpenSSL clients and servers. The buffer overrun is only known to be in
OpenSSL, so other SSL clients should be unaffected.

Client web browsers are not affected because:

Firefox uses NSS on all platforms.

Chrome uses NSS on Linux or platform libraries for SSL _or_ uses NSS on all
platforms for SSL, and then uses the system libraries for other cryptographic
operations and certificate validation.

Platform-specific browsers (IE, Safari) likely use their platform's SSL code.

Almost every other mainstream browser is a derivative of one of the four
mentioned so far.

Edit: As another commenter pointed out, client-side consumers of the OpenSSL
library are likely affected as well. That means web spiders and server-side
code that uses web APIs are likely affected. That may or may not be
concerning, depending on the networks that traffic travels over and the method
of authentication.

~~~
bri3d
While client _browsers_ aren't generally affected, other clients may be. If
you have some form of web spider, or especially a web hook or callback service
which can accept an arbitrary URL, you could be exploited relatively easily.
This applies to language runtimes, too.

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

~~~
mixedbit
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.

~~~
patio11
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_.

~~~
shock-value
> 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.

------
blantonl
Wow, just piping the output from this proof of concept python script through
grep and searching for the string "pass" shows that on a number of sites that
are vulnerable it is _that_ easy to pull a logged in user's username and
password.

Scary...

~~~
danielweber
Although there are no guarantees there, what you are likely getting is people
_logging in very recently_ because their POST request is still in memory. If
you were just logged in with an old session from a few hours ago, it's
unlikely your PUSH request will still be in memory.

But every time you connect you are sending a cookie which allows for session
hijacking.

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

~~~
justincormack
Anyone seen any evidence of attempts to do this, or set up honeypots?

------
fnsa
This is scary:

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

~~~
bri3d
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.

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

~~~
bri3d
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.

~~~
peterwwillis
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.

~~~
erichurkman
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?

~~~
bri3d
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.

~~~
peterwwillis
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.

------
rbobby
Dollars to donuts the NSA has had this hack in its bag of tricks.

~~~
danielweber
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_."

~~~
mey
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.

~~~
danielweber
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.

~~~
MetaCosm
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.

~~~
apendleton
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.

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

~~~
danielweber
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.

~~~
quasque
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]).

~~~
smtddr
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](http://en.wikipedia.org/wiki/Power_of_two)

~~~
axisK
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.

------
Bootvis
For SSH it's common to use private keys to communicate securely with servers
using public key cryptography. This is convenient and protects against key
loggers.

What are the possibilities of using public key cryptography in the browser?
For example, I upload my public key to some website, create an account which
is locked to my private key. I get the convenience of not having to log in
manually and some extra safety.

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

~~~
tjohns
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).

~~~
mikeash
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.

------
joshfraser
python heartbleed.py okcupid.com |grep -C3 username=

------
mykhal
on some servers you can even get the credentials themselves :)

------
Cthulhu_
TRWTF is how Jira doesn't apparently check if the session id is coming from
the same computer (a simple ip address check for example). Pretty sure most
sites are secure against cookie (and thus session) takeovers.

------
danielweber
What tool is he using for editing his cookies?

~~~
kaeruct
EditThisCookie extension:
[https://chrome.google.com/webstore/detail/editthiscookie/fng...](https://chrome.google.com/webstore/detail/editthiscookie/fngmhnnpilhplaeedifhccceomclgfbg?hl=en)

------
sinak
Running the exploit and all I see are session IDs. Has anyone seen any
passwords being output?

~~~
axisK
On my first run today I saw some passwords going to the admin section on our
staging servers so it really depends on what you're targeting.

------
labguy10001
It's not a vulnerability. It's a BACKDOOR.

~~~
choult
I don't believe there's any evidence on that yet, so please cool your jets.
One dev wrote that line of code but anyone could have made that mistake.

