2nd July 2014
This is a guest post for the Computer Weekly Developer Network by Luke Potter, operations manager at SureCloud — a cloud application service provider focusing on governance, risk and compliance process automation.
Closer analysis of the circumstances that led to the recent media furore surrounding the ‘Heartbleed’ bug shows the IT industry needs to quickly learn some important lessons if it is to avoid a similar own goal ever happening again.
The reasons why a two-year old bug managed to stay undetected for so long says much about the way the open source community works and the culpability of some organisations who were happy to take freely available open source software and put it at the heart of their mission-critical applications without contributing to the OpenSSL project.
However, the bug caused far greater panic than was necessary. People’s website credentials, bank account details, digital ‘life’ hadn’t necessarily been compromised and they probably never will be. The risk was that they ‘may’ have been but there was no way of knowing for certain.
The Heartbleed vulnerability was a bug within an OpenSSL extension called Heartbeat. The bug was introduced accidentally over three years ago on December 31, 2011 by a developer working voluntarily on the OpenSSL project. It only came to light recently when a security researcher from Google’s security team [Neel Mehta] identified the bug and reported it to OpenSSL on April 1, 2014. The cause of the bug was a combination of poor code control and limited funding for the security testing and code-review of a free product that is used by major institutions worldwide. It caught most IT teams and vendors off guard. Some quickly responded by patching their vulnerable systems, but recent statistics show there are still over 300,000 vulnerable servers worldwide that are yet to be patched (not including any internal systems!). After patching the bug, many organisations started revoking/re-issuing SSL certificates and advising users to change their passwords which in turn sparked widespread panic.
To prevent something like this happening again, companies should take stock and review their strategy for using similar software.
More time and money needs to be spent on projects such as OpenSSL where talented developers are often spending their personal time, without pay, providing and improving software and applications that benefit the masses. There are a lot of security researchers out there who are skilled at finding and fixing vulnerabilities. But an industry that is so reliant on this software should not expect this important work to be undertaken without contributing financially to this project.
A positive outcome following the Heartbleed incident has been the creation of the Core Infrastructure Initiative (CII). Set up by the Linux Foundation, the CII’s mission is to commit funds provided by the world of big business to open source projects that lie at the heart of core computing functions. The aim is to help the developer community become more security aware and hence reduce the chances of bugs being introduced in the first place.
The level of risk to which Internet users were exposed with Heartbleed was in fact quite insignificant.
Yet for anyone unlucky enough to be affected the consequences were serious. One of the major issues with this particular vulnerability was that the ‘detection’ of an attack (or previous attack) was actually very difficult.
Exploitation of the vulnerability allows an attacker to read a small amount of memory. This memory space could potentially contain sensitive information such as a server’s SSL certificate private key and/or user’s credentials. This is why, as part of their response, many companies placed the emphasis onto their users/customers by advising them to change their passwords.
Over and above this, it’s considered best practice to ensure that each site you use has a unique password (preferably with a random mix of alpha-numeric and non-standard characters). To take this a step further, consider using a unique email address/username for each and every site.
Perhaps the most important lesson for organisations to learn from Heartbleed is not to wait for the next high profile industry emergency before kicking into action. We will without doubt see many more similar ‘high profile’ vulnerabilities. It takes the occasional critical bug to shake things up and help the industry appreciate where there is room for improvement.