April 2014 Archives

Privacy and security folks rely on encryption as a means to ensure the confidentiality and integrity of information, protecting it at rest and in transit. But what happens when a fundamental control is thoroughly compromised? When a protective control becomes an attack vector? How should we react?

It is critical to note that proof of concept exploit code is already in the wild. This is not a theoretical emergency.

Today, we should be activating Incident Response Plans (or screaming, loudly, with hair on fire) within our organizations to do the following:
  • Identify all external and internal sites using SSL/TLS
    • This could be a website, API interface, e-mail connection, VPN concentrator, etc.
  • Check if they are vulnerable 
    • There are a few sites offering to "check if you're vulnerable" ; however, don't rely on them. They could be actively exploiting you and you wouldn't know it. Keep it in house.
    • Note for above: your client must support 'heartbeat' otherwise you will get false positives.
    • Find one of your system admins and have them conduct a check:
    • The following command (or something similar) can provide quick feedback (replace google.com with the target server)
openssl s_client -connect google.com:443 -tlsextdebug 2>1 | grep 'server extension "heartbeat" (id=15)' || echo safe
  • If the site is not vulnerable, celebrate. You've avoided the heartbleed problem but...
    • Don't celebrate too hard, it likely means you're running a very old OpenSSL version and are vulnerable to many other issues.
  • If the site is vulnerable, do the following:
    • Patching affected systems to OpenSSL 1.0.1g
    • Update any other dependent software/hardware
    • Procure new certificates
    • Revocation of the old keypairs that were just supersceded
    • Changing all passwords
    • nvalidating all session keys and cookies
    • Evaluating the actual content handled by the vulnerable servers that could have been leaked, and reacting accordingly
    • Evaluating any other information that could have been revealed, like memory addresses and security measures
    • Ensure all end-user browsers all check Certificate Revocation Lists, this functionality is generally off by default
Updating certificates will cost you money. However, the risk is that your site has already been compromised before you remediated the risk. If someone has your private key, you're forever compromised until you replace the certificates. Since, as of writing this, you cannot tell if you've been compromised or not, it is much better to err on the side of caution and spend the money replacing your certificates. 

In some cases, hardware based platforms will not have a quick fix for this vulnerability. You should have conversations with your IT, Business, and Security Operations people. Investigate the possibility of unplugging that piece of hardware, depending on how critical it is, until it can be fixed. This is a big decision and trade offs will need to be understood thoroughly. However, the gravity and seriousness of the heartbleed situation should be clearly communicated. This is the fire drill we never really wanted to have.

-------------------------- Background on OpenSSL and vulnerability --------------------------

OpenSSL (wikipedia) is an open-source implementation of the SSL and TLS protocols. The library is supported on multiple OS platforms (Unix, Windows, etc) , multiple connection types (web, email, VPN, XMMP chat, APIs, etc.), and is extensively used. Trust me when I say, it's in your environment. Likely in many places. Specific OpenSSL versions have a vulnerability that can completely compromise all information transmitted over the connection, rendering the protection moot. The vulnerability allows for compromise of the private keys on the server side. The attack, so far, is not detectable. This is very, very, bad.

Questions? Concerns? Comments are welcome below and on twitter @PrivacyWonk.

Security Advisory from OpenSSL - https://www.openssl.org/news/secadv_20140407.txt

OpenSSL Security Advisory [07 Apr 2014]

TLS heartbeat read overrun (CVE-2014-0160)

A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
preparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.0.2 will be fixed in 1.0.2-beta2.
Additional Sources: