4 ms·

I've published another toolset in Python here: https://github.com/einaros/heartbleed-tools https://github.com/einaros/heartbleed-tools The final test I did bef

by einaros 12y ago

I've published another toolset in Python here: https://github.com/einaros/heartbleed-tools https://github.com/einaros/heartbleed-tools The final test I did before publishing yielded ~100Mbit/sec of bleed from the challenge server, and had the prime in a few secs. I also detailed a couple of other challenge observations here: https://hacking.ventures/rsa-keys-in-heartbleed-memory/ https://hacking.ventures/rsa-keys-in-heartbleed-memory/

chubot 12y ago
Thanks for publishing. FWIW I tried your tools, and it said my server Nginx HTTPS was vulnerable, but I couldn't get any keys out of it. I created a 180MB dump file, and then scanned it, and it finished without finding keys (and I repeated this again) I also tried the code you linked here: https://news.ycombinator.com/item?id=7577659 https://news.ycombinator.com/item?id=7577659 This also failed, and it actually said my server was likely not vulnerable? I compiled my own Nginx, (but not my own SSL, that came from Debian 7.0 Wheezy) Linux ... 3.9.3-x86_64-linode33 #1 SMP Mon May 20 10:22:57 EDT 2013 x86_64 GNU/Linux OpenSSL 1.0.1e 11 Feb 2013 I just upgraded the Debian libssl1.0.0 package, and now your code says I am safe. I see there is the len(all_data) > 24 check. Should compiling my own Nginx have any effect on whether the exploit works? I would think not, but 2 different exploits failed (although maybe I didn't run it long enough). FWIW it was Nginx 1.0.12. EDIT: FWIW, now that I read Cloudflare's results, they think the Nginx server is only vulnerable shortly after being restarted. My server was running for months, which may have explained why it wasn't vulnerable. Oh well. http://blog.cloudflare.com/the-results-of-the-cloudflare-challenge http://blog.cloudflare.com/the-results-of-the-cloudflare-cha...
- einaros 12y ago
  No, the primes (and thus key) can be retrieved at any time, but it may be more frequently found right after reboot. I would recommend you to gather at least a gigabyte before digging for the key - preferably more. I dumped 43 GB from CloudFlare on Sunday, and found the prime 194 times in that dump. It can be found in much less time, however. Here's a test I just did against the CloudFlare server, resulting in the full prime 34 times in 60 seconds: https://twitter.com/einaros/status/456136820913238016 https://twitter.com/einaros/status/456136820913238016 The code from the second posted you noted (https://news.ycombinator.com/item?id=7577659 https://news.ycombinator.com/item?id=7577659) isn't mine. That one builds off of the original Python PoC, which fails for a lot of configurations. The Github code is the first publication I've done. Let me know if you see a server that's vulnerable, that the Github code fails to detect.
  - indutny 12y ago
    On other hand - you could try using my tool, and keep it running up until it'll find the key. It doesn't collect any dumps and does all processing in a real time.
    - einaros 12y ago
      I didn't actually write mine to collect primes :) I'm working with data dumped from other network devices, and for the most running various Yara rules during and after collection.
  - quasque 12y ago
    Was the other prime present in your 43 GB dump or just the one starting with 0xc4ea13ad? Or any other components of the private key? My own program only saved the snippets of memory in which a little-endian prime was detected - I didn't keep the rest of the data.
    - einaros 12y ago
      Doing realtime prime detection is trivial in mine as well. Either pipe the outfile or add to the lib. I didn't write the dump tool with keys as primary target; they just happened to be there.
      - quasque 12y ago
        Sorry, my comment may have come across as an unnecessary criticism of your technique rather than how I intended it - as mentioning a shortcoming of my program in not saving all data received, and that you may be able to get some interesting results from your dump by searching for other key data and in different formats.
        einaros 12y ago
        Ah. Well if you want to dig, I've still got the 43 GB from CloudFlare!

by einaros 12y ago

chubot 12y ago

Thanks for publishing. FWIW I tried your tools, and it said my server Nginx HTTPS was vulnerable, but I couldn't get any keys out of it. I created a 180MB dump file, and then scanned it, and it finished without finding keys (and I repeated this again) I also tried the code you linked here: https://news.ycombinator.com/item?id=7577659 https://news.ycombinator.com/item?id=7577659 This also failed, and it actually said my server was likely not vulnerable? I compiled my own Nginx, (but not my own SSL, that came from Debian 7.0 Wheezy) Linux ... 3.9.3-x86_64-linode33 #1 SMP Mon May 20 10:22:57 EDT 2013 x86_64 GNU/Linux OpenSSL 1.0.1e 11 Feb 2013 I just upgraded the Debian libssl1.0.0 package, and now your code says I am safe. I see there is the len(all_data) > 24 check. Should compiling my own Nginx have any effect on whether the exploit works? I would think not, but 2 different exploits failed (although maybe I didn't run it long enough). FWIW it was Nginx 1.0.12. EDIT: FWIW, now that I read Cloudflare's results, they think the Nginx server is only vulnerable shortly after being restarted. My server was running for months, which may have explained why it wasn't vulnerable. Oh well. http://blog.cloudflare.com/the-results-of-the-cloudflare-challenge http://blog.cloudflare.com/the-results-of-the-cloudflare-cha...

einaros 12y ago
No, the primes (and thus key) can be retrieved at any time, but it may be more frequently found right after reboot. I would recommend you to gather at least a gigabyte before digging for the key - preferably more. I dumped 43 GB from CloudFlare on Sunday, and found the prime 194 times in that dump. It can be found in much less time, however. Here's a test I just did against the CloudFlare server, resulting in the full prime 34 times in 60 seconds: https://twitter.com/einaros/status/456136820913238016 https://twitter.com/einaros/status/456136820913238016 The code from the second posted you noted (https://news.ycombinator.com/item?id=7577659 https://news.ycombinator.com/item?id=7577659) isn't mine. That one builds off of the original Python PoC, which fails for a lot of configurations. The Github code is the first publication I've done. Let me know if you see a server that's vulnerable, that the Github code fails to detect.
- indutny 12y ago
  On other hand - you could try using my tool, and keep it running up until it'll find the key. It doesn't collect any dumps and does all processing in a real time.
  - einaros 12y ago
    I didn't actually write mine to collect primes :) I'm working with data dumped from other network devices, and for the most running various Yara rules during and after collection.
- quasque 12y ago
  Was the other prime present in your 43 GB dump or just the one starting with 0xc4ea13ad? Or any other components of the private key? My own program only saved the snippets of memory in which a little-endian prime was detected - I didn't keep the rest of the data.
  - einaros 12y ago
    Doing realtime prime detection is trivial in mine as well. Either pipe the outfile or add to the lib. I didn't write the dump tool with keys as primary target; they just happened to be there.
    - quasque 12y ago
      Sorry, my comment may have come across as an unnecessary criticism of your technique rather than how I intended it - as mentioning a shortcoming of my program in not saving all data received, and that you may be able to get some interesting results from your dump by searching for other key data and in different formats.
      - einaros 12y ago
        Ah. Well if you want to dig, I've still got the 43 GB from CloudFlare!