A serious security flaw was discovered in OpenSSL several days ago. It is related to the Heartbeat TLS/DTLS extension and may cause critical data leaks.

 Details of the issue.

The Heartbeat TLS/DTLS extension provides keep-alive functionality to a TLS/DTLS session without renegotiation. In fact it is a pretty simple request-response protocol. Its implementation in OpenSSL was a bit incorrect, an array bounds check was missing and it could be used to reveal up to 64kb of memory to another endpoint. It is very bad: sensitive data may be stored in system memory including private keys, passwords and so on. It means that an attacker has the ability to steal such data. The worst news is that there are no traces in attacked system at all: no crashes, no warning logs.

Affected OpenSSL release versions list: 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1

The issue was fixed in OpenSSL release 1.0.1g

See http://heartbleed.com/ for more details. Technical information including links to patches is available at https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160

Impact

The security impact caused by this flaw is huge. First of all OpenSSL is a very popular implementation of the SSL/TLS protocol and it is very widely used for securing websites, email, XMPP, VPN communications, etc. As long as the bug allows a remote attacker to read process memory data, it allows them to steal private keys used by OpenSSL. As a result all private keys which were ever used by vulnerable OpenSSL versions should be as assumed to be compromised. Stolen keys allow attackers to build MiTM attacks and get users’ sensitive data including passwords, credit card numbers, etc.

What should be done as soon as possible?

The following steps are highly recommended to mitigate the consequences of this issue.

1. Check the OpenSSL version which is used in your services. A list of vulnerable versions is provided above. Many major vendors have already published security updates to OpenSSL and it is necessary to update to any non-vulnerable version as soon as possible. If you already have a non-vulnerable version, check if you had a vulnerable one before. For HTTPS testing you can use https://www.ssllabs.com/ssltest/, but note that every SSL/TLS connection is potentially vulnerable at the moment, not only HTTPS.
2. All TLS certificates used by vulnerable OpenSSL versions should be revoked and replaced. Their private keys should not be used anymore.
3. It is necessary to identify what infrastructure objects could be potentially attacked, and what additional data may be leaked using stolen TLS private keys. It makes sense to demand users reset their passwords and notify them that sensitive data may have been leaked.
4. It makes sense to perform an infrastructure security audit to check if there are any backdoors installed by attackers manually if your system was hacked using stolen private keys.
5. It is necessary to check that any services you use are not vulnerable at the moment. Vulnerable third-party services may affect your clients.