The Heartbleed vulnerability has created a massive news cycle, and generated technical risk-based discussions that might actually do some good. But some of these discussions boggle the mind, spreading misinformation in order to generate clicks or sales.
When security issues hit the mass media, such as Heartbleed, there is a good deal of Fear, Uncertainty, and Doubt – better known as FUD – that gets promoted on the airwaves and in print.
"Police say Canadian man used Heartbleed virus to steal personal info
"Heartbleed virus: Changing your password may not eliminate risk"
These headlines promote FUD because Heartbleed isn't a virus. Heartbleed is a vulnerability in libssl (the portion of OpenSSL supporting TLS). They're just two examples, but several news agencies have allowed the term virus to be attached to Heartbleed. That's unfortunate. There is no way someone can send you a file and infect you with Heartbleed.
In the business world, issues like Heartbleed can cause headaches and panicked discussions, as business leaders attempt to understand the bigger picture. This leaves some security professionals caught in an endless loop of explaining the problem while removing false notions.
The latest false notion Heartbleed was pitched to me earlier this month.
"Many organizations were not ready for Heartbleed, and sadly, many will likely not be ready for its mutations. Vulnerabilities like Heartbleed take advantage of an overreach flaw in the SSL heartbeat protocol and the truth is that there will be unknown mutations that might force you to reactively patch your devices, effecting the network or server's performance, privacy, and trust." - Chris Chapman, Technical Manager at Spirent
There will be no mutations of Heartbleed. This is just as good as calling it a virus. The reason that there can be no mutation is simple, Heartbleed is a single vulnerability, that impacts a subset of libssl deployments.
Those who use a vulnerable version of OpenSSL with the heartbeat option enabled were in trouble, those who don't use OpenSSL, or who used it without the heartbeat option, were not impacted by this flaw.
Spirent also listed five items of note as related to Heartbleed and the products / services they are trying to promote. I've listed all five below, with additional commentary.
5. Web servers may still be vulnerable to Heartbleed.
Rapidly deployed and inadequately tested security patches from the system vendors means that many devices and networks may still be susceptible to Heartbleed and its variations.
The patches and mitigation steps needed to address the Heartbleed vulnerability were documented and tested before being released to the public. Administrators were encouraged to weigh their options and to patch as appropriate. Most did, but others didn't need to patch as they didn't use OpenSSL, or they recompiled and disabled heartbeat until they could investigate further.
There were problems with some of the fixes released by infrastructure firms, but those were quickly addressed and no one suffered because of them. At best, Heartbleed patching caused short bursts of downtime that fall well within most SLAs.
In fact, the aftermath of the Heartbleed issue has led to additional development, including a fork of the OpenSSL project. Even better, the Linux Foundation has secured resources from the Web's largest firms in order to address security in various open source projects; the first recipient will be OpenSSL itself.
4. Heartbleed will mutate.
Heartbleed will likely mutate into hundreds or even thousands of variants. Software patches may not mitigate upcoming attacks.
No. Again, Heartbleed cannot mutate. This will not happen. Your server or product is either vulnerable to Heartbleed, or it isn't. End of story. If it is vulnerable, patch it. Patching against Heartbleed is exactly how you mitigate against such a vulnerability.
3. Multiple software patches can be a weak link.
Most organizations will have multiple devices requiring patches that may not all work together and inadvertently expose the network further.
2. Patches may break performance.
Urgently applied Heartbleed patches may impact network performance and quality of experience (QoE) of the IT networks.
Heartbleed doesn't have multiple patches. It is a single vulnerability; therefore it has a single patch. If the server or product is vulnerable, patch it with the proper fix from the vendor.
But again, in the security world, the majority of administrators test their patches first, widely deploy second. If something breaks, they have the ability to reverse the process. Heartbleed patching is, at its core element, no different than patching an Internet Explorer vulnerability.
1. Heartbleed-like vulnerabilities could happen in any protocol.
While Heartbleed is a SSL/TCP flaw there are other protocols such as TCP, HTTP are just as susceptible, so preparing for that eventuality is critical.
I'm assuming this is a typo. As Heartbleed impacts SSL/TLS, but using generic protocols like TCP and HTTP is a bit unfair and serves little purpose.
In response to massive criticism over the aforementioned five points, Chris Chapman published a blog clarifying his company's position.
"There are many ways of mutating attacks – the specific danger we wanted to address was technique mutation. Specifically when a pathway of attack works, malicious entities take that technique and apply it to other state machines, both close and distant to the original state machine, in an attempt to find other pathways of entry. Furthermore, variants of the technique may also attempt to gain entry. Together, these techniques of entry hunt for weaknesses in the protocol. In fact, we have already seen this happen."
Chapman cited a recent Mandiant post about how attackers exploited Heartbleed to hijack VPN sessions and bypass two-factor authentication as an example of what he's describing.
However, the VPN concentrator that Mandiant discusses was vulnerable to Heartbleed, so the criminals exploited that vulnerability and compromised VPN accounts. How did the company address the issue? They patched the VPN concentrator against the Heartbleed flaw.
In concluding his clarification, Chapman added:
"These are examples of how hackers are using the Heartbleed techniques in a slightly different way to successfully find new holes. There is also no reason why the exact technique of Heartbleed must be static. Small or large, technique changes (mutations) could also pose a threat."
That's the problem. They're not finding new holes. They're exploiting a single hole on multiple surfaces. Heartbleed is the vulnerability, if servers and other devices are patched against it, then it's no longer an issue.