Members of the Amazon Cloud community can build Amazon Machine Images (AMIs) from their own virtual servers and share them to save fellow developers time. But recently, the Center for Advanced Security Research Darmstadt (CASED) discovered that many community members are sharing more than they bargained for.
Like generous souls giving their old jacket to a shivering passerby – only to find that they left their driver’s license, passport, and credit cards in the pocket – these members published their AMIs without removing sensitive data such as SSH keys and the private keys associated with digital certificates.
Imagine that your company’s keys have just floated out into the ether. What consequences can you expect?
Handing Out the Keys to the Kingdom
An unauthorized person with your servers’ private keys can launch some frightening attacks:
Impersonation: A private key can “sign” data, and clients trust that data signed by your server’s private key originated from your server. But, if an unauthorized person has the private key, they’re placing their trust in a chimera.
The unauthorized user can now pose as the key’s legitimate owner to devastating consequence. For example, many of the insecure AMIs included companies’ Elastic Compute Cloud (EC2) or Simple Storage Service (S3) private keys, which Amazon uses to match virtual infrastructure utilization with company accounts. Just like someone with your credit card number, someone with your EC2 or S3 private key can rack up thousands of dollars of charges a day.
If the compromised key is associated with a login service or email server, hackers can launch the most convincing phishing attack ever against your users. Or your company might take on a new persona as the source of the latest spam campaign.
You can imagine more risks – and, if you can’t, hackers certainly can.
Data hijacking: Whenever a server uses SSL to transmit and receive sensitive data, it’s using a private key. The private key decrypts every shared key generated by clients to encrypt secure sessions. With access to the private key, hackers can decrypt those keys as well, unlocking all data transmitted and sent by the server at their leisure. All trust in the data’s security evaporates, and – considering that you’ve just blithely handed that key to anyone in the Amazon cloud – you’re probably starting to sweat.
If the compromised server key belongs to a server involved in credit card transactions, you’ve lost your PCI DSS compliance – and perhaps incurred some heavy fines. If the private key belongs to a server that receives protected consumer information, then you can scratch GBLA compliance off your list of achievements. You get the idea.
Server administrators commonly log into virtual machines with SSH, so it’s no surprise that the virtual machines from which AMIs were created stored SSH keys. Developers certainly should have removed the keys before publishing the AMIs but, according to CASED, fully one-third did not.
When you hand out your SSH key, a hacker can pose as your server, launching phishing attacks. Worse, if the SSH key provides root access, as many do, hackers can log directly into your server and take control.
Taking Back Control of Your Keys
How do you keep this scenario from hardening into a chilling reality?
Amazon provided guidelines that, had developers followed them, would have helped – clearly many ignored the guidelines. Now you know to pay attention. But consider this: Did developers really need Amazon’s warning? Shouldn’t their own common sense have triggered the flashing red lights and warning sirens?
Perhaps. But, familiar as I am with the state of enterprise key and certificate management, I’m not surprised that it didn’t.
Enterprises have deployed thousands and ten thousands of digital certificates and SSH keys. The keys are deployed on various platforms in various business silos; they’re obtained from multiple vendors and certification authorities (CA). Without any management tools, administrators have become used to ignoring them. In fact, server administrators often don’t even realize that a private key installs with the server’s digital certificate and that this key must be protected, which explains why the administrators so blithely left them in the AMIs.
The current state of knowledge about certificates and keys and the sorry state of current practices inside organizations is de facto training for the current generation. The question remains: Will the security industry work to close the gap in education and best-practice approaches to access controls for private keys? Or will this continue to be an overlooked issue until it is too late and a company becomes the victim of a highly publicized breach?
But as the insecure AMIs make clear, continuing to ignore the problem is like leaving your credit card in a Xerox machine. Enterprises must track these vital assets so that administrators understand where they are and can properly manage and secure them from the next big threat. If manual management isn’t doing the job, enterprises need an automated tool.
An automated solution could also help the unfortunate companies that already handed out their keys in AMIs. These companies need a disaster recovery plan. Every platform, application or service that uses a compromised key requires a new key/digital certificate. With more than 20 manual steps required to update a certificate, these companies are looking at extensive – and costly – downtime.
Jeff Hudson is the chief executive officer of Venafi. A key executive in four successful, high-technology start-ups that have gone public, Hudson brings over 25 years of experience in information technology and security management. Hudson has spent a significant portion of his career developing and delivering leading-edge technology solutions for financial services and other Global 2000 companies.
Prior to joining Venafi, Hudson was the CEO of Vhayu Technologies Corp. Before joining Vhayu, Hudson held numerous executive leadership posts, including CEO and co-founder of MS2, senior VP of corporate development at Informix Software, CEO of Visioneer, and numerous senior executive posts at NetFRAME Systems and WYSE Technology. He started his career with IBM.
Hudson holds a BA in communications from the University of California at Davis.