What you need to know about Heartbleed
Vendors and site administrators are scrambling to close the gaping hole opened by Heartbleed, a remotely-exploitable bug in the OpenSSL crypto library widely used to enable TLS sessions. But Heartbleed doesn’t just affect web servers. Given pervasive use of OpenSSL in a broad array of networking products and the two-year existence of this TLS implementation bug, Heartbleed’s attack surface and potential impact are very significant.
What is Heartbleed?
Heartbleed refers to a vulnerability recently discovered in the Transport Layer Security (TLS) heartbeat protocol implementation contained in OpenSSL. When a TLS server using a vulnerable version of OpenSSL (1.0.1 to 1.0.1f) receives a Heartbeat Extension message that has been crafted to cause buffer over-read, the server responds with up to 64 KB of random memory content.
According to CVE-2014-0160, heartbeat responses have been observed to contain sensitive data, including server certificate private keys, TLS session keys, user logins/passwords, and message contents. An attacker could send many heartbeat requests to harvest a significant portion of a server’s memory without raising suspicion. The request is encrypted and not logged by OpenSSL. However, it might be possible for an IPS to detect/block excessively frequent and lengthy TLS heartbeat responses.
More information about the Heartbleed bug, affected versions of OpenSSL, and fixes can be found here:
Why should I care about Heartbleed?
The damage potentially done by Heartbleed is extensive, in part because TLS servers and clients process quite a bit of sensitive information with potentially long-lasting utility to attackers.
For example, if Heartbleed were used to harvest primary keying material associated with an X.509 server certificate, that certificate can no longer be trusted for server authentication. Renewing the certificate does not mitigate this risk – the certificate must be revoked, reissued, and reinstalled.
If Heartbleed were used to harvest administrative passwords, or user credentials sent over a TLS-encrypted session, those stolen credentials could be used to compromise user accounts and associated profiles and stored data. If Heartbleed were used to harvest TLS session keys, those keys could be used to decrypt captured session traffic at any time. And so on.
Furthermore, the Heartbleed bug has been in OpenSSL code for about two years now, creating a large window of opportunity for past exploitation. Developers can take steps now to eliminate the bug – either by updating OpenSSL or by recompiling affected code with the configuration option -DNO_OPENSSL_HEARTBEATS. However, nothing can be done now to retroactively identify previously-harvested data. Instead, we may need to assume that implementations using vulnerable versions of OpenSSL were probably exploited by someone, somewhere.
Por que? According to http://www.heartbleed.com, pervasive open source web servers like Apache and nginx use vulnerable versions of OpenSSL; together, this software now runs on over 66% of active Internet websites. In addition, OpenSSL is used by many SMTP/POP/IMAP email servers, SSL VPN gateways, and network appliances – including WLAN routers, APs, controllers, and related infrastructure.
How could Heartbleed impact my WLAN’s security?
For starters, WLAN products that are manageable via HTTPS may be vulnerable to Heartbleed. This likely includes many residential wireless routers managed via web interfaces secured via OpenSSL. It may also include remotely-managed APs and WLAN controllers that use OpenSSL libraries, either to secure administrative interfaces or to secure built-in guest access portals. So watch for security notices and firmware updates issued by your WLAN product vendors, and take steps to minimize your risk of bug exploitation in the meantime – such as disabling remote WLAN management or applying ACLs.
In addition, X.509 server and client certificates generated using OpenSSL and used for WPA2-Enterprise 802.1X authentication may need to be revoked and reissued. Look at the CA system or service used to generate them to assess Heartbleed vulnerability, and also any vulnerable systems where these certificates might have been used along with the certificate’s private key.
Furthermore, as vulnerable network devices are identified, consider the credentials and settings that might have harvested in the past and take steps to deter future misuse of that information. For example, a vulnerable AP or WLAN controller might also leak other admin logins/passwords or configuration details stored in memory, such as PSKs used for WPA2-Personal authentication.
To the extent that your organization develops software which uses the OpenSSL library, move quickly to upgrade to a fixed version of OpenSSL and/or compile out TLS heartbeats as described above. Tools are now being circulated to pentest your own code / server for this vulnerability to Heartbleed (see http://www.heartbleed.com).
Finally, leverage your security and surveillance systems to key an eye on traffic – not just unusual TLS traffic or long TLS heartbeats, but unusual admin or user logins or other behaviors that might signal use of previously harvested information. In short, put yourself and your network on high alert until the dust settles and more details about possible impacts and consequences are known.