The recently announced vulnerability in OpenSSL, known as “Heartbleed,” is a serious flaw that not only affects the majority of web servers in the world, but also touches countless other applications that use the affected software. Because Heartbleed gives an attacker direct access to memory stored on the web server, it is possible that certificates, keys, passwords, financial information, personal consumer information and other sensitive data have been exploited.
TLS is a widely used encryption protocol that is commonly utilized by webservers to protect sensitive information while in transit. Because Heartbleed allows an attacker to gain direct access to system memory – and because the logs would show nothing out of the ordinary – all of the data on the server may be compromised, making it difficult to know if an exploit has occurred in the first place. Because this vulnerability has been in existence for two years, organizations should assume that any system running vulnerable OpenSSL software might have been compromised.
Heartbleed does not impact the safety of the Secure Shell protocol itself. However, web servers and other hosts typically run both OpenSSL and Secure Shell. This means that if an attacker is able to gain access to the system’s memory, the vulnerability may also expose Secure Shell authentication credentials that can be then used for accessing the servers through encrypted terminal and file transfers connections.
As the affected web servers and other TLS applications may share the same credentials with Secure Shell, it should be assumed that all Secure Shell authentication credentials stored on the affected host might have been compromised.
Customers are advised to patch any server where the vulnerable OpenSSL software is installed.
Due to the pervasive nature of the Heartbleed vulnerability, the length of time the flaw has been in place and the broad access that an attacker could potentially obtain, it is critical that organizations change all Secure Shell keys used to establish trust relationship with affected systems immediately after the Heartbleed patch has been installed, and should be part of the organization’s standard remediation procedure.
Once affected systems have been patched, organizations should immediately rotate any Secure Shell keys and change Secure Shell passwords stored on those systems. Potentially affected systems with stored Secure Shell user keys (either public or private) should have those credentials rotated (i.e., replaced) with new keys.
Any delay in rotating Secure Shell authentication credentials could enable an attacker to yet again access the system or utilize Secure Shell authentication credentials to compromise other network systems and applications.
Heartbleed may have allowed attackers to create back doors into critical systems. It is critical that organizations monitor their environments for any anomalous activity.
The impact of Heartbleed is breathtaking in its scope. Organizations are still scrambling to assess the fallout, reassure their customers and roll out remediation projects as soon as possible. Instances like Heartbleed underscore the need to centralize and control management of encryption keys – including regular rotation, removal and renewal – to reduce the chance of old or lost keys being stolen in an attack. While these best practices are aimed at reducing the risk of fallout from Heartbleed, they represent the first step towards a holistic security posture that makes Secure Shell key management a top priority.