Another huge blunder this week in the ubiquitous OpenSSL library secadv. This one’s called Heartbleed. You can easily check if your services are vulnerable at filippo.io/Heartbleed. This one is particularly scary as it allows reading random private memory directly from the server/device/etc. This may include decrypted SSL transactions, certs, private keys, and other random memory. So far I have only seen other SSL requests, and public certificate chains from my own devices.
XKCD has a comic which explains Heartbleed VERY well.
The implications are huge. Luckily it only affects OpenSSL 1.0.1 to 1.0.1f (and some beta 1.0.2 versions.. but you’d never run beta in production right?). 1.0.1g is not affected. Older versions are OK here as well. So my recent push for Upgraded SSL Ciphers bit me in the ass. Some of the various devices affected are included in this advisory from NSCS-FI. There are a lot of devices which use OpenSSL. There are many, many Linux/BSD distributions which shipped vulnerable OpenSSL packages/libs as well. Again, like the other SSL problems earlier this year, there will be implications from this for a long time because all sorts of embedded systems and devices won’t get updated (potentially ever).
Here is an interesting chunk of memory pulled from a vulnerable firewall using one of several widely available ssltest.py POCs. This is someone elses encrypted request body. Someone, or more likely something pretending to be a Googlebot, and sending a php file attachment with some badness in it. I would not recommend running the below hex decoded PHP code in the request, nor downloading the f.txt (and especially not executing it), unless you are a malware researcher.
Update several days later:
So the majority of the pain is over. Systems are patched and updated. Passwords changed. Certificates reissued (this was surprisingly easy!) and re-installed on various devices. Luckily for my usage, all of my OpenSSL 1.0.1 systems had PFS enabled, so private data should be private.