There’s been a major security alert over the last week regarding the heartbleed bug in OpenSSL (see the OpenSSL Advisory). A vast number of systems and sites have been affected, this is no storm in a teacup – it’s serious, and cannot be ignored.
OpenSSL is a component used to provide secure communications protocols for HTTPS websites used by a wide variety of systems (Twitter, Facebook, Remote VPNs, Remote Admin interfaces..) from a wide variety of vendors (Cisco, Big IP, Juniper, McAfee, Apache…), which means that it has hit a huge number of services and companies across the globe, from the likes of Google and the Canadian Revenue Agency to the shop around the corner running a simple payments page over HTTPS.
So, what is this bug exactly?
The flaw was discovered in the method used to implement TLS Heartbeats. These can be used to maintain long-lived TLS sessions. To create a heartbeat, either the client or the server can request some data from the other. The way they do this is to send a request with the data, and here’s the fun part, the length of the data sent [*].
Client: Hi Server, send this back to me : Carrots, 7 letters long
Server: Hi Client, I’m still here, proof: Carrots
All well and good. But what if we send a short sentence, and tell the peer we sent a long one?
Client: Hi Server, send this back to me: Car, 10 letters long
Server: Hi Client, I’m still here, proof: Car.FHULWF
Aha! What have we here? We get the original string back, plus an additional 7 characters from whatever was in the memory of the process after the string we sent. The protocol allows for up to 64Kb of data to be sent, so the attack basically sends one byte of data, and gets over 63,000 extra ones back.
This could be anything in the memory of the process being compromised – other web pages, secure pages, usernames, passwords, your private SSL keys…. it’s serious. As an example, the Canadian Revenue Agency has determined that approximately 900 Social Insurance Numbers were leaked due to this bug, and Yahoo! were reported to be leaking usernames and passwords of their users before they had patched as well.
You don’t need to authenticate against the server to do this, so there’s no need to know any existing secrets or to have an existing account. Worst of all, there’s every chance that it won’t be logged either as the session does not need to even request any actual web pages.
So what do I do?
You need to do three things, in this order:
- Patch
- Re-generate your private keys, revoke and re-issue your SSL certificates
- Change your passwords for the affected services
Right, I’m convinced. But what do I patch?
At the most basic level, you need to patch OpenSSL, which is the root cause of the issue. This affects all versions of OpenSSL from 1.0.1 to 1.0.1f. A fix has been released in version 1.0.1g, and older versions are NOT affected. The catch here is that OpenSSL is a component of other systems, and as it is an open source product, it can be (and has been) included in other commercial systems. The key to tracking down what needs to be patched is your software and hardware inventory which, in conjunction with vendor advisories, will help you narrow down what needs to be updated. For our own managed service customers, we maintain inventories that have enabled us to rapidly identify and update our customers systems. Without such lists, you will need to treat anything serving or terminating a HTTPS connection as suspect until you can examine and prove otherwise. Vendor advisories are also critical, as you may have no way of knowing what a commercial system is using to terminate HTTPS until your vendor can confirm it.
As a starter, The following systems are known to be affected:
- Big IP F5 (versions greater than 11.0, or if using COMPAT ciphers)
- FortiOS 5 and up
- Aruba 6.3.x, 6.4.x
- Centos & RedHat Linux using stock OpenSSL libraries versions 6.5 and greater
- Debian Linux 7 and up when using stock OpenSSL libraries
Other vendors have reported in the negative for issues (e.g. Checkpoint) or have yet to respond. We strongly recommend that everyone should check their environments for this vulnerability.
References:
http://xkcd.com/1354/
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
http://heartbleed.com
http://security.stackexchange.com/questions/55116/how-exactly-does-the-openssl-tls-heartbeat-heartbleed-exploit-work