Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Heartleech: Automated OpenSSL private key extraction tool using Heartbleed

github.com

Post reply on HN
Print view View original

51–60 of 78 posts

Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed

#51

Post by deeviant »

danielweber wrote: post #17

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

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.

Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed

#52

Post by nitrogen »

deeviant wrote: post #48
jameshart wrote: post #46

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

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

Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed

#53

Post by lstamour »

deeviant wrote: post #48
jameshart wrote: post #46

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

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

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.

Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed

#54

Post by awda »

awda wrote: post #38
nikcub wrote: post #28

Earlier quoted context omitted.

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

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

Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed

#55

Post by lstamour »

NoodleIncident wrote: post #49
jameshart wrote: post #46

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

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

Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed

#56

Post by lstamour »

neals wrote: post #3

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?

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

Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed

#57

Post by djcapelis »

Xylakant wrote: post #40
danielweber wrote: post #17

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

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…

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

Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed

#58

Post by acqq »

nikcub wrote: post #28
neals wrote: post #3

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?

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

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"

Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed

#59

Post by tsaoutourpants »

simias wrote: post #44
danielweber wrote: post #17

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

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?

Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed

#60

Post by larrys »

djcapelis wrote: post #43
danielweber wrote: post #17

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

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

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

Post reply on HN