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

61–70 of 155 posts

Re: CloudFlare's Heartbleed challenge cracked

#61

Post by pizzeys »

zuado wrote: post #56
guelo wrote: post #51

"We rebooted the server at 3:08PST, which may have contributed to the key being available in memory, but we can’t be certain.". https://www.cloudflarechallenge.com/heartbleed That doesn't make sense to me, seems like the key needs to be in memory all the time, or at least during every session.

It seems that someone is doing some requests with RSA keys as a parameter. It doesn't make sense at all to me doing such request in order to get the server private key. Anyone seeing the same?

They're doing it to troll you (or others looking for keys).

Re: CloudFlare's Heartbleed challenge cracked

#62

Post by nikcub »

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 get as much data out (not realizing the nuances of heap allocation). You can set a length of 8bytes or 16bytes and get allocated in a very different part of the heap.

The metasploit module for this exploit[1] supports varied lengths. Beating this challenge could have been as simple as running it with short lengths repeatably and re-assembling the different parts of the key as you find it.

edit something that I want to sneak in here since I missed the other threads. Cloudflare keep talking about how they had the bug 12 days early. Security companies and vendors have worked together to fix bugs in private for years, but this is the first time i've ever seen a company brag about it or put a marketing spin on it. It isn't good - one simple reason why: other security companies will now have to compete with that, which forces companies not to co-operate on bugs (we had the bug 16 days early, no we had the bug 18 days early!, etc.).

As users you want vendors and security companies co-operating, not competing at that phase.

[0] Cloudflare - Can You Get Private SSL Keys Using Heartbleed? http://blog.cloudflare.com/answering-the-critical-question-c...

[1] see https://github.com/rapid7/metasploit-framework/blob/master/m...

Re: CloudFlare's Heartbleed challenge cracked

#64

Post by patcheudor »

ephemeralgomi wrote: post #38
bmadden wrote: post #29

Earlier quoted context omitted.

Do you guys store passwords in plain text? Shouldn't you only be able to get password hashes from a vulnerable server? I might be reading too much into your statement, but I'd like to know if I'm misunderstanding the situation.

Heartbleed doesn't give you access to storage - it gives you access to the raw heap of the process that's linked to OpenSSL. Passwords are typically transmitted unhashed, albeit encrypted by TLS, and the application decrypts the TLS stream to heap, which means an unhashed version of the password is in process memory for some amount of time. An attacker using Heartbleed has a chance to see that memory, and could there…

Example from a memory dump on a vulnerable server (username & password changed to protect the innocent):

`..?...t?.R...t>

...ned....userna

me=0000000+0ew+0

user&password=my

passw0rD.~Jt....

.3z..a..........

One of the things that caught me off guard, but isn't surprising is that some hosting companies don't use VM isolation, thus it was possible to pull memory from other sites which may have been patched. Hopefully hosting vendors that don't have isolated VM's don't also allow users to install their own OpenSSL as this would become a vector to compromise neighboring hosts. Of course allowing any custom software install in such an environment is just asking for it.

Re: CloudFlare's Heartbleed challenge cracked

#65

Post by dpweb »

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…

How do you know when you've found a piece of a key?

Re: CloudFlare's Heartbleed challenge cracked

#67

Post by nikcub »

dpweb wrote: post #65
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…

How do you know when you've found a piece of a key?

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 malloc, so it is different on different systems. You could find out what the probabilities are by looking at the source. For some reason FreeBSD's malloc gave up private keys with the default exploit length and not much effort. It was only a matter of time before other platforms were also figured out.

Note that the FreeBSD exploit worked on a fresh server after boot, which might have also been the case here.

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.

Re: CloudFlare's Heartbleed challenge cracked

#68

Post by riking »

zuado wrote: post #56
guelo wrote: post #51

"We rebooted the server at 3:08PST, which may have contributed to the key being available in memory, but we can’t be certain.". https://www.cloudflarechallenge.com/heartbleed That doesn't make sense to me, seems like the key needs to be in memory all the time, or at least during every session.

It seems that someone is doing some requests with RSA keys as a parameter. It doesn't make sense at all to me doing such request in order to get the server private key. Anyone seeing the same?

They're probably trying to spoil the pot for the other people that are trying, by inserting extra private keys someone looking for 'just a private key' will grab one of the pushed ones.

Re: CloudFlare's Heartbleed challenge cracked

#70

Post by drakaal »

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…

>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, but OpenSSL has never had a secure release. Ever.

Post reply on HN