8 ms·

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 it

by nikcub 13y ago

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-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/modules/auxiliary/scanner/ssl/openssl_heartbleed.rb#L130-L149 https://github.com/rapid7/metasploit-framework/blob/master/m...

dpweb 13y ago
How do you know when you've found a piece of a key?
- nikcub 13y ago
  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.
  - adsche 13y ago
    > 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.
    - alexkus 13y ago
      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.
- willvarfar 13y ago
  From a piece? Hard. But brute force everything you get back? Easy. Take every key-sized chunk of heap you got back, and see if, when interpreted as the key, it is the private key to the public cert. When found, send it in!
- rich90usa 13y ago
  I would think that there could be some application of how genome sequencing is done? From what I understand chains of DNA are cut by restriction enzymes and these random chains are assembled together by some clever algorithms?
  - Blahah 13y ago
    Depending on the nature of the strings, yes. If there is no repetition or errors in the representation of the sequence, you could use overlap layout consensus if it were small, or de-brujn or string graphs if it were large. For repetitive but error free sequences, de-brujn and string graph will do. For error-containing sequences, only the de-brujn graph (with the proviso that you'll reconstruct some false-positive sequences too).
- coolj 13y ago
  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-heartbleed-bug.html http://blog.existentialize.com/diagnosis-of-the-openssl-hear...
drakaal 13y ago
>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 https://www.openssl.org/news/secadv_20030930.txt People act surprised, but OpenSSL has never had a secure release. Ever.
- PhasmaFelis 13y ago
  > CIA and FBI had knowledge of variations of this vulnerability nearly 10 years ago. Source?
  - drakaal 13y ago
    CIA and FBI servers are easy to find, and many run OpenSSL. Go see which ones have the vulnerability. You won't find it on them. Their branch doesn't have the issue. Also look through this http://web.nvd.nist.gov/view/vuln/search-results?query=openssl http://web.nvd.nist.gov/view/vuln/search-results?query=opens... You will see mentions of this bug in products that use OpenSSL quite often.
    - cdelsolar 13y ago
      haven't seen a mention of it yet.
    - PhasmaFelis 13y ago
      Do you have evidence of that being true a week ago? It's no surprise that the CIA and FBI would scramble to lock down vulnerabilities as soon as they were announced, but that's not proof that they never had them in the first place. After the Snowden business, I wouldn't be hugely surprised if the gov't was secretly aware of Heartbleed, but I'm not comfortable taking a random stranger's word for it.
      - 13y ago
tomkwok 13y ago
I get your point, but CloudFlare actually fixed that 7 days before the public disclosure, that is 12 days ago. "We fixed the flaw on Monday March 31, 2014 for all CloudFlare customers, with public notification on Monday April 7, 2014, after the researchers' public announcement." -- https://support.cloudflare.com/hc/en-us/articles/201660084-Update-on-the-Heartbleed-OpenSSL-Vulnerability https://support.cloudflare.com/hc/en-us/articles/201660084-U...
AReallyGoodName 13y ago
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. -----BEGIN RSA PRIVATE KEY----- MIIEpQIBAAKCAQEA6uXOrI1IRdAv8YCCd5PSBH9i+a85+gnFE+FWCQwtgOhRxCVX 3Wh3Sb74Dl9DSDGwiM7E9sGyZTmmAa/L4QrYq9Xz0/nGJfieFIfwqnY4XCoih5is w9pZMmMfOrS7Pov/e4AIorgqHjh5hU8eSim0d6NB35+fI8G6myOMolvkyMXBCO97 AYP1ALo4LhmlU9PsmWiTnekswzTtKspiRThRbP8ha9HNG+K2PUWtChtT7o8DrSb3 TdYmCdt/ryub/apnVasAEk5D3mux8d/vNhBlbqagfGVPyRI+PnGlnvBWaSQr+ERP INzlsKoqO/pKm075hzsSSZm6VMHk+tw8e9TTLQIDAQABAoIBAQDVFZEtcKCeTCQh xP0Vcm/zCogDjlReoRw5U5GTdYuVw6ng8CtLu2dy65zklMBZLlJBWKjOW5n0P557 KzkctZUmFFky8wMwEN9+Km9EgyfPW52lOfeHV3zQu6BpxeeR7rfdFaE/0ybJ8Vsz djk496oxWVT5gjh/3E7mSxJZelkJUrYNjWcyditpKvajUWDT/NQWemRFnkEWSOkp QMhnRNUNZLB2OIy58rDmzoX0RSnNnDcnqi4JQBnyH8N6SI7jd9KToDSBz2KubGeB y77VKEUjtzjOQHef+hXpOQEEJoWW2KevuMxrE9dj/6jR4wgs6638EoaC4sCaSXtc gQJPQni1AoGBAP1Dls3T5oYMbsrlDlInFVVP8N8jrWF3oivR8dtM1tsIVsSoSLt5 ZBO1v/4veUqKsZ+UJSJOfbIEArIo9p9J+j3EUW2BiOEUf9cwBnNukDgx5ocAjlWq Kz1p2HtPGzPmA920uik593xn5TVVqpVtZOZ6j3rVLIJ/eL07zNYJBd5fAoGBAO1v bOud4q8jmXdySaVfKVIhVljSooZ13Pfpr1dXMer1HDAFFROa0uI8SgCAlGUN6DIp Ji9kkmuvcU3NQcaAVus/maM63HSny5xpwl2ni4AZWUFoVh5WTjLZMXhH+L9ClN1G eoVOxTD2KnXE74gNTh0F/mHBoQSai9yv9QoMN6HzAoGBAMqrtNl/siEhf+PTy1MI vbSopUwbw9qUnu1MM6xX4DQlhzIWrSWBbgmrzzl9CiYRuTTHm7PJdiLnvLSPvVQZ Ii0dlj/4ge4Eto0gfHkRSE3/+MeeNUjuRW3+7uM2mcE9V2irALKPFbKzfaPhqwGr KiyadYlJYDYKBjgAy9mYHN8nAoGAc4YmedGdLNfmYK6z1ImjojlkON1rhH6uX9VM ofNj700JRPgEFEDdYIQzAWGOUkjc9CL/WEnX0BtRxqga28kwAVA1oa0O/JdzwwvW LRlLD63FtsRcOnCFpcn1fu+NwQlVQwB6tofn+/WaHSkP3qOSoR58cfXzMTk82cin MhdVri8CgYEA/JHRikQF7r384f8sDwFG6Ll8CTWW0NP7ng2yCPKjtu4U/T9OiFNT fbNv++blOEbtS/nPCUf1CrkjsesT76r/7YHLuQ43sk+rjKk3uFQnMDvrK1IJim9h 0h9D6Qr9XLGKFqbP72OQpuG/RFNXnCLxrJ0ZmxewJmyEYSS6kN78HHY= -----END RSA PRIVATE KEY-----
- AReallyGoodName 13y ago
  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-freelist-reuse http://www.tedunangst.com/flak/post/analysis-of-openssl-free...

by nikcub 13y ago

dpweb 13y ago

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

nikcub 13y ago
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.
- adsche 13y ago
  > 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.
  - alexkus 13y ago
    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.
willvarfar 13y ago
From a piece? Hard. But brute force everything you get back? Easy. Take every key-sized chunk of heap you got back, and see if, when interpreted as the key, it is the private key to the public cert. When found, send it in!
rich90usa 13y ago
I would think that there could be some application of how genome sequencing is done? From what I understand chains of DNA are cut by restriction enzymes and these random chains are assembled together by some clever algorithms?
- Blahah 13y ago
  Depending on the nature of the strings, yes. If there is no repetition or errors in the representation of the sequence, you could use overlap layout consensus if it were small, or de-brujn or string graphs if it were large. For repetitive but error free sequences, de-brujn and string graph will do. For error-containing sequences, only the de-brujn graph (with the proviso that you'll reconstruct some false-positive sequences too).
coolj 13y ago
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-heartbleed-bug.html http://blog.existentialize.com/diagnosis-of-the-openssl-hear...

drakaal 13y ago

>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 https://www.openssl.org/news/secadv_20030930.txt People act surprised, but OpenSSL has never had a secure release. Ever.

PhasmaFelis 13y ago
> CIA and FBI had knowledge of variations of this vulnerability nearly 10 years ago. Source?
- drakaal 13y ago
  CIA and FBI servers are easy to find, and many run OpenSSL. Go see which ones have the vulnerability. You won't find it on them. Their branch doesn't have the issue. Also look through this http://web.nvd.nist.gov/view/vuln/search-results?query=openssl http://web.nvd.nist.gov/view/vuln/search-results?query=opens... You will see mentions of this bug in products that use OpenSSL quite often.
  - cdelsolar 13y ago
    haven't seen a mention of it yet.
  - PhasmaFelis 13y ago
    Do you have evidence of that being true a week ago? It's no surprise that the CIA and FBI would scramble to lock down vulnerabilities as soon as they were announced, but that's not proof that they never had them in the first place. After the Snowden business, I wouldn't be hugely surprised if the gov't was secretly aware of Heartbleed, but I'm not comfortable taking a random stranger's word for it.
    - 13y ago

tomkwok 13y ago

I get your point, but CloudFlare actually fixed that 7 days before the public disclosure, that is 12 days ago. "We fixed the flaw on Monday March 31, 2014 for all CloudFlare customers, with public notification on Monday April 7, 2014, after the researchers' public announcement." -- https://support.cloudflare.com/hc/en-us/articles/201660084-Update-on-the-Heartbleed-OpenSSL-Vulnerability https://support.cloudflare.com/hc/en-us/articles/201660084-U...

AReallyGoodName 13y ago

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. -----BEGIN RSA PRIVATE KEY----- MIIEpQIBAAKCAQEA6uXOrI1IRdAv8YCCd5PSBH9i+a85+gnFE+FWCQwtgOhRxCVX 3Wh3Sb74Dl9DSDGwiM7E9sGyZTmmAa/L4QrYq9Xz0/nGJfieFIfwqnY4XCoih5is w9pZMmMfOrS7Pov/e4AIorgqHjh5hU8eSim0d6NB35+fI8G6myOMolvkyMXBCO97 AYP1ALo4LhmlU9PsmWiTnekswzTtKspiRThRbP8ha9HNG+K2PUWtChtT7o8DrSb3 TdYmCdt/ryub/apnVasAEk5D3mux8d/vNhBlbqagfGVPyRI+PnGlnvBWaSQr+ERP INzlsKoqO/pKm075hzsSSZm6VMHk+tw8e9TTLQIDAQABAoIBAQDVFZEtcKCeTCQh xP0Vcm/zCogDjlReoRw5U5GTdYuVw6ng8CtLu2dy65zklMBZLlJBWKjOW5n0P557 KzkctZUmFFky8wMwEN9+Km9EgyfPW52lOfeHV3zQu6BpxeeR7rfdFaE/0ybJ8Vsz djk496oxWVT5gjh/3E7mSxJZelkJUrYNjWcyditpKvajUWDT/NQWemRFnkEWSOkp QMhnRNUNZLB2OIy58rDmzoX0RSnNnDcnqi4JQBnyH8N6SI7jd9KToDSBz2KubGeB y77VKEUjtzjOQHef+hXpOQEEJoWW2KevuMxrE9dj/6jR4wgs6638EoaC4sCaSXtc gQJPQni1AoGBAP1Dls3T5oYMbsrlDlInFVVP8N8jrWF3oivR8dtM1tsIVsSoSLt5 ZBO1v/4veUqKsZ+UJSJOfbIEArIo9p9J+j3EUW2BiOEUf9cwBnNukDgx5ocAjlWq Kz1p2HtPGzPmA920uik593xn5TVVqpVtZOZ6j3rVLIJ/eL07zNYJBd5fAoGBAO1v bOud4q8jmXdySaVfKVIhVljSooZ13Pfpr1dXMer1HDAFFROa0uI8SgCAlGUN6DIp Ji9kkmuvcU3NQcaAVus/maM63HSny5xpwl2ni4AZWUFoVh5WTjLZMXhH+L9ClN1G eoVOxTD2KnXE74gNTh0F/mHBoQSai9yv9QoMN6HzAoGBAMqrtNl/siEhf+PTy1MI vbSopUwbw9qUnu1MM6xX4DQlhzIWrSWBbgmrzzl9CiYRuTTHm7PJdiLnvLSPvVQZ Ii0dlj/4ge4Eto0gfHkRSE3/+MeeNUjuRW3+7uM2mcE9V2irALKPFbKzfaPhqwGr KiyadYlJYDYKBjgAy9mYHN8nAoGAc4YmedGdLNfmYK6z1ImjojlkON1rhH6uX9VM ofNj700JRPgEFEDdYIQzAWGOUkjc9CL/WEnX0BtRxqga28kwAVA1oa0O/JdzwwvW LRlLD63FtsRcOnCFpcn1fu+NwQlVQwB6tofn+/WaHSkP3qOSoR58cfXzMTk82cin MhdVri8CgYEA/JHRikQF7r384f8sDwFG6Ll8CTWW0NP7ng2yCPKjtu4U/T9OiFNT fbNv++blOEbtS/nPCUf1CrkjsesT76r/7YHLuQ43sk+rjKk3uFQnMDvrK1IJim9h 0h9D6Qr9XLGKFqbP72OQpuG/RFNXnCLxrJ0ZmxewJmyEYSS6kN78HHY= -----END RSA PRIVATE KEY-----

AReallyGoodName 13y ago
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-freelist-reuse http://www.tedunangst.com/flak/post/analysis-of-openssl-free...