To be secure, AWS users must mind their keys and cues


Credit: Thinkstock

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(s amzn) 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.

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. (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 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

Lock, encryption, privacy, NSANeedless to say, posting key credentials on a public site is a no-no, according to AWS best practices. This should be well known, but the scary thing is it happens quite a bit.

“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. (There’s more on that here.). 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: is backed by True Ventures, a venture capital firm that is an investor in the parent company of this blog, Giga Omni Media.


Tony W.

Yeah, but CloudCheckr has failed our internal IT Security Assessment process, and still uses static AWS Keys even though AWS no longer supports providers doing that. That’s not meeting anybody’s best practice security in any shape or form. We can’t trust any provider who has worse security than we do, or else it defeats the purpose.


Hi Tony –
I cannot comment on your ITSA, but I think you are mistaken in your understanding of the necessary permissioning, rotation, and limitations. If you are interested in clarifying the issue, please feel free to contact .


Thanks for a well written article. It all seems obvious in hindsight but it goes to show once again how important it is to take the time to a:) understand AWS and its buffet of goodies, b.) make sure you’re security is tight as hell. Sometimes it seems some startups are in such a hurry to get something out the door (so they can “iterate fast” and be “lean” and “agile” and all that good stuff) they they tend to overlook how important security is.

Michael Vasquez

Great insight Barb — this is a growing issue and is precisely why CloudCheckr automated best practices checks around IAM, infrastructure security settings, key and password policies. The push alerts enable users to avoid these pitfalls.

Sudhi Seshachala

Very good write up Barb. If you really want avoid security concerns, threats and vulnerabilities, one should avoid sharing the secure keys and passwords over social collaboration and communication platforms such as skype, google hangouts and public email system etc., apart from git repos and stackoverflow/quora.

Comments are closed.