AWS Error Exposed GoDaddy Business Secrets (zdnet.com) 85
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.
"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.
Derptastic (Score:4, Insightful)
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 (Score:1)
link to the data or it never happened.
Re: (Score:2)
You didn't fix anything, you comprehended the story but not any of the human comments.
The *user* is who chooses the naming. It is the *user* who is more likely to have their stuff under attack if they name it after the company. Then when the *user* makes any other error, the baddies get their data.
Obscurity isn't security, and yet it is still an important part of operational security practices including belt and suspenders.
Re: (Score:2, Interesting)
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.
Re: (Score:2)
The possibility of name collision is clearly and obviously still much higher than using a random string, and maintaining your semantic metadata privately. Don't share your metadata frivolously!
What secrets ? (Score:2)
Nekkid pictures of Danica Patrick ?
Re: (Score:2)
more like, nekkid pictures of Andrew Anglin.
Re: (Score:2)
Re: (Score:2)
Both, and AWS is the user (Score:3, Insightful)
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 reso
Re: (Score:2)
To add to the list of mistakes: where was the security audit script? It's a trivial thing that anyone who has ever made this mistake should already be doing. Just log every best practice not being followed, and fix the inevitable mistakes before you load customer data. You know Amazon must do that sort of thing to police internal teams - heck, why isn't it there in the AWS dashboard?
That's on my TODO list, and we're a small team (Score:2)
An audit script that runs as new resources are created, and the again periodically, is on my to-do list. We're a small team with hundreds of dollars per month of AWS spend. If we can do it, certainly AWS themselves can and should have such a script for internal use.
Re: (Score:2, Informative)
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
And they are about 100 years behind the times (law (Score:2)
Yes, under their Customer Responsibility Model, AWS says the customer is responsible carefully avoiding the dangers inherent in the design of their product. That was a common, and arguably legal, position to take until 1963.
Since 1963, you may have noticed that self-propelled lawnmowers have deadman switches that automatically shit off the mower and apply a brake if the operator let's go of the handle for a second. All openings are covered by a metal plate held closed with a powerful spring any time the att
Re: (Score:3)
Nothing in your post is true. The default bucket policy is private and the default security group allows no public access.
Re: (Score:2)
Then you haven't used AWS in a really long time, or you never set up a VPC when you did.
S3 bucket policies default to non-public. You have to either use an IAM role that allows access, or have a bucket policy attached that allows access; or you can check a box that is very much not default to make it a public bucket.
If you are using a VPC (which any organization should be) then resources created in the VPC default to having no security groups attached, which means there is no access to anything allowed at
Comment removed (Score:5, Funny)
Re: (Score:1)
Re: (Score:2)
Re: Confused (Score:1)
Whoosh whoosh.
Re: (Score:2, Funny)
Re: (Score:2)
I'm confused should this information should have been kept confidential? I wish the summary would clarify that
I'm confused should this information should have been kept confidential? I wish the summary would clarify that
"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,
This is the Problem with Cloud Services (Score:1)
It's too easy to have an epic security fail because it's too complicated, the peons configuring it don't know WTF they're doing and management doesn't care as long as it involves the words "cloud" and "savings".
Re: (Score:2)
Yeah, back in my day it was too easy to have an epic security fail because your own damn server was too complicated and the peons configuring it didn't know WTF they were doing. Now they have this cloud thing with point and click security...
Now get off my... err... I'm not that old actually. I don't have a lawn yet.
User error, not AWS error (Score:2)
I forgave the local semi techy tabloid type online newspaper getting this wrong when the news broke days ago, but this is Slashdot FFS. This was user error, not a systems error. An AWS employee fucked up.
Re: (Score:1)
"The bucket in question was created by an AWS salesperson to store prospective AWS pricing scenarios while working with a customer," an AWS spokesperson told ZDNet.
Somebody is not getting their performance bonus this quarter...
Re: (Score:3)
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: (Score:1)
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.
It's not difficult to make a default deny (i.e. Deny:*) bucket policy and then add in the allows. Hard but not impossible.
Re: (Score:2)
Our usage of the term seems to differ, then. To me, a systems error is a category separate from user error, even if the user error is made more likely by overly complicated design or implementation.
que? (Score:1)
recurring theme (Score:1)
how many times does a bucket need to be exposed before people get smart enough to. stop. fucking. using. them. for. important. data.
Hmmm....Seem like someone dropped the ball. (Score:1)
The editors should ensure that duplicate sentences are removed from the summary. The editors should ensure that duplicate sentences are removed from the summary. It seems like this could be automated. It seems like this could be automated. I don't know why I see articles about 10% to 20% of the time with duplicate sentences, or sometimes even whole paragraphs, in them. I don't know why I see articles about 10% to 20% of the time with duplicate sentences, or sometimes even whole paragraphs, in them. It's kin
Re: (Score:1)
There's a joke I recall that has something to do with a woman and a man commenting on the size of the woman's, well, you know, and her asking why he said it twice, and him saying, "I didn't. I didn't". Something to do with acoustics of large spaces or something like that. These repetitions always remind me of that joke.
Re: (Score:1)
I'm pretty certain the original joke was from this guy: https://en.wikipedia.org/wiki/... [wikipedia.org]
How is this an AWS error? (Score:2)
Re: (Score:2)
If it were a Mercedes salesperson leaving it unlocked in the airport, they would call it a Mercedes issue.
Also, if Mercedes had a keyfob that would tend to unlock in the pocket, people would be questioning some human factors situations with that keyfob, even though that keyfob is working fine and would be secure if 'used properly'.
The challenge with cloud hosting is that humans suck at securing things, and in the cloud instance context they tend to make the same mistakes they make on private networks except
Misleading Title (Score:2)
The title suggests Amazon screwed up, when it was GoDaddy that screwed up their usage of Amazon's services. Kinda shady. The title.
Why not to go to the cloud (Score:2)
This is a perfect example why companies refuse to outsource their Exchange servers, SharePoint boxen, as well as file storage services to the cloud. HR won't let them for reasons such as this.
For those arguing it is GODADDYS FAULT not Amazon they miss the point. It was perfectly secure and fine the way it was. Some bean counter who is not trained in risk management urged to fire their IT workers and outsource this function to the cloud to save money.
They got what they paid for.
Retracted (Score:2)
"Although the potential threats to exploit this kind of data require intentional malicious actors, the exposure of that data through misconfigured storage does not," UpGuard said. "From operations as large as GoDaddy and Amazon, to small and medium organizations, anyone who uses cloud technology is subject to the risk of unintentional exposure, if the operational awareness and processes aren't there to catch and fix misconfigurations when they occur."