Share with Your Network
Yesterday, the information security community was made aware of a critical vulnerability in some versions of OpenSSL, one of the most commonly used software “libraries” for secure internet communications. When your web browser is connected via HTTPS (your less tech savvy friends might refer to it as the “lock icon”), there is a high probability that OpenSSL is involved in your communication with that website. It is the job of software like OpenSSL to ensure that your communications are unreadable and unmodifiable by anyone who might be listening in, which is especially important for communication of sensitive data.
It is important to note that this vulnerability affects nearly everyone, from small businesses to internet giants. I won’t go deep into the technical details of how the vulnerability works, which can be found at http://heartbleed.com/, but will instead talk about its impact and the steps Risk I/O is taking to keep your data safe.
In simplified terms, TLS/SSL secure communication requires a server to have a certificate and a private key. When your web browser connects to a server, it is given the certificate, which includes a special one-way key. The certificate is used to verify that the server is who it claims to be. The embedded one-way key is used to send messages that can only be read by someone with the server’s private key. An important point here is that even a legitimate client/user of the website should not be able to access the private key. For communication to remain secure, the private key must NEVER be readable by anyone except the server.
When a webserver is started, it loads the private key into memory, allowing it to reference the key whenever it is needed to send or receive a message. The vulnerability, CVE-2014-0160 or “Heartbleed,” allows an attacker to read (somewhat random) portions of the server’s memory in chunks up to 64kb in size. See where this is going? The private key is the most important thing protecting communication, and the vulnerability allows you to read random bits of data right out of the server’s memory, which means with enough tries you will have a complete map of everything including the prized private key.
As security practitioners ourselves, we have been working to mitigate the impact of this vulnerability. Our external load balancer software has been upgraded with the latest version of OpenSSL, which has fixed the bug. Unfortunately, because there is no way to detect whether the vulnerability has been used to steal private key information, we have also taken the step of revoking our old certificates and creating new private keys for https://www.risk.io. This change was made without user impact, and ensures that if a third party did gain access to our private key, they cannot use it to intercept or modify communications between Risk I/O and our users.
We monitor all communication in and out of our infrastructure, and we have no reason to believe any user data was intercepted during the short window where we were vulnerable. That said, and in the interest in being proactive, we will begin requiring our users change their password when they next log into Risk I/O.
In summary, this vulnerability sucked. Seriously sucked. The long term impact of CVE-2014-0160 remains unclear, but the prompt response from security-focused organizations has likely done a lot to mitigate what could have been a much more serious issue.
