We have a big one on our hands. Potentially affecting hundreds of thousands of websites, the Heartbleed bug - which was publicly disclosed on Monday night - exists in OpenSSL, a cryptographic library that secures a huge amount of web traffic.
The fallout from this disclosure is likely to continue for weeks and months to come. Web servers, as well as any program using an affected version of OpenSSL and exposed to the internet, are vulnerable. And although the bug was only announced recently, it has been present in OpenSSL versions released since March 14, 2012, giving savvy attackers ample opportunity to steal certificates or other sensitive information.
Here are some common questions surrounding the bug:
What is Trustwave doing to protect customers?
At Trustwave, our first priority since Heartbleed was disclosed was to determine any level of exposure in our own products and services and quickly release patches, if necessary, to make sure our customers are protected. For the most part, our solutions have avoided exposure to this vulnerability. However, we did issue hotfixes for Trustwave Secure Web Gateway and Trustwave Web Application Firewall. As a global Certificate Authority (CA), we also offer revocation and reissues of certificates to our SSL customers - free of charge. Our vulnerability scanner has been updated to detect vulnerable servers, and we released signatures for our intrusion detection system to detect Heartbleed-related attacks. Customers with additional questions may contact their sales representative or Trustwave support.
Why is Heartbleed such a big deal?
Heartbleed lies within a relatively new feature of OpenSSL, one of the most popular open source projects. OpenSSL is responsible for providing Secure Socket Layer (SSL) and Transmission Layer Security (TLS) encryption functionality (the 'S' in 'HTTPS'). SSL is what enables internet users to securely send sensitive information, such as passwords and credit cards, and is a cornerstone of modern e-commerce. According to estimates, OpenSSL is used on 60 percent of internet-facing, SSL-enabled services. While not all of these services will be vulnerable, the effects of this bug are widespread.
What's with the "Heartbleed" name?
The vulnerability was discovered in the 'heartbeat' function of TLS, which allows long-lasting connections to remain open without the need to re-establish the encryption channel. In a normal heartbeat, one side of the client/server connection will send a short request and the other end echoes the message back. Unfortunately, Heartbleed allows an attacker to confuse the receiver about how long the original message was, and in turn the receiver responds with not just the original message but up to 64k of additional content straight from the memory of the affected process. The attacker can repeatedly perform these malicious heartbeats to extract valuable information from the service on the other end.
So how can it affect my organization - or grandmother for that matter?
What can an attacker get in 64k chunks of memory? While they can't choose what they'll find, at least not directly, usernames and passwords, payment card details, cookies - essentially any information submitted by other users of the service - may be exposed. This information could be used directly (in the case of credit card numbers) or in a secondary attack after gaining access to accounts. The holy grail, though, are the encryption keys and certificates used by the server to authenticate itself. If an attacker is able to access a server's SSL private key, they can decrypt user traffic and impersonate the server - and it would be nearly impossible to detect them.
What does the future hold?
Considering the vulnerability has been present for two years, it's likely that sophisticated attackers have identified the bug and widely exploited it. To make matters worse, reviewing historic logs probably won't reveal any evidence of exploit considering the requests generated to perform the attack don't look particularly malicious.
Organizations will be hard pressed, if not unable, to glean whether their SSL certificate is compromised until an attacker is caught performing a man-in-the-middle attack (MitM). Users, through no fault of their own, are now exposed to nearly impossible-to-detect MitM attempts using these stolen certificates. Every server that is or was vulnerable to the Heartbleed attack is potentially compromised. As a result, certificate owners must act to protect their users and their reputations.
The situation sounds bleak. What should I do?
Users should check with their go-to websites that contain sensitive information, such as their banking and email providers, and ask them if they were affected. If they are, users should inquire whether they've patched the vulnerability. Once the provider has confirmed their service is fixed, users should also change their passwords.
Meanwhile, businesses that host their own affected SSL services should strongly consider revoking their current certificates, as compromise could lead to abuse of their users and damage to their reputation. SSL certificate owners will need to work with their certificate authority (CA) to reissue their certificates after vulnerabilities get patched. Many CAs will charge for this service, though Trustwave customers have free reissue for the life of their certificates.
However, self-signed certificates inherently cannot be revoked, leaving those certificates particularly vulnerable. Self-signed certificates normally generate warnings unless a user has specifically approved it for long-term use. These certificates should also be changed and removed from users' caches.
Are there any easy fixes for the SSL issue?
Perfect Forward Secrecy (PFS) is a seldom-used feature of SSL that provides additional protection in the event that a server's private key is compromised. PFS prevents an attacker from decrypting captured traffic unless they perform an active MitM. While this will not prevent the Heartbleed attack, it would slow down an attacker and help to limit the potential damage. Worth noting is that there can be a substantial overhead in using PFS and it may not be appropriate for all cases. Administrators of SSL-protected servers should explore if enabling PFS-capable cipher suites is a viable option for their environment.
John Miller is security research manager at Trustwave.
Editor's note: This is a developing story, and we may update this post in the future.
