Slashdot Mirror


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.

85 comments

  1. Derptastic by Aighearach · · Score: 3, 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?

    1. Re: Derptastic by Anonymous Coward · · Score: 0

      AWS *user* Error Exposed GoDaddy Business Secrets

      -FTFY

    2. Re: Derptastic by Anonymous Coward · · Score: 0

      Clearly nothing to do with EC2 instance naming. This was an s3 bucket that had some pricing/config data in it.

    3. Re: Derptastic by mSparks43 · · Score: 1

      link to the data or it never happened.

    4. Re:Derptastic by Anonymous Coward · · Score: 0

      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?

      It's a setup, or a trap. Odds are good that some dipshit LEAs are behind it.

    5. Re:Derptastic by Anonymous Coward · · 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.

    6. Re:Derptastic by Aighearach · · Score: 1

      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!

    7. Re: Derptastic by Aighearach · · Score: 1

      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.

  2. abbottgodaddy by Anonymous Coward · · Score: 0

    about-to-get-fired

  3. What secrets ? by Archfeld · · Score: 1

    Nekkid pictures of Danica Patrick ?

    --
    errr....umm...*whooosh* *whoosh* Is this thing on ?
    1. Re:What secrets ? by Tsolias · · Score: 1

      more like, nekkid pictures of Andrew Anglin.

    2. Re: What secrets ? by Anonymous Coward · · Score: 0

      Genetically speaking, they are both 99.9+% identically sexy.

  4. AWS error??? by Anonymous Coward · · Score: 0

    This is not an AWS error, this is a fucking-idiot-who-should-be-fired error. Get your fucking facts straight, BeauHD.

    1. Re:AWS error??? by nadass · · Score: 2

      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.

    2. Re:AWS error??? by Old+Tom+Bombadil · · Score: 2

      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.

      --
      "Tom Bombadil is a merry fellow! Bright Blue his jacket is, and his boots are yellow!" -Tom Bombadil
    3. Re:AWS error??? by Anonymous Coward · · Score: 0

      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.

      "Professional" only means he makes his living doing that job. It does not mean he is very good at it, and certainly don't imply long experience.

    4. Re:AWS error??? by Anonymous Coward · · Score: 0

      And why hadn't GoDaddy run any of the many tools available to inspect the various resources in your AWS account and create reports of S3 buckets with public access enabled, etc? Why didn't they have someone looking at what the "AWS Professional" was doing when he was doing it to make sure that it made sense, and wasn't a bonehead mistake? Isn't that what they would do with literally any other contractor or service provider if they cared at all about information security?

    5. Re:AWS error??? by Anonymous Coward · · Score: 0

      Being a professional does not make you professional.

  5. Confused by QuadEddie · · Score: 5, Funny

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

    1. Re:Confused by nadass · · Score: 1

      Generally speaking, infrastructure configurations and vendor-negotiated pricing arrangements are relatively confidential for the entity (GoDaddy) and they are traditionally classified as "trade secrets" (especially in the eyes of lawyers and employment/vendor contracts). The vendor/team/person who setup "abbottgodaddy" is liable for any damages directly attributable to this snafu; the direct damages would be changes in pricing strategy and infrastructure migration costs -- for a company like GoDaddy (with over 24K systems) that'll be a lotta budget spent to resolve, and the vendor would go broke (I hope they have good liability insurance).

    2. Re:Confused by giggleloop · · Score: 1, Funny

      Yeah. They really need to be clear that 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. Sloppy reporting not to include that info.

    3. Re:Confused by deviated_prevert · · Score: 1

      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, 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 redundancy could have made the situation more clear IMO, BeauHD didn't proof read the original post. I did and it made me somewhat dizzy it was deja vu all over again.
      • The redundancy could have made the situation more clear IMO, BeauHD didn't proof read the original post. I did and it made me somewhat dizzy it was deja vu all over again.
      --
      This message was not sent from an iPhone because Peter Sellers really was a deviated prevert without a dime for the call
    4. Re:Confused by jargonburn · · Score: 1

      Whoosh? ;-)

    5. Re:Confused by Anonymous Coward · · Score: 0

      Autism strikes again!

    6. Re: Confused by bestweasel · · Score: 1

      Whoosh whoosh.

  6. This is the Problem with Cloud Services by Anonymous Coward · · 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".

    1. Re:This is the Problem with Cloud Services by iTrawl · · Score: 1

      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.

      --
      "Everybody's naked underneath" -- The Doctor
  7. User error, not AWS error by Mascot · · Score: 1

    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.

    1. Re:User error, not AWS error by nadass · · Score: 1
      Hmm, from the article:

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

    2. Re:User error, not AWS error by StormReaver · · Score: 2

      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.

    3. Re:User error, not AWS error by Old+Tom+Bombadil · · 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.

      --
      "Tom Bombadil is a merry fellow! Bright Blue his jacket is, and his boots are yellow!" -Tom Bombadil
    4. Re:User error, not AWS error by Anonymous Coward · · Score: 0

      And gets an extra corporate sponsored lesson on using doors. Knobs, locks and keys included.

    5. Re:User error, not AWS error by Mascot · · Score: 1

      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.

    6. Re:User error, not AWS error by Anonymous Coward · · Score: 0

      An explicit Deny in any AWS access policy overrides any Allow, so you can't do it this way. You can allow access to a list of one or more AWS accounts, so it's not all-or-nothing.

  8. que? by MJhasHIV · · Score: 1

    que?

    1. Re:que? by Anonymous Coward · · Score: 0

      que?

      You misspelled "queue"

  9. S3 is the Twitter of File Systems by Anonymous Coward · · Score: 0

    Bucket to the world

  10. recurring theme by Anonymous Coward · · 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.

    1. Re: recurring theme by Anonymous Coward · · Score: 0

      Why? Where would you put data to facilitate two separate corporate entities exchanging data where itâ(TM)s safe, even if simple security is not followed properly?

    2. Re: recurring theme by Anonymous Coward · · Score: 0

      how about not putting the data on a cloud. fucking duh. christ.

    3. Re: recurring theme by Anonymous Coward · · Score: 0

      In a folder. Don't use buckets, use folders. Buckets are for slop.

    4. Re: recurring theme by Anonymous Coward · · Score: 0

      Why? Where would you put data to facilitate two separate corporate entities exchanging data where itâ(TM)s safe, even if simple security is not followed properly?

      How about an SCP server, which encrypts traffic by default, and REQUIRES A FUCKING PASSWORD?!?!
      I mean, I know they're pretty obscure, but I'm sure Amazon has someone, somewhere, who has the skills to set up such a beast......

    5. Re: recurring theme by Anonymous Coward · · Score: 0

      SCP and passwords are fail. You should have them both push/pull from a third party repo. Hell, you can use git to check it in and out.

  11. Hmmm....Seem like someone dropped the ball. by gerald.edward.butler · · 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 kind of annoying. It's kind of annoying.

    1. Re: Hmmm....Seem like someone dropped the ball. by Anonymous Coward · · Score: 0

      I'm still unclear whether the information should have been kept confidential. I'm still unclear whether the information should have been kept confidential.

    2. Re: Hmmm....Seem like someone dropped the ball. by gerald.edward.butler · · 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.

    3. Re: Hmmm....Seem like someone dropped the ball. by Anonymous Coward · · Score: 0

      See also: Predator, 1987

      https://www.imdb.com/title/tt0...

    4. Re: Hmmm....Seem like someone dropped the ball. by gerald.edward.butler · · Score: 1

      I'm pretty certain the original joke was from this guy: https://en.wikipedia.org/wiki/...

  12. If only they had asked someone who knows hosting by Anonymous Coward · · Score: 0

    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.

  13. Not an AWS error by Anonymous Coward · · Score: 0

    That's not an AWS error, that's a GoDaddy error. Some idiot didn't know how to use S3.

  14. How is this an AWS error? by technomom · · Score: 1

    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.

    1. Re:How is this an AWS error? by Junta · · Score: 1

      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 on internet accessible contexts. Sure, they shouldn't make the mistake on private networks and that's not defensible and can be a gigantic risk, but in practice the risk is mitigated by the nature of that private network. One would *hope* being on the internet would scare people into good practice, but that does not seem to be a safe outcome to presume.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    2. Re: How is this an AWS error? by Anonymous Coward · · Score: 0

      An AWS employee created the bucket...

  15. Should have been kept confidential by Anonymous Coward · · Score: 0

    This information should have been kept confidential.

  16. Both, and AWS is the user by raymorris · · 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 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.

    1. Re:Both, and AWS is the user by lgw · · Score: 1

      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?

      --
      Socialism: a lie told by totalitarians and believed by fools.
    2. Re:Both, and AWS is the user by Anonymous Coward · · 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 are not used for S3.

    3. Re:Both, and AWS is the user by Anonymous Coward · · Score: 0

      ...AWS says Security Groups is their implementation of a firewall. Just about the only firewall that defaults to wide open, no security at all.

      Minor point: AWS security groups (at least for network traffic) do not default to allow any/any. They have an implicit deny any/any. If no traffic is allowed, nothing gets through. Someone has to punch holes to allow traffic inbound.

      Could be different for S3 buckets. I don't use those so I can't say.

      (posting anon since I have mod points)

    4. Re:Both, and AWS is the user by Anonymous Coward · · Score: 0

      AWS Security Groups are and always have been default Deny All. You have to explicitly add Allow rules to let traffic through.

    5. Re: Both, and AWS is the user by Anonymous Coward · · Score: 0

      You obviously donâ(TM)t know how Aws s3 works, security groups have nothing to do with s3 (vpc and ec2) The default for a s3 bucket is not public.

      Itâ(TM)s also the customers responsibility to secure their own s3 buckets, not aws, under the customer responsibility model.

    6. Re:Both, and AWS is the user by Anonymous Coward · · Score: 0

      S3 buckets are all or nothing. If they are made public, their data is available to all and sundry, regardless of security groups, as security groups don't apply to the public setting for buckets.

      I don't understand how buckets can turn public. When creating one, there is a definite dialog that you have to click through in order to turn a bucket public on creation or when modifying the ACLs. However, I have read about people complaining about EC2 VMs disappearing, so perhaps magically S3 buckets can go public. However, I seriously doubt Amazon would allow something like to come to pass, as it would be caught on any basic audit (and you can run a basic shell script via awscli via cron) to catch stuff like this. In fact, this should be caught via audit tools (like this), similar to open local admin accounts or accounts which have a nonexpiring password.

      I blame this shit on the fact that it is part of a lot of companies that they believe security has no ROI. This, coupled with the fact that C-levels can short their stock once they find out about this, make the announcement public, then laugh all the way to the bank on the stock drop, makes it quite common for shit like this to happen, just because there are zero consequences a company, especially one that holds a bunch of other companies by the balls like a TLD registrar can do.

    7. Re:Both, and AWS is the user by Lord+Ender · · Score: 2

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

      --
      A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
    8. Re:Both, and AWS is the user by MachineShedFred · · Score: 1

      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 all. You have to create security groups that whitelist CIDR / port combinations, and then attach them to the resources. If you want it to be wide open, you would have to actually get an elastic IP, attach it to the instance, create a security group allowing traffic from 0.0.0.0/0 on ports 0-65535, and then attach that security group to the instance.

      None of that happens by default, if using a VPC.

      If you are using EC2-Classic (which really nobody should be unless you are looking to make a single public-available VM for playing around) then yes, it will be far more open. No organization of any size worth talking about would do this, and they would definitely not use EC2-classic under the direction from anyone working at AWS.

      Don't lie about shit you don't know anything about.

      --
      Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
    9. Re:Both, and AWS is the user by Anonymous Coward · · Score: 0

      You've "spent 20 years full time IT security" and are clearly worthless in IT. Even if buckets are open to all by default - which they are not contrary to your lies - any "IT" person who is actually worth a damn would not just click-click-click-click through setup and would make sure that what they are clicking, even if they've done it 100 times, is correct, especially with something so important as security. If you've set up a bucket and "forgotten to change the incredibly stupid AWS defaults, thereby leaving a security problem" as you say, then you should have been fired, because the fault lies squarely with you.

      Regardless of the fact that it was an AWS employee that did this, as I (I'm the parent poster) said, this is not an AWS error, this is a fucking-idiot-who-should-be-fired error. Along with BeauHD, you should get your fucking facts straight, and get a clue while you're at it.

  17. godaddy.... by Anonymous Coward · · Score: 0

    ...they kill elephants, don't they?

    Vword: grieves

    1. Re:godaddy.... by Anonymous Coward · · Score: 0

      They kill brain cells.

  18. Bloopers, deleted scenes of original commercials by Anonymous Coward · · Score: 0

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

  19. Confused-locked in a desk. by Anonymous Coward · · Score: 0

    More than confidential, but should have been locked in a managers desk somewhere. Not put on a network waiting for this to happen.

  20. That's on my TODO list, and we're a small team by raymorris · · Score: 1

    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.

    1. Re:That's on my TODO list, and we're a small team by Anonymous Coward · · Score: 0

      Look at AWS Config

  21. And they are about 100 years behind the times (law by raymorris · · Score: 1

    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.

  22. Misleading Title by duke_cheetah2003 · · Score: 1

    The title suggests Amazon screwed up, when it was GoDaddy that screwed up their usage of Amazon's services. Kinda shady. The title.

    1. Re: Misleading Title by Anonymous Coward · · Score: 0

      It was an AWS employee that set the bucket up.

  23. Misleading Title, it's a USER ERROR! by Anonymous Coward · · Score: 0

    Fucking clickbait bullshit!

  24. AWS needs to work on S3 by Anonymous Coward · · Score: 0

    After so many leaks like this, it just seems that it's too easy to misconfigure S3 buckets. Surely AWS can improve this somehow.

  25. Relax it was a sales person by Anonymous Coward · · Score: 0

    According to article an AWS Sales person created the S3 bucket without following best practices. - now it makes perfect sense. Although unnacceptable.

  26. Why not to go to the cloud by Billly+Gates · · Score: 1

    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.

  27. Retracted by brunes69 · · Score: 1

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

  28. Just some dimwit salesman at Amazon by Anonymous Coward · · Score: 0

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

  29. Re: And they are about 100 years behind the times by Anonymous Coward · · Score: 0

    Nice red herring

  30. Journalism? by Anonymous Coward · · Score: 0

    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.

  31. Re:And they are about 100 years behind the times ( by Anonymous Coward · · Score: 0

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

  32. Re: And they are about 100 years behind the times by Anonymous Coward · · Score: 0

    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.