infoTECH Feature

November 05, 2014

The Lessons of Heartbleed and Shellshock

By TMCnet Special Guest
Jonathan Lewis, Director of Product Marketing, SSH Communications Security

By now, the Heartbleed vulnerability is old news. We heard about it last April along with how to fix the problem. So why should we still talk about it? Didn’t everyone fix the problem and move on? If only it were that simple. Now that Shellshock – a similar but possibly more insidious vulnerability – has been identified, the industry must revisit the past to learn critical lessons on how to go forward.

Heartbleed is dangerous because any malicious actor can exploit it to retrieve the contents of memory from vulnerable servers – without being detected. As a result, any private credentials that may have resided in memory at the time of attack can no longer be considered private. This reality led many enterprises and public-facing Web services to recommend to their users that they change their passwords.

Exploiting Transitive Trust

However, passwords were only the tip of the iceberg. Other forms of credentials, such as private Secure Shell keys, did not get much attention – but they should have.  One stolen Private Secure Shell key can be used by an attacker to gain login privileges to multiple servers. For example, a Web server might have a Secure Shell private key authorized to access a back-end database. The database server might have private keys authorizing access to back-up systems. A log management system running on the same server might have keys authorized on dozens of other servers.  This creates a cascading effect that can give the malicious actor access to assets across the data center environment.

Two graphics help drive home the point. The transitive trust graphic shows how a complex network of trust relationships can enable an attacker with just one stolen key to gain access across the server estate. 

The other graphic is a real-world picture of trust relationships inside a modest-sized data center of just a few hundred servers. There are over 8,000 trust relationships in the environment of about 550 servers.

Heartbleed Lessons for Shellshock

So, how do transitive trust and the dense network of trust relationships inside data centers help us understand how to deal with Shellshock? Let’s look back at what we learned from Heartbleed: while patching the vulnerability prevents future losses of data due to Heartbleed, it does nothing to recover from data loss the organization may have already experienced. Security teams therefore must evaluate what might have been taken and what that information could be used for. In the case of stolen Secure Shell private keys, the potential for enterprise-wide compromise is real and significant.

Another lesson learned from dealing with Heartbleed is that if an organization uses Secure Shell keys in its network environment, as do roughly 80 percent of enterprises, it might not be so easy to replace potentially compromised keys with new ones. Assuming the IT department knows where all its keys are and what they are used for—and frankly, most don’t—the simple mechanics of manually changing out key pairs are daunting. It takes about 20 minutes to change a single key pair (the process: remove the public key, generate a new private/public key pair, install the keys in the proper locations, test to make sure everything works and document the change). A typical 1,000-server environment will have about 15,000 Secure Shell key-based trust relationships. At 20 minutes per key pair, we are looking 2.4 years of work. If the goal is to get it done in one month, the IT team will need to allocate 29 people to the task.  

Finally, remember that doing whatever work is necessary to return an environment to a pristine state does not protect the organization from another compromise. What will the organization do when the next vulnerability, like Shellshock, rears its ugly head? Go through the costly, time-consuming process of manually replacing keys, or hunker down with possibly-compromised credentials and hope for the best?

Shellshock enables an attacker to take control of the target system. The attacker is able to not only steal private keys, but also to create new key-based authorizations to use as back doors to access the environment even if the original stolen keys are disabled. Heartbleed and Shellshock teach the same lesson: Even after the IT team fixes the vulnerability, the environment is potentially compromised. The work is not yet done.

 

Looking Ahead

So, what can the organization do next? The dangers of doing nothing, or only securing the environment halfway, are evident. Heartbleed was a wakeup call to maintain a state of preparedness. Compromises will keep occuring, as Shellshock demonstrated in just a few short months after Heartbleed. The ability to recover from the potential compromise of credentials is an essential element of preparedness. This includes the ability to recover from the compromise of Secure Shell keys and put continuous monitoring in place to ensure no keys are secretly added. The main takeaway is to put processes and procedures in place to monitor and manage Secure Shell keys. This will better position organizations to deal with Shellshock and whatever new threats arise.

About the Author:Jonathan Lewis is director of product marketing for SSH Communications (News - Alert) Security, where he is responsible for communicating the value and importance of effective Secure Shell access governance. Jonathan has diverse experience in the network and security industry including technical and business management roles at companies ranging from start-ups to global enterprises.  His technology expertise includes VPN, Firewall, SSL, SSH and DDoS mitigation. Jonathan holds BS and MS degrees from McGill University and an MBA from Bentley College.




Edited by Maurice Nagle
FOLLOW US

Subscribe to InfoTECH Spotlight eNews

InfoTECH Spotlight eNews delivers the latest news impacting technology in the IT industry each week. Sign up to receive FREE breaking news today!
FREE eNewsletter

infoTECH Whitepapers