AWS Urges Devs To Scrub Secret Keys From GitHub

An anonymous reader writes "GitHub contains thousands of 'secret keys', which are stored in plain text and can be used by miscreants to access AWS accounts and either run up huge bills or even delete/damage the users files. Amazon is urging users of the coding community site to clean up their act."

Comments

How effective is such an ... urging?

[utnapistim]

If the problem is as widespread as TFA suggests, an article/post/urging by Amazon risks simply triggering the Streisand effect (I was tempted to do a search myself after reading the article).

Then again, I'm not sure what else they could have done.

Re:How effective is such an ... urging?

[QuasiSteve]

Wouldn't the Streisand Effect in this context imply that more developers are going to be placing their AWS/API keys in plain view?

I think you're more referring to the effect of full disclosure, where by making it public you end up not just notifying the potential victims (if they're even awake) but also a not statistically insignificant amount of script kiddies - thus instead of having the effect of less exploited victims, you end up getting more. At least initially - in the long run it should be the other way around.

I seem to remember this having been a story before, though, so they should have been warned in the past.. or known better regardless.
Ah, yes: http://it.slashdot.org/story/1...

Re:How effective is such an ... urging?

[gweihir]

You cannot protect stupid people. You can only make sure that you told them they were being stupid in order to prevent that _you_ get blamed for their stupidity. That is what Amazon is doing here. The only other option I would see is forced closing of the affected accounts, but that would likely result in a PR nightmare.

Re:How effective is such an ... urging?

[thaylin]

Poor analogy, a better one would be if you saw someone jump into the ocean, near where sharks have been seen, should be blame you for then deliberately pouring blood near the swimmer in an effort to get him attacked, and yes I would blame you.

Or if someone was speeding, but a drunk ran a stop sign and hit the speeder, do you blame the drunk? Yes.

Or if you leave your front door unlocked and someone walks in and steals all your stuff do we blame the robber? Yes.

Just because someone does something silly does not mean they are not a victim when someone breaks the law targeting them.

Re:How effective is such an ... urging?

[bill_mcgonigle]

The only other option I would see is forced closing of the affected accounts, but that would likely result in a PR nightmare.

They could just delete the authorized_keys file entries on their systems when the matching private key is found on in the wild - on github or elsewhere.

It's a heck of a slippery slope for Amazon, but we should recognize that ultimately they are Amazon's systems. Maybe create an environment where they will do this by default unless you explicitly op-out but if you op-out then there is a no-refunds policy at Amazon for unauthorized use.

Ban 'em

[undulato]

If there is a direct link to be discerned from a Github user to an AWS stack then surely that user should simply be banned and then made to fix their crap before being allowed back on. Back in the 'old days' if the sysadmins on a system I was leasing time off could show that through my action or inaction one of their servers (even my virtual instance) was leaky they wouldn't flinch from shutting my crap down if I didn't comply straight away - and as far as I'm concerned they are quite within their rights to do it.

Re:Ban 'em

[gweihir]

In a time were you can sue the hell out of others because you were stupid, this is unfortunately not an option anymore.

Re:Ban 'em

[Bacon Bits]

It sounds like they're billing users with excessive usage when they get compromised. If that's the case, why should Amazon care that someone who had the correct authentication keys installed bitcoin miners? How are they to know that they weren't installed by the owner? As long as AWS as a service isn't impacted directly, I don't see that they'd care.

More than that, they never say they won't terminate instances for potential ToS violations (that's if poor credential practice is even a ToS violation). I just don't expect Amazon to scan all of Github and all other VCS hosts, either. Amazon isn't going to go looking for customers to punish. You don't aim for your own feet.

Re:Isn't This A Bit Irresponsible?

[mlk]

Depends on how public the knowledge already is.This is the first time I've heard of it, but this kind of thing is done a lot (private stuff thrown on publicly available services that can be found via a Google search) so I'd guess this was already reasonably well known in the bad people circles. By shouting about it Amazon is ensuring that everyone knows without having to track down and inform people individually.

Re:Opensource and web services keys

[kthreadd]

I'm sorry but you can't bundle a secret key in either source code or a binary, ship it to a user and somehow think that the user will be unable to extract it.

And?

[ledow]

The summary tries to make it sound like it's Github's - or even Amazon's - fault.

If you're stupid enough to store credentials that allow access to pay-for goods in your name, and to then blindly upload them to a public service, I have little sympathy.

No more than people who upload their SSH keys, or hard-code their credentials into their code in the first place, or those who put the contents of their passwd/shadow/htpasswd file into a public arena. All of which we've had articles about people doing - and others finding via Google or just a quick inspection of certain projects. I'm sure there was even one with a Steam API key of some kind once.

