The SANS Internet Storm Center dialed down the panic on Monday, resetting the Infocon to “Green” and citing the increased awareness of the critical OpenSSL vulnerability known as Heartbleed as the reason.
Still, the drumbeat of news about a serious vulnerability in the OpenSSL encryption software continued this week. Among the large-font headlines: tens of millions of Android mobile devices running version 4.1 of that mobile operating system (or “Jelly Bean”) use a vulnerable version of the OpenSSL software. Also: more infrastructure and web application players announced patches to address the Heartbleed vulnerability. They include virtualization software vendor VMWare, as well as cloud-based file sharing service Box.
If history is any guide: at some point in the next week or two, the drumbeat will soften and, eventually, go silent or nearly so. But that hardly means the Heartbleed problem has gone away. In fact, if Heartbleed follows the same pattern as other, similar flaws, it is unlikely to ever be eradicated. Rather, experts we spoke to say that the Heartbleed vulnerability will almost certainly become an endemic problem on the Internet: present and readily exploitable on a wide range of vulnerable and loosely managed application servers and host systems.
Consider another, recent flaw affecting SSL and TLS: the TLS protocol vulnerability exploited by SSL BEAST (Browser Exploit Against SSL/TLS). First revealed in late September 2011, BEAST exploits a weaknesses in cipher block chaining (CBC) to exploit the Secure Sockets Layer (SSL) protocol. It makes possible enable man-in-the-middle attacks against SSL implementations that use TLS 1.0, allowing an attacker to derive the authentication tokens used in SSL-encrypted communications, allowing attackers to decrypt data passed between a Web server and the Web browser accessing that server.
BEAST isn’t a perfect analogue for Heartbleed. As this blog post from Akamai points out, the BEAST vulnerability was a flaw in the underlying TLS protocol, not a coding error in a specific implementation of SSL/TLS (like Heartbleed). That means the impact of the BEAST vulnerability is much wider. It affected most SSL implementations, not just OpenSSL. As we approach the three year anniversary of the SSL BEAST disclosure, close to three quarters of all web sites surveyed (72%) are vulnerable to SSL BEAST-based attacks. Following public outcry and media attention, some large vendors, like Microsoft, acted promptly to patched the flaw. Others took a cautious approach. (Siemens just issued its BEAST patch for the Ruggedcom Wimax product line last week.) Many more sites and vendors have chosen to mitigate rather than outright patch the vulnerability.
Will Heartbleed go the same route?
“My guess is the answer is ‘Yes,'” said Andy Ellis, the Chief Security Officer at the firm Akamai. “There’s no indicator that Heart bleed will be significantly different (than SSL BEAST).”
The reasons, as Ellis sees it, are both different and the same. Fixing the SSL BEAST vulnerability required action by parties up and down the chain of trust. Server admins had to upgrade their SSL libraries and configure their servers to support TLS v 1.1 and 1.2, which were not vulnerable to SSL BEAST. But, at the time, versions 1.1 and 1.2 were not as mature and proven in production employments as Version 1.0, the vulnerable version. Application providers worried that switching to the newer libraries could result in a failure and website outage. That was a big disincentive, given the difficulty of carrying out a successful BEAST attack.
Beyond that: popular browsers at the time, including Chrome, Mozilla and Safari, didn’t support TLS v1.1 or v1.2. Given that web sites need to support legacy browsers of all types, outright fixes for SSL BEAST have often taken a back seat to other remediation efforts that wouldn’t run afoul of older browsers.
In the case of Heartbleed, the damage is limited to OpenSSL, but structural challenges with the system of certificate issuance and revocation will complicate efforts to eliminate the vulnerability altogether, said Ellis. For one thing: the CA system wasn’t designed for what he referred to as ‘epochal’ events like Heartbleed, involving the simultaneous cancellation and reissue of signing certificates by tens of thousands of organizations.
Even now, it’s not clear how the system will handle the flood of certificate swaps in the weeks ahead. Certificate revocation lists (or CRLs) are not foolproof and have been abused in the past, said John Miller, a security research manager at the firm Trustwave.
Beyond that, many certificate issuers have strengthened the procedures for renewing certificates, following high profile incidents at Diginotar and Comodo, in which fraudulent certificates were issued and used in sophisticated cyber attacks. While most CAs allow customers to cancel and reissue certificates automatically, others have instituted manual processes for verification that will complicate the process. “For those (CAs) it’s going to take longer,” Ellis said. “I wish I had an estimate for it.”
And, as with BEAST, the ripple effects of Heartbleed are extensive and, in fact, are still being studied. It is hard to judge how smaller OpenSSL users affected by Heartbleed will choose to respond – if at all, said Miller.
Certificate authorities are in an easier position vis-a-vis their customers. They can update their version of OpenSSL, then work with customers to revoke and reissue certificates they have signed. But smaller players may use self-signed certificates that are harder to track and may not be revoked, Miller said.
Miller said he expects the focus of remediation to shift from web sites to other clients and services that rely on OpenSSL and that are also vulnerable. They include FTP, SMTP, FXTP and others. Ideally, affected applications would issue patches to users. At the very least, they should acknowledge that the Heartbleed vulnerability affects their service and that users might be vulnerable to snooping, Miller said.
Even in the best case scenario, experts like Ellis expect that a certain percentage of systems will remain vulnerable to compromise via the Heartbleed attack for months, years or longer. That will include client endpoints, as well as more powerful web-based platforms like WordPress and Joomla that are a favorite target of cyber criminals and others, he said.
Heartbleed is likely to add to the ranks of systems that are what Ellis calls ‘public health nuisances.’ “The question is: at what point do we hit a watershed with all these unpatched systems that then become useable in DDoS attacks and such?”
“You have certain systems that are not maintained, but what do you do about them? Do you exclude them from the Internet – have a blacklist of servers where you’re saying ‘these systems are dangerous?'”