Heartleech: Automated OpenSSL private key extraction tool using Heartbleed

https://github.com/robertdavidgraham/heartleech

by FredericJ • 12 years ago

114 74 12 years ago

chronid• 12 years ago

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• 12 years ago

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

danielweber5• 12 years ago

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

neals4• 12 years ago

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?

slashdotaccount• 12 years ago

Maybe they use the GNU TLS library.

fit2rule• 12 years ago

You might want to rely on some other tool to determine if you are vulnerable or not. Or, just fix it yourself:

http://www.ansoncheunghk.info/article/3-simple-steps-update-...

neals4• 12 years ago

I ran some of the exploits that were floating around against my own servers and against known vulnerable servers. I got nothing from mine, but lots of scary stuff from the others.

VeejayRampay• 12 years ago

I am not an expert on the topic by any means, but one possibility is that older versions of impacted software are simply not vulnerable.

tsenkov• 12 years ago

Yep, older versions of OpenSSL are not vulnerable.

neals4• 12 years ago

Ok, so I am rewarded for not having an up-to-date system. How about that...

gokhan• 12 years ago

Are you http only?

neals4• 12 years ago

no I've got SSL certificates and https set up

rmc• 12 years ago

Older versions of OpenSSL were not vulnerable. Noticable 10.04 is not vulnerable.

dspillett• 12 years ago

How can they not be vulnerable?

It very much depends which variant you have installed. 10.04 is not vulnerable at all as it runs with 0.98.something (with some backported fixes, not including the exploit). 12.04 was vulnerable (it carries OpenSSL v1.0.1). There is a very similar situation with Debian's OldStable and Stable, and no doubt with the stable/long-term-support releases from RedHat and everyone else.

It also depends what they are testing: some things might be complied against GNUTLS instead of OpenSSL. That has had a vulnerability in recent months too, but is completely unaffected by this one.

If you are not using HTTPS (or other TLS wrapped protocols) at all on those servers then you are never going to be susceptible to this particular attack at all. OpenSSH apprently does not use OpenSSL in a manner that exposes he problem, so if all you expose is HTTP and SSH then you are fine (though if your users are sending anything sensitive over plain HTTP they are at risk from other problems).

nikcub• 12 years ago

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

Redhat with 6.5 in November 2013:

https://access.redhat.com/site/documentation/en-US/Red_Hat_E...

CentOS Feb 26th 2014:

http://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.5

awda2• 12 years ago

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

acqq• 12 years ago

It's apparently Dec 2011 not Dec 2012, if we look at the date of the now famous commit:

http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817...

"Sat, 31 Dec 2011 22:59:57 +0000

Support for TLS/DTLS heartbeats. 20 files changed"

LukeShu• 12 years ago

    > 2 years ago (Dec '12, which isn't even 2 years - but
    > anyway)

It was Dec 31 '11, not '12, that the commit was made--more than 2 years ago. It first appeared in the OpenSSL 1.0.1 release; March 14, 2012.

I don't know what's up with the timestamp on the Ubuntu announcement, but 12.04 was released in April 2012.

However, that's before the OpenSSL 1.0.1 date; the Ubuntu 12.04.4 update for openssl 1.0.1-2ubuntu1 came on March 22, 2012.

No matter how you slice it, that's more than 2 years.

Edit: Ubuntu 12.04 was April 2012, but the 12.04.4 point-release was released at the later date; that's where the 2014 date came from. 12.04 included OpenSSL 1.0.1 before that.

lstamour3• 12 years ago

Some builds of nginx linked to earlier libssl releases. This sort of software-level rather than system-level version difference can explain why upgrading "openssl" packages may be insufficient to prevent attacks. Upgrade "libssl" also. To see which version of libssl your stack uses, see ldd and strings: http://nginx.com/blog/nginx-and-the-heartbleed-vulnerability...

danielweber5• 12 years ago

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.

eli3• 12 years ago

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.

danielweber5• 12 years ago

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.

makomk2• 12 years ago

It's quite easy to argue that actually. People pointed out that those Snort and other IDS rules were inadequate as soon as they were released, yet it hasn't stopped vendors from claiming they offer protection.

vezzy-fnord3• 12 years ago

I, for one, am glad that a good chunk of the security community still has its old Wild West spirit of "anarchy and chaos" that was present back during the early hacker groups of the '80s and '90s. In addition to the existence of tons of highly casual security conventions (compared to the strict cons for programming languages and frameworks), it shows that many have not forgotten their roots, and have not succumbed to becoming a false, dishonest corporate face, just so they can look like ideals that they are not.

