CloudFlare's Heartbleed challenge cracked • Hacker News Board

Re: CloudFlare's Heartbleed challenge cracked

#111

Post by brokenparser » Sat, Apr 12, 2014, 4:00 PM UTC

maccard wrote: post #104

bitsteak wrote: post #63

Why did anyone need this challenge in the first place? Couldn't someone have justed ASKED a good exploit developer what they would do and what the impact is? No, I guess we're all up for wasting people's time and creating potential false negatives.

Because good idea in theory != good idea in practice. Showing that this actually works in practice (albeit on an isolated incident) shows that the bug is dangerous in practice, not just theory. Look at all the research in timing attacks etc on TLS, some of which are theoretically feasible, until you consider real world possibilities of remote servers, such as "Their ISP is fiddling with routing so I have varying late…

Yeah, I bet that fix is real easy.

Re: CloudFlare's Heartbleed challenge cracked

#112

Post by dogsky » Sat, Apr 12, 2014, 4:12 PM UTC

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…

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

Re: CloudFlare's Heartbleed challenge cracked

#113

Post by dogsky » Sat, Apr 12, 2014, 4:12 PM UTC

I was unable to replicate. Can someone give more details, maybe the heartbleed script updated and some instructions to replicate it? Thanks.

Re: CloudFlare's Heartbleed challenge cracked

#114

Post by dogsky » Sat, Apr 12, 2014, 4:13 PM UTC

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…

I was unable to replicate. Can someone give more details, maybe the heartbleed script updated and some instructions to replicate it? Thanks.

Re: CloudFlare's Heartbleed challenge cracked

#115

Post by drakaal » Sat, Apr 12, 2014, 4:15 PM UTC

nl wrote: post #97

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

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 vulnerabilities, publicly and not publicly documented. They use this information for doing investigations. I have personally run in to issues where I was contacted by FBI because we had created fixes for our deployments and they contacted us to "unfix" them, because their warrants were "no knock" and they didn't wish to tell us who they were attempting to do surveillance on.

Feel free to Google me (Brandon Wirtz) if you need some background on my credentials in the security space.

But thanks for jumping to I make stuff up. The mis-information that is out there is that OpenSSL has ever been secure.

I'm more sad nobody beyond XKCD did a good job explaining how the bug works, or doing the demonstration I like where you bash on the server and do data alignment to show a couple of gigs worth of data from a single server. People aren't scared enough of this stuff.

All those people saying "change your passwords on every site", but nobody is creating a huge public list of which sites are currently not patched.

so >bad enough without misinformation

No. People are too complacent and the OpenSource community doesn't own up to the things they let slip by. The "smart" guys at CDN's and Banks, were never at risk because they use proxies that have extremely short "memory life" because data is streaming through rather than stored (by the time you could get a second value to do finger printing everything would have changed), and are running NSS, or Matrix or Polar.

Hearbleed is an issue because too many people are too complacent, too trustworthy, and too uninformed.

Re: CloudFlare's Heartbleed challenge cracked

#116

Post by alexkus » Sat, Apr 12, 2014, 4:20 PM UTC

adsche wrote: post #99

nikcub wrote: post #67

Earlier quoted context omitted.

store everything, reconstruct it all later by trying to work out which part of the heap each request is from. there is likely some sort of efficiency calculus you can do here (i'm not good at math so I have no idea what i'm talking about) where you could calculate for heap size x and probabilities y and z etc. just how many requests and what size they should be to cover the entire process heap. edit: OpenSSL wraps ma…

> Note that in the heap there are the intermediate values that and are used when constructing the connection and doing the encryption, you aren't exactly looking for '------BEGIN PRIVATE KEY------' or base64 string, you'd be looking for those - each which have a unique data type. That's what I thought as well when I saw people POSTing strings like that and other people finding them. But when the key is first loaded f…

It shouldn't be about it eventually being overwritten, sensitive information like that (which isn't needed for runtime) should be actively scrubbed before the block of memory is freed.

You can't, however, get away with not having the private key modulus in memory (in some form) all the time.

Re: CloudFlare's Heartbleed challenge cracked

#117

Post by alexkus » Sat, Apr 12, 2014, 4:27 PM UTC

dogsky wrote: post #112

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…

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.

Re: CloudFlare's Heartbleed challenge cracked

#118

Post by benmmurphy » Sat, Apr 12, 2014, 4:43 PM UTC

dogsky wrote: post #112

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…

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

Re: CloudFlare's Heartbleed challenge cracked

#119

Post by pinaceae » Sat, Apr 12, 2014, 4:52 PM UTC

ademarre wrote: post #34

https://twitter.com/eastdakota/status/454792635279220737 Pic of the CloudFlare team reviewing the attack. Ten guys crowded around one monitor.

to be that guy: that's a bunch of kids. goes to show that we're far from being a mature industry when critical pieces of internet infrastructure are being run by bright, but inexperienced people. and of course they're inexperienced, no one really is, the whole thing is in its infancy.

but imagine this being "the team" in charge of mission critical stuff on a 777.

experience cannot be gained through shortcuts or pure intelligence. case in point, this very situation.

Re: CloudFlare's Heartbleed challenge cracked

#120

Post by carmaa » Sat, Apr 12, 2014, 4:58 PM UTC

ig1 wrote: post #106

So I didn't manage to crack the challenge (I used around 10k heartbeats), but I suspect it may have just been a case of brute-force (i.e asking for enough heartbleeds). Other people may have got the key without realizing that had done so because they were looking for the wrong thing (i.e. normal cert text representation). I took the approach of using two fingerprints to search the data: 1) The hex sequence "30 82 ..…

That's the way to do it - you can also use the tool interrogate:

https://github.com/carmaa/interrogate

/shameless plug