More than a month after the world learned of the epic, headline-grabbing Heartbleed flaw, the severe OpenSSL vulnerability...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
can still be found on hundreds of thousands of servers -- and some other not-so-obvious spots -- thanks to an inconsistent industry-wide response.
The Heartbleed bug -- the result of a missing bound check in the handling of the TLS heartbeat extension in the widely used OpenSSL encryption library -- was first introduced into the OpenSSL code back in December 2011, but wasn't discovered until early April 2014.
There is no one-size-fits-all solution here; unfortunately, organizations will have to make decisions based on their own risk tolerances and costs.
Carnegie Mellon SEI CERT
Heartbleed potentially exposed sensitive data stored in the memory of millions of servers and clients, and though there is no proof that the flaw was successfully exploited before it was revealed -- or that it is even worthwhile for attackers to exploit in most scenarios -- during the past month Heartbleed has been used both in real attacks and simulations.
Still, despite a widespread effort by the information security industry to explain the dangers of Heartbleed, the flaw is still widespread. In a blog post last week, Errata Security CEO Robert Graham said he had scanned the Internet for port 443 and found that more than 300,000 systems remained vulnerable to Heartbleed -- a significant number, though down from his estimate of 600,000 vulnerable systems a month prior. Graham noted that he did not include other well-known SSL ports like SMTP, and that he found around six million fewer systems this month.
"The numbers are a little strange. Last month, I found 28 million systems supporting SSL, but this month I found only 22 million," Graham said. "I suspect the reason is that this time people detected my Heartbleed 'attacks' and automatically firewalled me before the scan completed. Or, another problem is that I may have more traffic congestion at my ISP [Internet service provider], which would reduce numbers."
Shockingly, even in cases where companies and users are taking steps to mitigate Heartbleed, rudimentary mistakes are plaguing the process. Last week, analysis firm Netcraft published a finding that suggested only 14% of websites affected by the vulnerability have performed all three steps required to fully mitigate the issue: replacing their SSL certificates, revoking old certs and using a different private key when issuing new certs.
Netcraft found that 57% of affected sites had taken no action in response to Heartbleed. Another 21% of sites reissued certificates with a new private key, but failed to revoke the old certificates. The final 5% issued new certificates without changing the private key -- a grave mistake that Netcraft noted was made by certain Canadian government sites, including the Quebec Automobile Insurance Corporation, even after being one of the few known victims of a Heartbleed-related attack.
"One of its websites at secure.saaq.gouv.qc.ca was issued a new SSL certificate in response to the Heartbleed bug, and the previous certificate was revoked on April 29," the Netcraft post said. "The CRL revocation status listed the reason as "keyCompromise", but the issuing certificate authority nonetheless allowed the new certificate to be signed with the same private key. This means the new certificate can also be impersonated by anyone who is in possession of the compromised key."
The reach of Heartbleed extends beyond Web servers, as well. The Industrial Control System Computer Emergency Response Team (ICS-CERT) issued an advisory last week warning that Heartbleed is present in five products made by Digi International, a provider of machine-to-machine products and services that can be found in many SCADA and ICS environments.
From the editors: More Heartbleed coverage
Software security expert details the real lessons learned from Heartbleed.
Learn how hundreds of thousands of revoked certificates may affect the Internet itself.
Google says the impact of Heartbleed on its Android mobile OS is limited, but is that really the case?
Sister site SearchNetworking rounds up the latest actions by networking vendors to mitigate Heartbleed in their products.
Even Canadian mobile giant BlackBerry was forced to update a number of its products -- including its BlackBerry Messenger app for Android and iOS, BlackBerry Enterprise Service 10 and BlackBerry Link -- joining the long list of vendors such as Apple, Oracle, Siemens and others that have released Heartbleed-related security patches.
The response by enterprises and government organizations may be considered swift and efficient compared to that of everyday consumers; however, as an online survey of 2,000 U.S.-based adults by identity theft services provider LifeLock found, among those that had heard of Heartbleed, nearly half had yet to change their password. When asked why, 44% indicated that they simply weren't concerned by the security implications of the vulnerability, and another 12% thought changing passwords would be to "overwhelming."
While a dozen of the largest tech companies in the world recently promised millions in funding to help secure OpenSSL and other vital open source projects against the next Heartbleed, the current vulnerability has clearly not been put to bed. In a Q&A session this week for the Carnegie Mellon Software Engineering Institute CERT, staff member Jason McCormick advised organizations affected by the flaw to upgrade to the newest version of OpenSSL and conduct a thorough risk assessment to discover the extent of the problem.
"The big gray area is what to do next. There is no one-size-fits-all solution here; unfortunately, organizations will have to make decisions based on their own risk tolerances and costs," McCormick said. "Every organization should immediately be re-issuing certificates on Internet-facing systems that were vulnerable to Heartbleed as quickly as possible. The potential compromise of private key material that could be used for decryption of captured data or the impersonation of sites makes this an important consideration."