How a bug in VS2015 exposed my source code on GitHub and cost me $6,500

Post by spdionis » Tue, Sep 01, 2015, 1:41 PM UTC

RussianCow wrote: post #31

Alupis wrote: post #24

Earlier quoted context omitted.

Is it really on the web service companies to make sure you (the developer) don't do anything stupid? The article author could have avoided a lot of headache if he simply checked the repo before walking away. Red flags should have gone up as soon as he received the first weird Amazon messages, but he still didn't think to check his own work. The author calls this a "Data Breach" but in reality it was a "Data Leak".

Amazon would save some money by doing this, since they usually reimburse "victims" of public AWS keys (at least on the first instance) and eat the cost.

Post by zeveb » Tue, Sep 01, 2015, 2:28 PM UTC

curun1r wrote: post #87

zeveb wrote: post #80

Earlier quoted context omitted.

> Don't ever check access keys into any repo, public, private or even self-hosted. So, how do you propose to handle version control of your exact production configuration? Do you think that recording one's production configuration is a valuable (or even useful) technique? Do you propose to have a single file with production configuration relying only on point-in-time backups for history? That gets us back to the bad…

> So, how do you propose to handle version control of your exact production configuration? Version control is perfectly acceptable for that, but the key point is that access keys aren’t part of your production configuration. I personally don’t allow my team to have long-lived AWS access keys that have access to production. Production is only changed via an assumed role requiring MFA or an IAM instance role. If this k…

Post by RussianCow » Tue, Sep 01, 2015, 4:55 PM UTC

spdionis wrote: post #101

RussianCow wrote: post #31

Earlier quoted context omitted.

Amazon would save some money by doing this, since they usually reimburse "victims" of public AWS keys (at least on the first instance) and eat the cost.

They don't "reimburse" anything. They only cancel the due amount. The only thing they lose is their wasted computing power (and some support costs) and I think the RAW computing power is very cheap to them, especially considering their scale. The cost in terms of support for the victims is probably bigger but still not significant.

Post by chrismcb » Wed, Sep 02, 2015, 6:45 AM UTC

Alupis wrote: post #63

nsxwolf wrote: post #54

Earlier quoted context omitted.

There's a huge amount of value in a service that insulates you from mistakes like this. You really, really have to know what you're doing with EC2 because it is a loaded gun. Personally, I don't like using things that are covered in spring loaded booby traps that require eternal hypervigilance in order to avoid nasty financial consequences. Certainly not when deploying something that would be right at home on somethi…

> You really, really have to know what you're doing with EC2 because it is a loaded gun. That's a fair point, but keep in mind the article author was given several warnings that something was wrong, but failed to correct the problem each time (which resulted in the huge bill he ultimately received). At what point is the responsibility on the author here?

Post by koffiezet » Wed, Sep 02, 2015, 4:42 PM UTC

Alupis wrote: post #24

Analemma_ wrote: post #5

This is becoming such a common story that I'm starting to think it's a little irresponsible of both Amazon and GitHub to not react better to it. Clearly Amazon is capable of detecting when this happens as evidenced by their rapid response; when they see AWS keys published to GitHub, they should block the account, or at least prevent it from spinning up any new instances. They can then contact the owner over e-mail to…

Is it really on the web service companies to make sure you (the developer) don't do anything stupid? The article author could have avoided a lot of headache if he simply checked the repo before walking away. Red flags should have gone up as soon as he received the first weird Amazon messages, but he still didn't think to check his own work. The author calls this a "Data Breach" but in reality it was a "Data Leak".