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

CloudFlare's Heartbleed challenge cracked

twitter.com

Post reply on HN
Print view View original

121–130 of 155 posts

Re: CloudFlare's Heartbleed challenge cracked

#121

Post by quasque »

benmmurphy wrote: post #102

i think cloudfare's version of nginx is a lucky version or my code is bugged or time after restart is important or you need to do some heap-fu by sending different payload sizes. so i booted up a micro vm on amazon aws and was able to dump the private key in one request. Ubuntu Server 13.10 (PV) - ami-35dbde5c sudo add-apt-repository ppa:nginx/development sudo apt-get update sudo apt-get install nginx sudo apt-get in…

I also got the Cloudflare private key with the same technique you describe, tried both incrementally increasing the payload size and choosing it at random (between 3 and 18427 bytes - anything higher than that triggered an alert). The incremental increase worked better: there was a range in the mid-hundreds that continually emitted one of the primes.

Other possible contributing factors: I was hammering the server with empty https requests hoping it would leave traces of calculation about, and was running a few dozen of the heartbeat keysearch in parallel. I don't know if either of these helped or not.

Who knows, maybe some anonymous benefactor carefully extracted the primes out of a more opaque data structure and uploaded them neatly back to the heap for us all to find!

Re: CloudFlare's Heartbleed challenge cracked

#123

Post by itsnotvalid »

drakaal wrote: post #115
nl wrote: post #97

Earlier quoted context omitted.

CIA and FBI had knowledge of variations of this vulnerability nearly 10 years ago. This isn't true. Don't make things up - this bug is bad enough without misinformation. OpenSSL has been patching variations of this bug for that whole time Untrue. OpenSSL has been patching unrelated bugs since it was created (as has most software). https://www.openssl.org/news/secadv_20030930.txt* This is unrelated to heartbleed.

It is related in that there has never been a release of OpenSSL that was secure. Not one. Ever. The known vulnerabilities list for OpenSSL has never had a release that didn't have a flaw that allowed some amount of "backdooring", Dataextraction, or data manipulation. (as opposed to just a path for a DoS attack) >Don't make things up - I don't have to make things up. The CIA and FBI keep a list of known vulnerabilitie…

Which kind of proxies? What are they using them actually?

Re: CloudFlare's Heartbleed challenge cracked

#124

Post by benmmurphy »

quasque wrote: post #121
benmmurphy wrote: post #102

i think cloudfare's version of nginx is a lucky version or my code is bugged or time after restart is important or you need to do some heap-fu by sending different payload sizes. so i booted up a micro vm on amazon aws and was able to dump the private key in one request. Ubuntu Server 13.10 (PV) - ami-35dbde5c sudo add-apt-repository ppa:nginx/development sudo apt-get update sudo apt-get install nginx sudo apt-get in…

I also got the Cloudflare private key with the same technique you describe, tried both incrementally increasing the payload size and choosing it at random (between 3 and 18427 bytes - anything higher than that triggered an alert). The incremental increase worked better: there was a range in the mid-hundreds that continually emitted one of the primes. Other possible contributing factors: I was hammering the server wit…

I used the random payload size between 0 and 10,000. But sounds like you found a nice way to get the keys :) I looked at the openssl source code and I don't think it is possible in nginx for it to leak the intermediate results into memory. I suspect we are leaking one of the only two primes stored in memory. Another HN poster was able to break apache MPM and I strongly suspect they were leaking intermediate values: https://twitter.com/makomk/status/454761049955127296

i also thought an earlier discoverer might have been trolling us :)

Re: CloudFlare's Heartbleed challenge cracked

#125

Post by intelliot »

AReallyGoodName wrote: post #92
nikcub wrote: post #62

Reading Cloudflare's blog post[0], they keep referring to the exploit having a length of 65,536 bytes, and how an allocation of that size is unlikely to find itself lower in the heap. That is true - but this exploit doesn't depend on setting a length of 65,536. The server takes whatever length the client gives it (which is, afterall, the bug). Most of the early exploits just happen to set the maximum packet size to g…

That's close but you actually want to change the size of your packet, not the size of the requested return data. // Essentially OpenSSLs bug is the following buffer = malloc(payload_claimed) // we aren't going over these bounds // Later memcpy(buffer, your_actual_payload, payload_claimed) // we are going over your_actual_payloads bounds By changing your actual payloads size you can influence what data we get. The pay…

Doesn't seem to match https://gist.github.com/indutny/a11c2568533abcf8b9a1

Re: CloudFlare's Heartbleed challenge cracked

#126

Post by pushrax »

jsmeaton wrote: post #79
pushrax wrote: post #71

Earlier quoted context omitted.

I would call this a "self-induced man in the middle attack". You're telling your computer that cloudflarechallenge.com is his server.

The point is you can connect to it with HTTPS and your browser doesn't throw up big flashy warnings. It's basically proof that he has got the private key, since he can impersonate cloudfarechallenge.com with regards to SSL.

