AWS error exposed GoDaddy business secrets | Hacker News Reader

AWS error exposed GoDaddy business secrets

zdnet.com

77 pointssahin-boydas35 comments

  "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 Engadget.

It's bad when even AWS employees misconfigure security on buckets...

I guess it's really bad when sales has to store sales material in self-configured buckets. That feels like about three layers too low.

   That feels like about three layers too low.

Pretty much my entire feeling on AWS's UX every time I want to do something simple

Seriously. You'd think they'd have an internal Web DAM on top of S3 and productize it.

If you put a demo system set up by a sales rep into production without even checking the settings this is what you get.

Can the link be changed to https://www.upguard.com/breaches/public-domain-how-configura...? The original link is essentially blogspam.

10-15 years ago, if you asked me what would get your SAAS shop owned up, I'd have said an overlooked SQL injection vulnerability.

5-10 years ago, I'd have said credential stuffing in your accidentally-exposed admin app.

Today, without question: it's AWS misconfiguration or credential leaking.

If the admin app were not exposed, wouldn’t credential stuffing work just as well on the VPN interface?

No, because the people whose credentials tend to get stuffed in these examples tend not to be the people who use the VPN. Like, it happens, but "tier 2 support" is the victim I'm usually thinking about here.

it's AWS misconfiguration or credential leaking.

By AWS themselves? Does that actually happen a lot?

No, by AWS users. There are safe ways to configure AWS and there are very unsafe ways, and the very unsafe ways are easy, well-documented, and on the UX "happy path".

Oh ok, I was about to start freaking out. This just looks like AWS salesperson had some doc in a world readable bucket - sort of like if a building contractor forgot the proposed plans for a superhero HQ in a public dropbox folder. The AWSery seems almost incidental.

We hear about these mis-configurations leading to publicly-viewable things that shouldn't be publicly viewable all the time. This makes me wonder what is the default security setting? It seems like -- and this is from the outside looking in, I have little experience with AWS -- whatever the default is, it's not nearly strict enough. Shouldn't the default config be pretty restrictive for security's sake? Or is this a case of trying to dumb it down in the name of "usability" or "streamlining the UI" or some other marketing fluff crap (aka "for people who don't/won't/can't RTFM")?

I just checked, and the default for creating a new S3 bucket through the console is not public readable. However, getting the right permissions in place for real-world work is not trivial if you haven't put some time in the docs so I suspect people end up shoving wild cards and the like in their access policies.

The default is private to the owning AWS account. You’re meant to generate short-term tokens in your backend code to authorize specific requests, embedding them in the URLs you pass to others. People who are abusing S3 as a substitute for Dropbox or Google Drive (or using it from any context other than custom server-side software) won’t do that, so they set resources as public to make things work.

"After all, without trade secrets and IP, a business has nothing to stand out from the crowd."

I'm not sure if that's meant to be sarcastic or serious.

I thought that was a bizarre statement too. There are plenty of businesses that are successful without unique IP. GoDaddy is probably one of the best examples of that -- it's web hosting and domains, it's mostly a commodity at this point. Domain registration is absolutely a commodity.

I also question how bad it really would have been if the entirety of the information was leaked to the public. This is more embarrassing for AWS than GoDaddy.

Yeah, this is a rare case where the company can actually 100% blame the vendor. It's usually a case of a company not properly following the vendor's documentation or otherwise misconfiguring something.

The article is a bit sensationalist from the title through to most of the "what ifs" and speculations in the body.

Hidden right at the end Godaddy even downplays the sensitivity of the information that was available.

Sounds like a serious Freudian slip that reveals their true character. Like when in the wake of a horrifying scandal the head says that their goal is to restore the trust of the public instead of doing something about the root problem. Or a bad parent's reaction to hearing that their teenaged son was in a high speed crash while borrowing his car was 'is the car okay'? In this case he admits that he has absolutely nothing special or even good to stand out.

I'm pretty sure the author is serious here and that they honestly don't know other ways to stand out.

>"After all, without trade secrets and IP, a business has nothing to stand out from the crowd."

Except that GoDaddy has a massive, massive brand with millions invested in marketing over years of business. Its success is hardly down to trade secrets or juicy AWS discounts...

Title should read "AWS bucket configuration error by Amazon employee...".

Title makes it seem like AWS system flaw, it's not.

AWS, as a system, allowed this. AWS, its employees, made such a mistake. Pretending processes somehow don't involve people blindsides us to obvious problems in real implementations.

Possible lessons: Why is it so easy/tempting/overlookable to misconfigure a bucket that an AWS employee could do it? What lessons can we learn from, for instance, Google Apps, where you don't usually misconfigure your file share? Upguard's conclusions are what you should be taking away, not "AWS buckets are fine from a tech standpoint".

Defaults for AWS are not public. The UI recommends against turning it on.

Sales people turn on Public so clients can see it w/o logging into some system.

IMO an employee intentionally set a bucket with critical data to public.

My original point that the title was misleading stands.

The Internet as a system allowed this deliberately public configuration, so the Internet is at fault.

The World Wide Web as a system allowed this deliberately public configuration, so the web is at fault.

AWS S3 as a system allowed this deliberately public configuration. So AWS S3 is at fault.

None of those seem quite right.

To me, seems more like AWS S3 isn’t designed for the higher level use case of sending a “shared secret” folder link by email to a collaborator, combined with a drinking the kool-aid tic where all employees try solving all use cases with the in-house hammer at hand.

At the same time, I think AWS has made a mistake — putting a Web Console on top of an API driven infrastructure, and investing so much recently in trying to make the web UI more “usable”.

AWS is not your father’s webmin VPS, but by now the console is so friendly, today’s sales guy can be forgiven for thinking S3 config and Dropbox config are the same thing.

Looks like a case for FTP. Does AWS provides FTP hosting? I think not.

_human_ error exposed GoDaddy business secrets. AWS did exactly what it was told to do.

Except an AWS employee configured it, granted that employee was human, but was a member of the blamed organization.

Is there a public link to the disclosed details of the information?

Dupe: https://news.ycombinator.com/item?id=17741281

This post has more points. Additionally the other post has no comments.

Something's been done. LoL. I saw that and am aware. Yeah.

Since the comment you're responding to is the oldest one, it would seem this thread had no comments yet either.

Without attempting to make a joke, wouldn't a better place to store a doc like this be and of the following: Google Docs, O365, Dropbox, Box.com, Zoho, or basically ANY syste designed for file sharing with specific external customers? AWS isn't really meant to function on it's own as a file sharing service, though there are services that could have been made on AWS for this purpose.

Reply on news.ycombinator.com