CloudFlare's Heartbleed challenge cracked

91–100 of 155 posts

Re: CloudFlare's Heartbleed challenge cracked

#91

Post by ErrantX » Sat, Apr 12, 2014, 8:44 AM UTC

girvo wrote: post #10

bigiain wrote: post #6

Earlier quoted context omitted.

On the other hand, if anyone asks me to justify all that "unproductive time" this week, I don't need to handwave and explanations any more.

I was lucky, my boss understood pretty quickly how big a deal it was. My project manager didn't, though, but he did pretty quick when I cracked our dev server and told him his password for a couple of services. It was fun playing pen tester and getting paid for it this week :)

Fortunately, I picked this week to muck up some of our HTTPS endpoints... ready made excuse!

Re: CloudFlare's Heartbleed challenge cracked

#92

Post by AReallyGoodName » Sat, Apr 12, 2014, 9:00 AM UTC

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 payload claimed doesn't really matter, that's just the amount we copy starting from wherever our actual payload ends up so that should always be 65536 for best results.

Incidentally i got the following off the server (a payload size of 0x1D seems to hit it) but it doesn't seem to accept it as the real RSA key.

I wonder if someones spamming requests containing false keys to the server or if they've just stopped accepting answers.

Re: CloudFlare's Heartbleed challenge cracked

#93

Post by coolj » Sat, Apr 12, 2014, 9:05 AM UTC

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?

Brute force is infeasible if you get random heap data along with key fragments. Based on the way the exploit works[0], my amateur guess would be they sent small payloads and actually did get SSLv3 records, because they found the right heap allocation strategy for a specific build on a specific platform.

[0] http://blog.existentialize.com/diagnosis-of-the-openssl-hear...

Re: CloudFlare's Heartbleed challenge cracked

#94

Post by dtech » Sat, Apr 12, 2014, 9:11 AM UTC

drakaal wrote: post #70

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

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

Re: CloudFlare's Heartbleed challenge cracked

#95

Post by nodesocket » Sat, Apr 12, 2014, 9:18 AM UTC

danielpal wrote: post #30

The important thing to know here is that you not only have to change your current certs you ALSO HAVE TO REVOKE THE OLD ONE. If you only change your current cert to get a new key but you don't go through the revocation process of the old certificate if someone managed to get the old one they can still use it for a MiTM attack - as both certs would be valid to any client.

With GoDady, when you rekey, it automatically revokes the old cert after 72 hours.

Re: CloudFlare's Heartbleed challenge cracked

#96

Post by AReallyGoodName » Sat, Apr 12, 2014, 9:22 AM 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…

Excuse the formatting above, it seems to have eaten my whitespace.

Just for further reference i recommend reading about OpenSSLs freelists implementation. Essentially if you have an object that uses a specific amount of space it will be stored in a specific location. Which is why private key extraction is possible. You just need to craft a request that puts your_actual_payload in a location so that the 65536 bytes that are read from it into a buffer also end up reading the key.

http://www.tedunangst.com/flak/post/analysis-of-openssl-free...

Re: CloudFlare's Heartbleed challenge cracked

#97

Post by nl » Sat, Apr 12, 2014, 9:29 AM UTC

drakaal wrote: post #70

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

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.

Permalink View on HN Reply on HN Top

Re: CloudFlare's Heartbleed challenge cracked
#98

StavrosK
HN member S

Activity:
0

Joined:
Sun, Jun 20, 2021, 4:50 PM UTC

HN karma:
1

Post by StavrosK » Sat, Apr 12, 2014, 10:04 AM UTC

capcah wrote: post #44

I am not sure how those guys did it, but I was talking to a friend of mine today, and I guess that it had something to do with forcing the server to use its private key to check for information sent to it. Then you use the heartbleed bug to intercept the intermediate forms on the information you sent to be decrypted/authenticated. Since you know the plaintext, the ciphertext and the intermediate forms, it should be p…

You can't recover keys with known plaintext attacks in most encryption algorithms used nowadays, plus, as far as I know, they don't even use the private key to encrypt your request. They only use it for a DH handshake, which establishes the session key you are going to use.

Permalink View on HN Reply on HN Top

Re: CloudFlare's Heartbleed challenge cracked
#99

adsche
HN member A

Activity:
194

Joined:
Sun, Jul 14, 2013, 6:31 AM UTC

HN karma:
673

Post by adsche » Sat, Apr 12, 2014, 10:30 AM UTC

nikcub wrote: post #67

dpweb wrote: post #65

Earlier quoted context omitted.

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 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 from file, wouldn't actually all those base64 strings be in memory?
Probably just pretty unlikely that they would persist for a long time without being overwritten.

Permalink View on HN Reply on HN Top

Re: CloudFlare's Heartbleed challenge cracked
#100

klapinat0r
HN member K

Activity:
229

Joined:
Thu, Feb 03, 2011, 9:35 PM UTC

HN karma:
528

Post by klapinat0r » Sat, Apr 12, 2014, 11:04 AM UTC

barkingcat wrote: post #59

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.

you are underestimating the severity of the bug. The bug leaks server memory - in which case unencrypted passwords are being sent to the server by the user's browser in order to be hashed to be compared to the hashed versions in storage. Normally this is protected by tls, but as you can see, for servers that suffer from this hole, it's as good as naught. Note that this occurs for "any" connections hitting the vulnera…

This is why I always make sure to GC, delete or NULL input variables (you must include the request; body et al.) after encrypt/hash/.
I basically take the stanze that I want as little to do with your real password as possible.

Permalink View on HN Reply on HN Top

Post reply on HN
Page 10 of 16

‹

1

9

10

11

16

›