Sure, it's easy to do if you're not paying attention - especially if you blindly upload a ton of hidden files (Why? Quite what hidden files do you need to upload to a public third-party version-management service? Yes, I've svn'd or bzr'd my /etc/ in the past for basic rollback functionality, but when you press commit to a public service, are you not checking WHAT files are going up and/or excluding hidden files by default anyway?)

Sorry, but for such projects Amazon shouldn't warn them, they should just block those credentials. It's a quick, easy lesson in how to manage your access to a third-party resource, and the hassle of having to redo your account verification should be enough of a kick up the bum to get you to never do it again.

And those people who were billed? Sorry, it's like asking the credit card company to refund you after you post your credit card number in a forum - sure, they might do it, but they are not obligated to as you breached the contract by failing to ensure the security of those details in the first place (proving it was your fault can actually make the credit card company not liable for it, even with "credit card protection" in law - it's just that proving it is usually more hassle than just paying it). The resources were consumed, by someone with your valid credentials. Your problem.

Re:And?

[gweihir]

Indeed. But stupid people (being stupid) will blame Amazon publicly anyways. Remember the random-number generator "bug" in Android recently that left some 30'000 Apps vulnerable? Turns out this was 100% developer error because they did not read the documentation and assumed the Sun/Oracle (but not 'Java') default behavior applied to Android as well. But who got the blame? Google. They did not even try to argue, although they were clearly wronged.

These days stupid people assume that they have a right to demand that everything is idiot-proof. Well, that is just not possible. Especially when mistakes that cannot really be topped in stupidity like the one under discussion are being made. People cannot be this low in intelligence and still be able to learn how to read and write. They can just refuse to apply what intelligence they have to make mistakes this severe. There is a price to pay for that.

Re:And?

[Slashdot Parent]

If you're stupid enough to store credentials that allow access to pay-for goods in your name, and to then blindly upload them to a public service, I have little sympathy.

In fairness, credentials management is a bit of a tricky problem to solve. Most people screw it up.

Here's a real life example: I wrote an automated derivatives trading program that makes trades based on certain triggers. In order to access my brokerage account, the program needs access to my brokerage credentials. How does my program get the credentials? This is not a simple question. Options are:

1. Enter them manually at the start of each trading day. Certainly, this is by far the best option from a security perspective. Unfortunately, that is unacceptable from a usability perspective as I do not want to have to be at my computer at 9:30am each day. What if I forget or I'm busy or something?
2. Store credentials in private source control repository with my code. The repository is private, so this should not be a problem, in theory. Of course, if someone were able to access my source code, that would be a problem. I would like to think that the security practices at my repository provider are up to snuff, but that isn't super reliable. After all, github has had a number of high profile security lapses. I don't use github, but anyway, I don't trust it quite enough to store my credentials there.
3. The platform runs in AWS, so store on the AWS image. I actually did this for a while, but that made key rotation difficult and still trusts the security of AWS (I trust AWS way more than a git provider, but still...).

My current solution is a bit more complicated, but I'm comfortable with it. I store the brokerage credentials in Amazon S3, protected by gpg and S3's access controls. This way, in order to access the credentials file, you need to be on the AWS instance that the platform runs on (due to IAM role ACL), and in order to decrypt the credentials, you need access to the source code. That way, if my source code is compromised, the attacker cannot get my brokerage credentials due to S3 access control, and if S3 is compromised, the attacker cannot decrypt the credentials due to gpg encryption. The attacker would need to compromise both services in order to gain access to the brokerage credentials.

Rocket science? No. But it's not super simple, either. It's unsurprising that many people screw it up.

Re:Everything else is simply too dangerous

[Anonymous Coward]

The last school shooting could have been prevented if only crypto was banned!

Oh you mean the one that happened in a GUN FREE ZONE?

It's as though criminals willing to commit murder aren't afraid of jail and don't obey weapons restrictions huh. If only the law-abiding adults on campus had some method of fighting back...

Re:Opensource and web services keys

[Richard_at_work]

That's not a problem for the developer of the application, that's a problem for whomever is providing the hosted instance of their code. If a "normal non-technical user" is deploying the code, then they should equally be able to solve the problem of third party webservice keys etc where they are required.

Re:Opensource and web services keys

[Richard_at_work]

Your understanding of the open source license requirements is fairly broken - there is NOTHING in the GPL (any version) which requires the distributor of the code to provide access to third party services where they require the use of that third party service.

You are thinking of the anti-tivoism stuff in the GPLv3, which does not cover this.

Supid is as stupid does...

[Lumpy]

these "developers" are making huge rookie mistakes. Honestly you are not a developer if you make that huge of a mistake. I can see hardcoding a key, but the version you put publicly is set to not function until someone changes it. cripes less than 3 lines of freaking code in nearly any language will make your release puke with "change the default key moron, did you not READ the README?"

Best solution, auto generate a key with the install script. Sadly most developers are too freaking lazy to write an install script.

Re: Everything else is simply too dangerous

[Anonymous Coward]

If he shoots you on a daily basis, you may want to consider changing cubes after a few days. Maybe mention this behavior to management, too.