A few weeks ago startup Code Spaces shut down after a distributed denial of service (DDOS) attack followed by attempted extortion followed by the attacker accessing the company’s Amazon Web Services’ EC2 control panel and deleting data when the company did not pay up. Bye bye Code Spaces.
It is a nightmare scenario no matter how you cut it, but similar incidents have cropped up — albeit not with such dramatic results. Security experts say typically in these other cases a user inadvertently posts his or her AWS account root key somewhere public — on Github or StackOverflow for example –and miscreants seize on that to spin up free (well, free to them anyway) computing resources. The goal here isn’t extortion or stealing data — it’s free IT IT.
Recently an unnamed company said someone was able to spin up tens of thousands of dollars worth of “rogue” AWS instances in faraway regions. AWS issued a credit for the amount even though this company (Company X for our purposes) found no sign of a breach or its credentials being posted.
Evident.io (see disclosure), which offers a SaaS security product for AWS, was called in to help Company X and it didn’t take too long to see what was wrong, said Evident.io Founder and CEO Tim Prendergast. While the company did not push its root key out, it did have “high double digits of security controls that were not properly implemented,” he said.
Three ways to avoid trouble
There are three broad areas of vulnerability for such companies, all of which must be factored in early in the set-up process.
First, there is the possible penetration that happens when a root key or IAM user key is exposed, as mentioned before.
Second, there is a lack of good password planning. Companies often do not set up password authentication at all or correctly. It’s important to enforce the use both of “strong passwords” and multi-factor authentication.
And third, many companies are lax in how they set up permissions or user roles. Many give all users full administrative access when there is no reason to do so. This is exactly analogous to the old days when too many Windows users had full admin rights. That opens up a huge front for potential bad guys who, if they get just one user’s password, get access to a whole smorgasbord of goodies.
“People get phished or someone gains access to email and a keylogger and can see them logging into accounts,” Prendergast said. If that phishing victim has admin rights, then well, yikes.
Read the best practices
“I have seen people’s AWS root keys on StackOverflow two times and when I alerted them, they had no idea,” said the CTO of another startup that is a heavy AWS user. In both cases, he added, Amazon credited the fraudulent charges back to the customer.
Asked for comment, an AWS spokeswoman said customers should not have an access key for their root account but use Identity Access Management (IAM) to create temporary security credentials for applications that interact with AWS resources. Then, of course, those IAM access keys must be managed carefully.
“Developers are responsible for following our guidance and utilizing those mechanisms. When we become aware of potentially exposed credentials, we proactively notify the affected customers and provide guidance on how to secure their access keys,” she added.
Here’s the thing. Many AWS accounts are small developer-centric shops. They do not have Chief Information Security Officers or often any security experts at all. That means developers are in charge of security and often aren’t focused on it. And, technically speaking, any security issues above the API level are the users’ — not Amazon’s — responsibility, Prendergast said.
It may take a few more catastrophes for these lessons to sink in, but hopefully not too many more.
Disclosure: Evident.io is backed by True Ventures, a venture capital firm that is an investor in the parent company of this blog, Giga Omni Media.
Related research and analysis from Gigaom Research:
Subscriber content. Sign up for a free trial.
