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

21–30 of 78 posts

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

#21

Post by aroch »

danielweber wrote: post #18
jhardcastle wrote: post #13

Earlier quoted context omitted.

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

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

#22

Post by Pxtl »

happyscrappy wrote: post #20

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?

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

#23

Post by larrysilverman »

Pxtl wrote: post #22
happyscrappy wrote: post #20

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

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

#24

Post by danielweber »

aroch wrote: post #21
danielweber wrote: post #18

Earlier quoted context omitted.

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.

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

#25

Post by vezzy-fnord »

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…

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.

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

#26

Post by danielweber »

eli wrote: post #19
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…

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.

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

#27

Post by dspillett »

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?

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

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

#28

Post by nikcub »

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.

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

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

#29

Post by eli »

Pxtl wrote: post #22
happyscrappy wrote: post #20

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?

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

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

#30

Post by makomk »

eli wrote: post #19
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…

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.

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.
Post reply on HN