By the way, this isn't really related to or damning of the concept of full disclosure in any way. It still remains the most widespread philosophy. The CVE lists would be drastically smaller, if it were otherwise.

_delirium• 12 years ago

In addition to the existence of tons of highly casual security conventions (compared to the strict cons for programming languages and frameworks)

There are plenty of casual PLs conventions, meetups, hackathons, unconferences, just about any format you want. If anything I think that community is more welcoming and casual than the computer-security convention scene, which has a heavy tilt towards big-money, "rockstar" conferences like DEF CON and Black Hat, full of corporate and government presenters and attendees. There are conferences like that outside of security, like videogames (E3, GDC), but security really takes it to ridiculous levels, even holding the damn things in places like Las Vegas and Abu Dhabi.

What that portion of the security scene's image most reminds me of outside tech is the rockstars they'd like to be: a manufactured pretense of "anarchy and chaos" sold as a business's brand image.

dendory• 12 years ago

In this particular case, the bit about IDS isn't that ground breaking, it's just that the IDS checks for the malformed heartbeat request at the start of a packet, so instead he sends it at the end of a packet, namely appending it to the SSL handshake request. It's not like any hacker ever won't figure it out. I do agree with responsible disclosure for actual security holes, but this isn't it.

Xylakant• 12 years ago

Granted, this is weapon grade quality. However, most checks for heartbleed out there could be considered weapon grade or at least not far off[1], this one does not add anything a somewhat experienced developer could not have added. This time, the bug is just too clear, too easily exploitable. I appreciate that someone saw the IDS signatures were inadequate and wrote a proof showing that.

[1] hey, they read some bytes of server memory, it's fairly simple to move on from there and read more.

djcapelis3• 12 years ago

Granted, this is weapon grade quality

No. Stop.

A good security tool that does what it says and means what it says is just a good tool that does what it says and means what it says. There is no "weapons grade" or not "weapons grade" tools. I've seen people pop boxes with netcat and a keyboard. I've seen people fail to pop boxes with the best fucking attack framework you could put in their hands. Nothing is "weapons grade" and code isn't a weapon.

Leave the weapons grade labels to radioactive isotopes where they actually have real meaning.

Calling some types of code weapons grade is a huge bad thing.

djcapelis3• 12 years ago

Everytime someone writes a tool to show what is possible in public, there's some jerk giving them a hard time about it. Don't be that jerk. The function of the security community is to help people realize when they're not safe. No one likes having their bubble burst, but it's important that it get burst or people don't fix the problems. We've seen this over, and over, and over. Find a good way to improve security that is nicer for everyone involved and actually works and a lot of people in the community will listen and will legitimately care, promise.

larrys• 12 years ago

"The function of the security community is to help people realize"

You say that because you are not on the other end of this and don't suffer any of the consequences as a result of the actions of people who create some of these things which make it for sure easier for more people to exploit systems.

Please don't take this as an attack but your perspective is based upon your job [1] and your apparent lack of exposure to how people have to scramble and are actually impacted by certain types of disclosures. I mean the end users of the technology. Who in no way are in a position to get the vendors to do anything or make things more secure, in general.

This is for sure different from vendors and developers needing to write secure code and not make mistakes.

So have a bit of empathy. Not appropriate to call parent commenter, imo, a "jerk".

[1] "I'm a hacker in the computer science department at the University of California"

simias• 12 years ago

Meh, do you think "the bad guys" waited for this guy to publish his tool to make their own version?

I agree his justification is a bit weak, but in my opinion he doesn't need any justification at all, if you haven't patched your OpenSSL version yet you're no more vulnerable today than you were tomorrow IMO, it's already too late.

It's not like he released a 0-day exploit into the wild.

tsaoutourpants• 12 years ago

the bad guys

You mean the NSA?

rdl• 12 years ago

End users are more likely to pressure their vendors for better security in the future if they suffer more pain today.

clogston2• 12 years ago

"End users are more likely to pressure their vendors for better security in the future if they suffer more pain today."

Your statement is true, but surely there's a better and less damaging way to reach the end goal? e.g., if I run over someone with my car and they're saddled with life-long medical bills, they're more likely to call their Congressman and demand a better healthcare system.

deeviant2• 12 years ago

Sunlight truly is the best disinfectant. The fact is, there are already people writing such tools and actively attempting to compromise systems with it. If the attack vectors are not released to public and made a big hub-bub of, sysadmins are likely to either not be aware of the proper countermeasures and/or not be allocated the resources and time to fix the issue.

Ignorance is not bliss, nor is it security.

diminoten• 12 years ago

This smells of anti-sec nonsense to me.

