| Didn't have any spare time to have a go at this, here's how I was going to do it:- 1) Create a VM with the same version of Linux, nginx, openssl. 2) Create a self-signed SSL certificate for the server 3) Verify that the HTTPS server is vulnerable to heartbleed 4) Run a few HTTPS requests against the server 5) Use gcore (or just send SIGABRT) to get a core file of the nginx process 6) Write a tool to check the memory image for remnants of the private key (since I know what it looks like). This may be encoded in several forms: as is from the ssl key file, hex encoded modulus, binary encoded modulus, however the BigNum stuff in OpenSSL stores the modulus, intermediate values used in calculations, etc. I can also check for partial matches since I know what the full key looks like. 7) Run the heartbleed client against the site to extract some chunks of memory, there are various strategies for this:- a) Repeatedly grab the largest (65535) bytes of memory each time b) Repeatedly grab different sizes (8KB, 16KB, etc) depending on the bucket sizes for OpenSSL's freelist wrapper around malloc. c) Vary the request size (lots more headers, etc) to try and get different chunks of memory returned. d) Occasionally restart nginx 8) Once I can reliably (for whatever value of reliably that is) get the key from my own server, I then modify the test for success from a comparison against the known private key, to a test which involves decrypting a string that was the result of encrypting some known plaintext with the known public key. That'll be slower, but still possible. 9) Run that analysis against real data retreived from the challenge server. The data (using the various strategies in #7) can be obtained in the background whilst I'm developing #1-#8. You can't rely on having sole access to the server so whatever strategy you use may be perturbed by other people performing requests. 10) Repeat #1-#8 for Apache and any other web server that is vulnerable to heartbleed. This does work on the assumption that the key (in whatever form it is in) will be returned as a contiguous block of memory. Trying to patch together chunks of memory to look for the key will be much much harder unless there's significant overlap and it's easy to detect what/where a key is somehow. |