41–50 of 110 posts
Either the author is just mistaken/lying about that point, or there's another leak he doesn't know about, or there's a serious privilege escalation vulnerability in AWS.
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".
Maybe not, but it think it is the web service company's responsibility to alert and contact you on suspicious activity ... like a sudden $6,000 jump in service usage of spot instances in regions you have never used before. I mean a quick automated email would be enough for you to take action. The way it is set up now, you pay for it and humbly beg Amazon to deduct those charges if they see fit.
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".
Yes. Or, it's not so much a responsibility as it is an opportunity. I'd choose the provider that stops me from shooting my foot.
I assume AWS has spending caps for each account. My credit card company blocks my card and calls me if I spend in a suspicious pattern. And so on.
It's similar to driving your car too close to the car in front - you will get away with it most of the time and get lulled into a false sense of security, but eventually it will catch up with you.
Don't be one mistake away from a disaster. Make room for at least two.
Are we really going to run this story every month? "I posted my private AWS keys by mistake on github, a spider got them, I got a huge bill" Yeah, you don't say
Don't be so quick to dismiss this one. This is notable for several reasons, including (1) it wasn't his mistake, but rather that of a Visual Studio bug not following his instructions to make a private repo on GitHub; (2) the speed in which this happened (minutes), and (3) it has useful analysis into some sorely lacking functionality in AWS that lets this continue to happen.
Also if you use a proper IAM profile locked down to specific resources then you wouldn't expose your entire account. The author stated he didn't use EC2 so why wasn't the key/secret pair an IAM account with a policy set for minimal access?
What I'd worry more about is that the VS bug exposed private source code, data and proprietary intellectual property.
We use github and I worry every day someone will public fork one of our repos by accident. That would be a grave fuck up but it's waiting to happen. We should have stuck with centrally controlled active-directory integrated SVN from a security perspective (even if it is a pain in the ass).
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".
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".
Making sure I don't do something stupid and expensive is a value add.
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".
Or just waive the charges.
Why does somebody pushes AWS Keys into a Git Repository? Why should somebody ever push some Authentications? Currently when I code an app I create a database with name of the app and have new credentials with just name:name so that the only thing that I check into my config if the app needs a application.conf or resource.conf are default username:passwords for development, so that bootstrapping is easier. However EVE…
If one wants to use version control to track credentials, then this makes sense. Why would one want to do that? In order to track versions of one's production system. This enables things like one-shot rebuilds.
Now, it's obvious that such a production repository should be separate from one's development repo(s). And one could make a decent argument that it should never be pushed someplace like GitHub anyway, even as a private repository.