Security experts consider the Heartbleed bug to be a very serious issue, and one that will require action by most Internet users – not just for businesses – bringing the topic of information security home for web users everywhere.

“It's a pretty significant bug, particularly since it impacts popular open-source web servers such as Apache (the most popular web server) and Nginx,” explains ISACA director of emerging business and technology, Ed Moyle. “One significant area that has been covered less in the industry press is the impact this issue could have outside of the population of vulnerable web servers. Now clearly, the impact to web servers is a big deal. But consider for a moment what else might be impacted by this.”

In other words, he explains, consider the impact on embedded systems and "special purpose" systems (like biomed or ICS). “OpenSSL has a very developer-friendly license, requiring only attribution for it to be linked against, copied/pasted or otherwise incorporated into a derivative software product. It is also free. This makes it compelling for developers to incorporate it into anything they're building that requires SSL functionality: everything from toasters to ICS systems, medical equipment, smoke detectors, remote cameras, consumer-oriented cable routers and wireless access points. It's literally the path of least resistance as a supporting library/toolkit when developing new software that requires SSL.

“We've seen an analogue of this in the past. Remember the fallout from the string of ASN1 parsing vulnerabilities a few years ago (for example, CVE-2003-0543 and CVE-2003-0544)? Take a look at the long list of products and vendors affected by that bug in the link above. The underlying reason for the wide reach of that problem is that the code for ASN1 parsing was reused and recycled so extensively in other products.

Because ASN1 parsing is hard to do, finding code that does it already and incorporating it into derivate software is a huge timesaver. Likewise, SSL functionality is complicated to write – it is advantageous to incorporate something that is already written (like OpenSSL), particularly when doing so doesn't incur additional cost to you or lock you in to a particular operating system platform, such as with OS-specific proprietary libraries.

“From a practical standpoint, there are a few ramifications to this. While a webserver can be upgraded (relatively) easily to use the fixed OpenSSL code, an embedded system is quite a bit more challenging to upgrade. Upgrading a biomedical system, for example, without careful coordination with the vendor who supplies it can (quite literally) have a life and safety impact to patients. Upgrading an ICS system, likewise, requires careful coordination and specialised testing.

Moyle believes recovering from this issue could take years. So what can organisations do about it in the meantime? Patching webservers is a good idea, according to Moyle. “Folks who run websites might also wish to consider getting a new certificate since it's possible private key data might have been exposed. Everyday users might consider changing their passwords since they could have been exposed.

Moyle reckons the longer-term issue that could be lurking in embedded devices or specialised systems is a thornier issue. “One thing that could be helpful is encouraging vendors of those systems to confirm explicitly (and in writing) that they are not vulnerable to this if they provide SSL functionality (or to provide instructions on remediation if they are). By doing this, organisations with a population of these devices can get an assurance that someone at the vendor has at least evaluated the issue and how it might impact production deployments.”

Impact in the cloud

Clarification over the specifics of the exploit are now essential to get to the meat of the risk at hand, according to Mark Bower of Voltage Security. "This is about SSL transport use of OpenSSL, not using OpenSSL’s other functions like math libraries commonly used in applications and unrelated to this exploit.

“However, to show how easy it is to compromise a system, we set up a typical web server and demonstrated this attack using trivially simple Python scripts created in about 30 minutes to pry open 64k of server memory in the test server loaded with the affected library. The SSL session doesn’t even have to complete – it just has to start. This is a worst-case scenario: easily exploitable and highly effective, allowing a virtual bank robber to repeatedly grab hefty handfuls of data from inside the bank safe without touching the lock.

"One of the biggest unknowns is in the cloud, and by that I mean all SaaS, PaaS and IaaS providers like Amazon, Rackspace, Google and others. The cloud creates a far more insidious challenge – as OpenSSL is very likely part of downstream systems and services well outside the remit of scanning tools or even the end users knowledge, yet still vulnerable, exposing highly sensitive data deep inside. So now the question that the providers need to answer is – what exactly was at risk? Given the vulnerability has been exploitable for two years that could be the entire data inventory of a company."

He believes Heartbleed might also solve some of the mysterious large scale password dumps that have been found in the last 12 months that are not attributable to specific attacks – like the 360 million passwords found in February 2014.

By now, we know that some key sites , including Twitter, Linked-in, Amazon, Paypal, HSBC, Lloyds, RBS/NatWest and Co-op – were not affected by the bug, and hence that passwords will not have to be changed by users of these sites. But, as Futurologist Christopher Barnatt points out, lots and lots of sites were probably were, including Google and Facebook. “Users of any site which may have been affected really ought to change their passwords,” he explains, “but not necessarily right now – as the websites need time to implement fixes first. I personally will be changing a lot of passwords over the next couple of weeks.

Barnatt considers the Heartbleed bug very powerful reminder of why users should implement multi-factor security on their accounts. “Google, for example, provide two-factor security by allowing users to link their mobile phone to their Google account. When this is implemented, to log on a user has to enter their username and password, and is then sent a code to their mobile phone that also needs to be entered. When a machine is used regularly, it can be flagged as a trusted device, meaning that access to an account depends on a username, a password and the use of the specific hardware device, so again providing two-factor security. The practical implication is that even if a username and password are stolen, the security of an account is not compromised. Anybody can implement this for free, and Heartbleed really ought to be a wake-up call to get far more people to implement this type of measure.”

Share Story: