AWS Error Exposed GoDaddy Business Secrets (zdnet.com)

Internal information belonging to hosting provider GoDaddy has been exposed via an error in Amazon's AWS bucket configuration. According to cybersecurity firm UpGuard, a set of documents were left in an Amazon S3 bucket which was available to the public. ZDNet reports: The information involved in the security breach appeared to describe GoDaddy's architecture, as well as "high-level configuration information for tens of thousands of systems and pricing options for running those systems in Amazon AWS, including the discounts offered under different scenarios," according to UpGuard. Configuration files for hostnames, operating systems, workloads, AWS regions, memory, CPU specifications, and more were included in the exposed cache, which described at least 24,000 systems.

"Essentially, this data mapped a very large scale AWS cloud infrastructure deployment, with 41 different columns on individual systems, as well as summarized and modeled data on totals, averages, and other calculated fields," the cybersecurity firm said. The open bucket, called "abbottgodaddy," also included what the company believes to be business information relating to GoDaddy and Amazon AWS' relationship, including rate negotiations. This information should have been kept confidential. The open bucket, called "abbottgodaddy," also included what the company believes to be business information relating to GoDaddy and Amazon AWS' relationship, including rate negotiations. This information should have been kept confidential.

Comments

Derptastic

[Aighearach]

Don't name your instances after your company. Select a neutral naming policy, and follow it.

It is bad enough when business data gets leaked, but why put a big flag on anything accidentally visible to let people know that they should snoop into it because they're not supposed to see it?

Re:Derptastic

[Anonymous Coward]

AWS S3 bucket names are shared globally. I don't mean globally within your account. I mean globally globally. If you name an S3 bucket "GoDaddy" then nobody else in the world can name an S3 bucket "GoDaddy". It's a rather strange quirk of the AWS systems that often leads to people naming their buckets with their company name because the likelihood of name collision is much lower that way.

Confused

[QuadEddie]

I'm confused should this information should have been kept confidential? I wish the summary would clarify that

Re:AWS error???

[nadass]

It's unambiguously an error in the AWS bucket configuration. The title doesn't state responsibility but the first line in the brief description does.

Re:User error, not AWS error

[StormReaver]

This was user error, not a systems error. An AWS employee fucked up.

I disagree. The "storing your data on someone else's servers" craze makes configuration so hard that not even the vendor can get it right.

Re:AWS error???

[Old Tom Bombadil]

The article states that an AWS employee created the bucket and did not follow best practices. That's part of the problem with AWS, they apply the "professional" tag to new hires who sometimes only have 2-3 months experience with the company.

Both, and AWS is the user

[raymorris]

We have two major errors here, or three, all by AWS and their employees.

An AWS employee created this bucket with it set to be accessible by everyone in the world.

Why did the set it to be accessible to anyone and everyone? They didn't set it, that's the DEFAULT on AWS. AWS says Security Groups is their implementation of a firewall. Just about the only firewall that defaults to wide open, no security at all.

Amazon's sales process apparently involves employees manually clicking on the generic UI to create resources for each customer, rather than having a Cloud Formation or other script for "create customer file".

There are many failures here. The failure of the AWS employee to override the really stupid defaults is, to me, the least significant. Had he never been hired, other employees would be frequently creating buckets with the default, and stupidly insecure, settings. Had the default been to be secure, and let the let customer select places it SHOULD be accessible from, this wouldn't have happened and it wouldn't be a common occurrence.

I've spent 20 years full time IT security. I'm very much security aware. I've forgotten to change the incredibly stupid AWS defaults, thereby leaving a security problem.

Re:Both, and AWS is the user

[Anonymous Coward]

You are not correct on the defaults. S3 buckets default to no access to anyone outside your account, and in fact usually throw up "WARNING: This bucket is public" if you change it. Security groups are not used on S3 buckets, but they default to no access as well (except I think port 22, which is how you access your EC2 instances, but anyone with half a brain will configure their own security groups for VPCs where machines should be deployed), but would not have mattered in this case because security groups are not used for S3.

Re:Both, and AWS is the user

[Lord Ender]

Nothing in your post is true. The default bucket policy is private and the default security group allows no public access.