Yes, of course. That's why it's a successful "man in the middle attack" of sorts. If the cert wasn't trusted then it would mean nothing.

Re: CloudFlare's Heartbleed challenge cracked

#127

Post by drakaal »

itsnotvalid wrote: post #123
drakaal wrote: post #115

Earlier quoted context omitted.

It is related in that there has never been a release of OpenSSL that was secure. Not one. Ever. The known vulnerabilities list for OpenSSL has never had a release that didn't have a flaw that allowed some amount of "backdooring", Dataextraction, or data manipulation. (as opposed to just a path for a DoS attack) >Don't make things up - I don't have to make things up. The CIA and FBI keep a list of known vulnerabilitie…

Which kind of proxies? What are they using them actually?

Just one example, but this is a typical setup.

http://www.cisco.com/c/en/us/td/docs/interfaces_modules/serv...

I don't suggest doing the Clear Text between server and proxy, but the idea is the same. You use a proxy so that you don't ever have user names or passwords in memory longer than a few ms.

Once a user is authenticated data passes through quickly making it very very difficult to do a fingerprint match of the data you do extract.

Also because you can load balance across proxies you may not even hit the same machine with a second "hear beat".

The Cert still has to be there somewhere, so you could still end up giving up a cert, and you could give away anything that fits on a single HTML page as it is flying by in the stream... But most sites know better than to display a password, or a username and a bank account number at the same time (not all, but most).

Heart Bleed is more of an issue because too many people built monoliths, rather than compartmentalizing. The Titanic didn't sink because it was compartmentalized, it sank because the man at the Wheel didn't know to let one compartment take all of the force, and instead spread it over a larger surface.

Your proxy should be disposable. Nothing of value should be on the thing that talks to the user, and shouldn't retain data for any length of time.

Re: CloudFlare's Heartbleed challenge cracked

#128

Post by cryptbe »

alexkus wrote: post #117
dogsky wrote: post #112

Earlier quoted context omitted.

Interesting. But from got the prime1 and prime2, from there how do you obtain the private certificate?

You now know the two primes (p,q) which multiply together to make n (the public key modulus). We also know e (the public key exponent). d (the private key) is:- d = e^-1 mod ((p-1)(q-1)) To work this modular inverse out you use the extended Euclidean algorithm. This is why you need to know the factorisation of n=(p*q). You can't compute d (the private key) with just the composite n.

You don't need to use p or q. See http://vnhacker.blogspot.com/2014/04/idea-to-solve-cloudflar...

Re: CloudFlare's Heartbleed challenge cracked

#129

Post by cryptbe »

benmmurphy wrote: post #118
dogsky wrote: post #112

Earlier quoted context omitted.

Interesting. But from got the prime1 and prime2, from there how do you obtain the private certificate?

i think this took me as long as coding the recovery tool :( https://github.com/jjarmoc/csaw2012_cert_app/blob/master/lib... https://github.com/ius/rsatool

I wrote a tool some time ago. It's 10 lines of Python using pyasn1.

Re: CloudFlare's Heartbleed challenge cracked

#130

Post by drakaal »

dtech wrote: post #94
drakaal wrote: post #70

Earlier quoted context omitted.

>we had the bug 16 days early, no we had the bug 18 days early And we didn't know what to do about it... CIA and FBI had knowledge of variations of this vulnerability nearly 10 years ago. OpenSSL has been patching variations of this bug for that whole time, and every good hacker, (and the bad ones) have been exploiting OpenSSL since its creation. https://www.openssl.org/news/secadv_20030930.txt People act surprised,…

BS. Those bugs are completely unrelated. If there is a common denomenator between all OpenSSL bugs in the last 10 years is that they often come from basic problems/difficulties with C (array out of bounds, length checks and such).

Which is what caused those particular vulnerabilities.

OpenSSL has been vulnerable as you state because it is C rather than managed code, and managing memory has never been one of the core teams strong suits.

I get the reason for using C, OpenSSL is probably the most performant SSL solutions available. It is much less resource intensive than say Polar. (NSS is getting there, but is not really a solution for embedded systems [routers and such])

>all OpenSSL bugs in the last 10 years is that they often come from basic problems/difficulties with C (array out of bounds, length checks and such)

When you have a means to over flow or retrieve memory you can get at data or execute code to give you data. Which is the bug that is causing heart bleed.

What is making heart bleed worse is that it goes back so many versions so for the first time in a long time there is a well known vulnerability that is the same on everyone who runs it.

It isn't a "worse" vulnerability it is a "more common one". Think of it like a Genetic defect. If 1 animal in 10 has it, the herd still has "herd immunity". Or the old "there are no viruses for mac" back when mac had like 2% of the market share so even when there were viruses they were hard to spread. We are now at a point everybody who wants to be malicious knows how to attack, and there are a lot of thing to attack, so more attackers will get "lucky" and find something interesting, especially since there will be so many servers that no one remember they need to track down and fix.

Post reply on HN