More information is always, always better, and hiding information and implementation has been proven, over and over again, to not work, and to piss people off.

robertgraham6• 12 years ago

This isn't true.

One of the things I'm famous for is creating "BlackICE" 15 years ago, an intrusion-detection technology that we shipped as a variety of products, such as a personal firewall, gigabit IDS, and inline protection (i.e. intrusion-prevention-system or IPS).

The distinguishing feature of this technology is that we wrote "protocol-decodes" for everything. This made the product faster, able to catch more things, yet producing fewer false-positives. It's a vastly better technique than Snort-style pattern-matching.

Yet, it was an uphill battle convincing the market of this. That's because people are stupid and don't understand how things work well enough to appreciate the difference. All they know is that they download a public exploit, run it, and if the IDS catches it, then the IDS is good.

Today, there are lots of commercial products that do things the right way, with protocol decodes. There is also the open-source "Bro" project which does things the right way. All these products can catch my heartleech tool -- it can't evade tools doing things the right way.

Even Snort often does things the right way, but only when people like me prod them. They are going to add an SSL decode (I predict).

So the upshot is this: I really are about the difference between protocol-analysis and pattern-matching in IDS technology, and as long as people like you aren't smart enough to understand the difference, I'm going to keep releasing exploits to demonstrate it. None of my exploits evade properly written IDS -- only IDS that takes shortcuts.

tptacek2• 12 years ago

I don't think I had a problem with "heartleech" until I read this comment. What exactly does Snort's TLS decoding have to do with extracting private keys from servers? That's not the bug. The bug is OpenSSL leaking memory when it receives a malformed TLS heartbeat. You could have demonstrated that without publishing "find_private_key()".

I think you published this because it was fun to write. "Auto pwn", as you call it, has nothing to do with convincing Snort to do anything.

I don't believe you agree with Daniel Weber's argument at all. Don't dodge it by making things up. Engage with it directly. I wouldn't think it would be that difficult for you to knock down.

anizan• 12 years ago

Illusion of security is worse than being insecure.

I hate seeing a green lock sign next to the url in my browser. I am amazed Snowden didn't leak anything about root CAs.

happyscrappy• 12 years ago

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.

Pxtl2• 12 years ago

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?

larrysilverman• 12 years ago

Android 4.1.1 is the vulnerable version. Google says only 4.1.1 is vulnerable. There are a handful of services on Android that use openssl and, I suppose, could present open ports for there to be an attack vector. See http://www.pcmag.com/article2/0,2817,2456507,00.asp

eli3• 12 years ago

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

sp332• 12 years ago

You can check for vulnerable clients using this site https://reverseheartbleed.com/

lawnchair_larry• 12 years ago

No, OpenSSL is equally for clients and servers. It's a general purpose crypto library. You can use it in anything to do with crypto.

makomk2• 12 years ago

Don't think so, but some of the other tools out there probably would.

uuid_to_string• 12 years ago

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• 12 years ago

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.

jameshart• 12 years ago

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.

deeviant2• 12 years ago

"If someone can steal your private key, yes, they can now impersonate your SSL server."

I don't understand this comment. If they steal your private key, they can impersonate the client and do everything the client can do. I don't understand the "impersonate the SSL server".

If they steal the public key, then they can impersonate the server.

nitrogen2• 12 years ago

No, you can't do anything with a public key. Public keys are meant to be public. You might be confusing session keys, public keys, and private keys.

lstamour3• 12 years ago

Not an expert, but I'll attempt an answer: "your private key" refers to the server's key. The public key is already available. What gives a connection the lock icon is the verification of the public key by verifying signatures to recognize that the correct private key was used. In this diagram, the private key we refer to is the red key symbol on the far right: http://upload.wikimedia.org/wikipedia/commons/9/96/Usage-of-... In this diagram, ignoring TLS for the moment, what we care about is the purple box. That represents the kind of verification we have of a server's web traffic -- the purple box is the response from the server. The public key is shared and anyone can get a copy by asking, that's how they know where the certificate came from -- that it came from a valid CA -- the problem is that if anyone can get access to the red key (or the green key from earlier), they can impersonate a certificate because to the encryption, they are valid, the signatures match. It's like someone stealing your password or PIN code. The private key just happens to be much longer than that.

NoodleIncident• 12 years ago

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?

lstamour3• 12 years ago

Depends.

This might be useful here: https://www.eff.org/deeplinks/2014/04/why-web-needs-perfect-...

If really interested in the topic, Google the acronyms on this page: http://www.certificate-transparency.org/comparison

robertgraham6• 12 years ago

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/

Heartleech: Automated OpenSSL private key extraction tool using Heartbleed

Related Stories