Heartleech: Automated OpenSSL private key extraction tool using Heartbleed | Hacker News Reader

Heartleech: Automated OpenSSL private key extraction tool using Heartbleed

github.com

114 pointsFredericJ76 comments

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.

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.

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.

If you invented time travel people would definitely be writing about it.

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

This is hardly something isolated to the security industry. It's human nature. Some person sealing a hole is nowhere near as attention-gathering as a hole leading to a catastrophic flood due to no one realizing that it needs to be sealed.

The potential for something bad to happen doesn't raise anywhere near as much eyebrows as the bad thing actually happening, especially for something as invisible to the average person as a software vulnerability.

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

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.

I totally understand the desire to tweak the IDS vendors. Having spent a lot of time working for vendors in that space, they often need tweaking.

But I don't get the leap from "IDS vendors suck" to "I made a command-line tool so any idiot can suck down private keys from a server." If the idea was to show that the IDS rules sucked, then just release a slightly different version of the previous heartbleed testers that gets around it.

But that's not as much fun.

"yet it hasn't stopped vendors from claiming they offer protection"

100% true. The argument Dan and others are trying to make is there are a lot of people caught in the cross-fire who have nothing to do with IDS-vendors claims.

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.

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.

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.

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.

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

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.

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

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.

Writing offensive security tools is bound to get the attention of the vendors, to cause a storm that will get attention from the vendors.

What you're advocating amounts to shooting the messenger. How dare some person write software that disrupts your falsely ingrained peace of mind.

The fact of the matter is, vendors have been notorious throughout the ages for not listening to the security community. So many easily preventable mistakes have led to so many breaches.

Well, it's time to get people to listen. What better way to do that then demonstrate, first-hand, the gravity of their errors?

I'd like to offer a different perspective. You're free to dismiss me as well because I currently have a similar job description to 'djcapelis, but I've also been a sysadmin and front-line IT security guy (watching IDSes, patching systems), so I have a pretty good idea what the commoditization of exploit code means.

I think that things like metasploit and heartleech are an almost purely unalloyed good. In my experience, the "bad guys" already have easy-to-use tools. What publicly available tools do is give defenders access to these techniques, which they can use to demonstrate that problems really are a Big Deal. There is a certain kind of person (who seem to gravitate towards management) that cannot be convinced to take an issue seriously unless they can see the impact with their own eyes. A tool that prints out the private key of their production server is worth a dozen blog posts and security advisories as far as convincing them the danger is real.

Yup.

Getting a private key using the extent simple scrypts is quite complicated, with lots of difficult steps. This is no barrier to teenage kids, who has lots of time on their hands that can play around until they get things right.

As a defender, however, you don't have that much time. For you, it's really easy. If you have a server, and want to know if the private key is visible, just download the Windows heartleech binary from github, run it against a server, walk away for 10 hours, and then come back to see if it's gotten the key.

In short, as you say, a tool that effortlessly prints the private key of a production server is worth a bazillion blogposts and security advisories. Code or GTFO, IMO :)

Exactly, how many people didn't really care about unencrypted requests over public WiFi networks until everyone and their grandson could install Firesheep? Tools to make that attack had been available forever, but only after Firesheep did many people finally accept that basically any authenticated request should be done over a secure channel.

For a huge majority of folks, some unfortunately in the position of making decisions and policy surrounding security, the attack just isn't real until there's a nicely usable and widely available tool.

You're making bad assumptions and your logic doesn't hold water. I have very much worked on teams responsible for protecting computers from breaking zero days. Most memorable for me was probably when the Debian SSH key generation bug was released. I was there that morning, writing a scanner to find all the vulnerable machines my team was responsible for (and actually racing against the scanner a colleague on my former team who had responsibility for the whole org's security was writing) and trying to get them patched as quick as possible. (Most of ours were found and patched by the time my former team put up their version of the list out, and another bunch had been patched before their scan even got to them, so we did a good job that day.) What I'm trying to say is, I know exactly what it's like. That operational experience informs my work today even though I don't have a large operational role for many machines these days. (I'm only responsible for about 40-60 machines now.)

That all aside, the job of the security community is not to make your life or my life easier. And neither you or the person I was replying to gets to be angry at someone for exposing a problem because it inconveniences you or your colleagues.

The only thing that will do you any good is to fix your shit.

Pretending that it is someone else's fault that you have to scramble to fix your shit is not okay. I think my comment was phrased bluntly, but was both truthful and appropriate. I understand the emotions that cause it, but no one who blames others for their own problems has much high ground to stand on when it comes to empathy.

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.

> the bad guys

You mean the NSA?

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

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

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.

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.

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.

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.

Because Snort's signatures can't detect 'heartleech'.

But most other IDSs can, such as Bro.

Unless there is a tool that demonstrates this, people won't believe that there is a difference between Snort and Bro, because existing tools don't show a difference.

You didn't address what I wrote. The demonstration didn't require the extraction of private key material from servers, because that's not the bug. The difference between Bro and Snort has nothing to do with private key material.

People are good at convincing themselves there is no problem. Vendors are good at convincing people there is no problem. The demonstration has to hit them over the head with the obviousness of the exploit. If the private-key pops up automatically, and a sensor didn't detect it, they have to believe. Otherwise, when the sensor doesn't fire, they'll believe that the exploit is at fault.

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.

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?

Maybe they use the GNU TLS library.

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

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.

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.

Yep, older versions of OpenSSL are not vulnerable.

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

Are you http only?

no I've got SSL certificates and https set up

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

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

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

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

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_.... So that's 18 months of exposure for Fedora users (including me).

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"

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

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

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.

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

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.

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.

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?

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

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/

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.

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

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

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

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

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?

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.

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.

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?

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

You can also MITM outgoing SSL connections and use heartbleed on them. The vulnerability is accessible before the certificate checks are completed, so the standard MITM prevention measures don't help you there.

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

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

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.

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

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.

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

Reply on news.ycombinator.com