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. The web service company should look at it as basic security - if people are using their service to discover private information and use it to defraud their users, even if the users have been stupid enough to upload that information publicly, the company should do what they can to mitigate the problem.
If I post a photo of my credit card on Twitter I would expect my bank to limit the damage as much as possible by declining obviously fraudulent transactions. Ultimately it's my own fault, and I would be liable for the costs, but that doesn't mean the bank should just let it happen if they can do something to stop it.
This seems like very minor engineering effort on behalf of GH - simple regexes, even.
I don't think this would be a minor undertaking or simple in any way, but it is important enough that a provider (and target) the size of GitHub should still do it.
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.
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.
FTFY
It baffles me that people actually do this. Passwords and secrets DO NOT BELONG THERE. Even your 'if he simply checked the repo' statement is in my view completely crazy. No you should not have to worry about that, because that should not be there at all. Leaking your source-code should not result in a system-breach at any point.
Or just waive the charges.
Making sure I don't do something stupid and expensive is a value add.
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 something like Heroku.
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?
This is the answer I would like to see implemented. If they can detect the key they can put a freeze on the account so that only existing resources are available.
They should also have a timeline of all created instances in every zone so you can see what has happened in the last x hours and kill all instances at once.
* Allow me to see all instances in all regions from a single screen
* When accounts are first created for AWS, set up some sane default IAM policies and/or hire some UI designers to fix that godawful mess.
From committing the basic design error of using hard-coded credentials at all; to committing them to any kind of repository; to failing to check on the visibility of that repository; to giving those credentials privileges they did not need; to failing to act effectively on warning messages.
And all this, apparently, is laid at the feet of Visual Studio.
I have no love of the Microsoft ecosystem, but the author does not acquit themselves well in this incident. The arrogant claims of seniority in the opening paragraph seem ironic in this light.
I wonder if you actually read the story.
He admits several faults including most if not all of those you mention.
https://github.com/hootware/github-firehose-node
http://blog.scalyr.com/2013/10/exploring-the-github-firehose...
I do wonder if GitHub's events firehose has benefits that outweigh all the compromised credentials, though. Not just limited to AWS keys.
That's almost worse though. Maybe I'm being unfair here, but the fact that they will waive charges immediately if you ask, but don't just block them pre-emptively, tells me that they're hoping at least some customers (with deep pockets and automated billing that no one pays attention to) will just pay the bill and never notice. Maybe they're making more money from that than they're losing by waiving charges on compromised accounts for customers who ask.
Even if it's public... That's still a Gmail-esque situation that would immediately raise privacy concerns.
Developers should pay attention to what they're doing. Your AWS keys shouldn't even been in your private repo. You should find another way or you shouldn't be using a third-party for source control.
Stop doing it in the first place, problem solved. I don't see why GitHub or Amazon need to hold my hand through a serious process. It would diminish the importance of what you're doing.
Also, this guy didn't just use AWS keys...he clearly used AWS master keys...which has not been the recommended course of action for AT LEAST THREE YEARS...if he had used a proper IAM user with only the access he needed, this wouldn't have happened. Sorry, but that was just irresponsible.
No it wouldn't, not at all. Not unless you're one of those, "REAL MEN us {$editor}" people, in which case no one cares about your opinion.
Same thing with GitHub. When they see an AWS key, they need to block that push and send back a message saying "If you're really, really, REALLY sure you want to do this, add .allowawskey at the root of your commit and push again". There's no excuse for letting people shoot themselves in the foot like this over and over.
(Edited for typo)