"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...
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.
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")?
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.
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.
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 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.
>"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...
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".
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.
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.
