
Heartleech: Automated OpenSSL private key extraction tool using Heartbleed - FredericJ
https://github.com/robertdavidgraham/heartleech
======
danielweber
_This should be a useful tool on its own, but I wrote it primarily because the
pattern-matching rules for Snort are inadequate. IDS vendors won 't fix their
stuff until I can prove they are inadequate._

Ugh. In the old days the mantra of full-disclosure was "well, if we don't make
exploit tools, then the vendors won't issue patches." And then it became
"well, if we don't make exploit tools, then the sysadmins won't patch."
Apparently the bar has sunk so low that people personally pushing out Snort
rules on snort-users aren't actually catching all instances of the bug is the
justification for releasing tools to steal private keys.

In reality, lots of people in the security community just like seeing chaos in
the world, because it makes for even more news headlines and in their mind
this increases the status of the security community. Then it's time for the
_post hoc_ justifications for their behavior.

~~~
eli
I would imagine the motivation is less about money and more about having fun
breaking stuff (and bragging rights).

I agree though. Hard to argue that this particular security issue needed any
extra attention in order to get it fixed.

~~~
danielweber
One of the biggest root causes of problems in the security industry is that
often the only way to make a name for yourself is to cause pain to others.
(It's not too hard to convince yourself that those others deserved it.)

If you went back in time two years and fixed the Heartbleed bug, no one would
be writing newspaper articles about you.

~~~
robertgraham
Nobody is writing articles at Neel Mehta, the guy who discovered the bug. They
should, he's a god.

------
neals
I have a few ubuntu servers. When I do a "check for heartbleed" check with
various tools, it says they are not vulnerable. However, these servers were
installed 6 months ago and not updated for at least 2 months. How can they not
be vulnerable?

~~~
nikcub
Most reports about Heartbleed kept repeating that the vulnerability was
introduced 2 years ago (Dec '12, which isn't even 2 years - but anyway) it was
committed to a version of OpenSSL (v1.0.1) that wasn't widely distributed
until the middle of last year.

The time surface of the Heartbleed attack is a lot smaller than what most
think. Debian and the BSD projects moved to v1.0.1 earliest, around
March/April last year.

Ubuntu only upgraded two months ago (in 12.04.4) on the 6th of Feb:

[http://fridge.ubuntu.com/2014/02/06/ubuntu-12-04-4-lts-
relea...](http://fridge.ubuntu.com/2014/02/06/ubuntu-12-04-4-lts-released/)

Redhat with 6.5 in November 2013:

[https://access.redhat.com/site/documentation/en-
US/Red_Hat_E...](https://access.redhat.com/site/documentation/en-
US/Red_Hat_Enterprise_Linux/6/html/6.5_Release_Notes/bh-chap-security.html)

CentOS Feb 26th 2014:

[http://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.5](http://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.5)

~~~
awda
Fedora has been on OpenSSL 1.0.1 since maybe March 14, 2012 (that was when the
.spec was bumped, anyway)[0]. So quite a long window for Fedora users,
unfortunately.

[0]:
[http://pkgs.fedoraproject.org/cgit/openssl.git/commit/?h=f18...](http://pkgs.fedoraproject.org/cgit/openssl.git/commit/?h=f18&id=0f0ab241767afcda7d3a21a5b8e7bc770516f2ea)

~~~
awda
Whoah, downvote for this? I thought this was factual and helpful... if you
disagree, can you at least let me know what's wrong? Thanks.

For more details: Fedora 18 shipped with OpenSSL 1.0.1c on 11-Sep-2012:
[http://mirrors.kernel.org/fedora/releases/18/Everything/x86_...](http://mirrors.kernel.org/fedora/releases/18/Everything/x86_64/os/Packages/o/).
So that's 18 months of exposure for Fedora users (including me).

------
jameshart
While I know private keys are important and you really don't want to leak
them, I have to wonder if the security community's focus on the private keys
as the crown jewels that heartbleed accesses is a little misplaced.

If someone can steal your private key, yes, they can now impersonate your SSL
server. For HTTPS, they'll need to actually perform a DNS spoof or similar to
truly exploit that change, though. I guess there might be more of a concern
about things like DKIM keys being stolen. We have to be a little less trusting
of SSL certs to verify identity.

But in all this fuss about the keys, we seem to be forgetting that the
heartbleed vulnerability allowed attackers to sniff random cleartext as it
passed through OpenSSL. Session identities, usernames, passwords, sure - but
again, the security industry focuses on credentials being stolen as the worst
case scenario. But what about all the other private data going across the SSL
connection?

This reminds me a little of the focus on operating system security preventing
privilege escalation, while ignoring the risk of malware trashing all of a
user's own data - you might lose all your photographs, but at least the device
drivers will be safe.

When it comes to heartbleed, users might legitimately fear that data they sent
over SSL could have been eavesdropped by anybody; but the security industry
doesn't seem to care about that as much as it does about whether the private
key could have been compromised.

~~~
NoodleIncident
Preface: I don't understand this stuff much at all.

I was under the impression that stuff gets encrypted with the public key, and
can only be decrypted with the private key. Doesn't owning the private key let
you snoop on all traffic, all of the time, forever until they change the keys?

~~~
robertgraham
You still have to be in a spot to snoop. If you are a random hacker wanting to
snoop on a Russian bank, once you get their private key, you have to now tap
into the network. This is unlikely to be within your ability. You might fly to
Russia and sit in cybercafe's open to catch people on the open WiFi, but it's
not something that's easy.

On the other hand, as the above comment says, you can use heartbleed in other
ways, such as catching people's cookies from memory, then insert those cookies
into your own browser and hijack their connection.

Among the things I'm famous for is having written a proxy server you can aim
your browser through in order to do cookie hijacking:
[https://github.com/robertdavidgraham/hamster/](https://github.com/robertdavidgraham/hamster/)

------
chronid
Well, with the exploits for this vulnerability now showing up everywhere i
_almost_ feel bad for the people that still have not-patched servers lying
around.

~~~
jhardcastle
Feel no pity whatsoever for the sysadmins. Feel pity for the users, who are
unwittingly using a vulnerable service.

~~~
danielweber
Maybe the sysadmin took a vacation. Fuck him, why should he spend time with
his family?

~~~
aroch
Well if you're the only sysadmin for a company and they let you travel without
the ability to both contact you and have emergency work done, you're pretty
lucky. I would hope no company would let their one and only fulltime sysadmin
take a vacation without having backup personnel on-hand

~~~
danielweber
Not every company in the world has sysadmins three levels deep. Lots of
companies don't even have sysadmins _one_ level deep.

------
uuid_to_string
It could be just my perception but it seems like the authors of Heartbleed
exploit code are focusing on www and email servers.

Doesn't OpenVPN use OpenSSL?

~~~
trebor
I believe so, yes. It often provides a certificate with the configuration
settings. Many screen sharing and remote access tools use some form of TLS/SSL
too.

------
happyscrappy
Will these automated tools work on vulnerable Android devices? If so this
seems a little irresponsible, I mean it is one thing to stick it to lazy
sysadmins but making it easy to exploit peoples phones seems evil.

~~~
Pxtl
I'm confused how openSSL on Android is a problem... isn't openSSL a server
technology? Do the clients use a heartbeat for something?

Or is this only relevant when you're running a server on your client device?

Is OpenSSL always running as a server on Android?

~~~
eli
Heartbeat goes both ways. If you can be tricked to accessing a malicious HTTPS
server, it can extract data from the _client_.
[http://blog.meldium.com/home/2014/4/10/testing-for-
reverse-h...](http://blog.meldium.com/home/2014/4/10/testing-for-reverse-
heartbleed)

~~~
Pxtl
... wow, the media firestorm around heartbleed was so fixated on the server-
side issue that this completely slipped by me. I guess it's only relevant to
one particular Android version and a handful of Linux-based versions where
patching is expected to occur automatically and quickly, and nobody cares
about desktop Linux.

~~~
eli
I wonder how many different ways you can trick a server into accessing a HTTPS
site. Seems like lots of services check links in comments or load remote
images or run webhooks...

I can definitely see how a server could slip through the cracks if it has a
broken HTTPS client, but the site it's serving is fine. No automated scanner
is gonna pick that up from the outside.

