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.
"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.
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?
about-to-get-fired
Nekkid pictures of Danica Patrick ?
errr....umm...*whooosh* *whoosh* Is this thing on ?
This is not an AWS error, this is a fucking-idiot-who-should-be-fired error. Get your fucking facts straight, BeauHD.
I'm confused should this information should have been kept confidential? I wish the summary would clarify that
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".
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.
que?
Bucket to the world
how many times does a bucket need to be exposed before people get smart enough to. stop. fucking. using. them. for. important. data.
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 kind of annoying. It's kind of annoying.
GoDaddy... isn't that who bought HostEurope in 2016? HostEurope, whose subsidiary DomainFactory was "hacked" two months ago? And by "hacked" I mean someone found their customer database completely unprotected on the internet? Who knew they were such a great cultural fit.
That's not an AWS error, that's a GoDaddy error. Some idiot didn't know how to use S3.
Calling this an AWS error is like calling leaving an unlocked S series in an airport parking lot a "Mercedes Benz" error. This is an error that GoDaddy, who is typically poor when it comes to security knowledge, made in their implementation. They used S3 without applying proper policies around it, all of which are more than sufficiently documented.
This information should have been kept confidential.
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.
...they kill elephants, don't they?
Vword: grieves
One would hope all the bloopers and deleted scenes from the original godaddy commercials were included. nothing like a flash back to SNL's sweaty balls slapstick... now that would definitely be worth the look at the treasure trove..
More than confidential, but should have been locked in a managers desk somewhere. Not put on a network waiting for this to happen.
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.
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 attachment isn't attached. In general, products have every reasonable safeguard in place in order to eliminate any foreseeable danger. That's because companies are legally required to put safeguards in place to guard against dangers whenever it's reasonably possible. "It's the customer's responsibility to avoid the clear dangers we designed into our product" hasn't been a legitimate or legal stance since at least 1963.
The title suggests Amazon screwed up, when it was GoDaddy that screwed up their usage of Amazon's services. Kinda shady. The title.
Fucking clickbait bullshit!
After so many leaks like this, it just seems that it's too easy to misconfigure S3 buckets. Surely AWS can improve this somehow.
According to article an AWS Sales person created the S3 bucket without following best practices. - now it makes perfect sense. Although unnacceptable.
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.
http://saveie6.com/
"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."
Update 00.52 BST: AWS statement:
"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. "No GoDaddy customer information was in the bucket that was exposed. While Amazon S3 is secure by default and bucket access is locked down to just the account owner and root administrator under default configurations, the salesperson did not follow AWS best practices with this particular bucket."
AWS says that no GoDaddy information was involved in the breach. GoDaddy says that the exposed documents were speculative models and were not related to current activities between the hosting provider and Amazon.
"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."
Nice red herring
Facts. Who needs them?
This was NOT an "AWS error and this was NOT a "security breach". This was a clueless user being clueless, again.
A middle manager puts important corporate documents on the roof of her car while opening the door during her morning rush to work. As so often happens, she forgets the documents on the roof and then drives onto the highway. Many people try to signal that there is something on her roof but, she doesn't realize that they are trying to inform her of the rooftop papers and not simply flipping her off for driving while applying makeup and texting all at once. The stack ultimately blows off and comes to rest on the side of the road for a day or two before someone stumbles upon them and discovers the trade secrets within.
Is this a Xerox/paper/car error? Is this a security breach? Does this reflect on any of these companies or the middle manager's company? NO. It is a simple everyday mistake made by the end user, the middle manager distracted in her morning rush.
The above scenario is analogous to what has happened here to GoDaddy. A stupid user left documents in a public place and someone stumbled onto them.
The article's horseshit hyperbole is typical of today's Twitter journalism, where "news" and sources are Twitter based and accuracy and fact checking is for old people that need to FOAD. It's pure fucking garbage that paints a picture that is completely without basis in reality. It is the very essence of "fake news"
I am again disappointed by Slashdot's ever lowering standards for regurgitating this horseshit.As for the ZDNet editor that published the story, they should literally be flogged.
"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."
Well that is a learning moment for me. I never knew my lawnmower was supposed to shit itself if I let go of the handle. :)
Is that why cars automatically pull over and don't crash if the driver is drunk or falls asleep? Except for all of them, but at least the auto maker is at fault in those instances, right? Right?
Oh wait, none of that is true.
Regular people don't (directly) use Amazon AWS or S3. You may as well say NIX is insecure because idiots run
chmod -r 777 /
To get stuff to work and then think they are done.