Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

AWS Urges Devs To Scrub Secret Keys From GitHub

timothy posted about 6 months ago | from the key-is-under-the-mat dept.

Open Source 109

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

cancel ×

109 comments

Sorry! There are no comments related to the filter you selected.

Everything else is simply too dangerous (-1)

Anonymous Coward | about 6 months ago | (#46562061)

The Government should only allow organized criminals and the Government to have guns. Everything else is simply too dangerous. Too Undemocratic.

Re:Everything else is simply too dangerous (1, Insightful)

Anonymous Coward | about 6 months ago | (#46562091)

Agreed. Also, The People should not have access to:

1. crypto
2. computers with unsigned boot chains.
3. unlicensed programming tools of any kind.
4. untrackable vehicles
5. untrackable currency
6. non networked home appliances

We're only about a decade or two away from this being 'normal'.

Re:Everything else is simply too dangerous (-1)

Anonymous Coward | about 6 months ago | (#46562117)

War is Peace
Freedom is Slavery
Ignorance is Power

Funny isn't it how all these things were relevant then and remain so today. There's nothing new under the sun.

Re:Everything else is simply too dangerous (-1)

Anonymous Coward | about 6 months ago | (#46562119)

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

Re:Everything else is simply too dangerous (2, Insightful)

Anonymous Coward | about 6 months ago | (#46562431)

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: Everything else is simply too dangerous (0)

Anonymous Coward | about 6 months ago | (#46562601)

Everybody is a law abiding citizen until they are not. What is stupid is acting as if all gun injuries and death happen because of deliberate action and not because of irresponsibility and carelessness.

I'd rather have a gun free zone and remove an option that can result in death from an impulse decision or just plain stupidity.
I'm more afraid of the idiot in the next cubicle accidentally shooting me on a daily basis than a remote chance of one day a mass murderer walking through the front door.

Re: Everything else is simply too dangerous (4, Funny)

Anonymous Coward | about 6 months ago | (#46562829)

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.

Re: Everything else is simply too dangerous (0)

Oligonicella (659917) | about 6 months ago | (#46563607)

All multiple murders *HAVE* been premeditated. Turn your damned brain on. Gun free zones have not one thing to do with irresponsibility and carelessness on the part of the gun perp, only on the part of those preventing others from defense. You know, like you with your very, very lame reasoning. .

Re: Everything else is simply too dangerous (0)

Anonymous Coward | about 6 months ago | (#46564809)

Yes, but multiple murders (Columbine, Sandy Hook, etc) are a drop in the bucket wrt total gun deaths.

Re:Everything else is simply too dangerous (0, Insightful)

Anonymous Coward | about 6 months ago | (#46562953)

This is a fucking stupid argument. The reason there are loads of school shootings in America but almost nowhere else is not because America has stricter gun laws than everywhere else, but because America has a gun culture which is propped up by easy access to guns.

If it wasn't easy to get a gun, or if guns weren't considered a solution to problems, there wouldn't be so many school shootings.

Gun-fanboys are as subtle with their argument as with the tools they think can be used to end them.

Re: Everything else is simply too dangerous (0)

Anonymous Coward | about 6 months ago | (#46564385)

Guns are illegal in Mexico and they don't have any problems with murders...oh wait...

Re:Everything else is simply too dangerous (-1)

Anonymous Coward | about 6 months ago | (#46563039)

A tiny gun free zone in the middle of a gun owning country. Yeah that works.

and (-1)

Anonymous Coward | about 6 months ago | (#46562123)

and be required to wear a head set that actually sees everything you do and cant be removed except to shower where also a camera the nsa has to peek at you is maintained...all at your cost

Re:Everything else is simply too dangerous (1)

mrchaotica (681592) | about 6 months ago | (#46564345)

Obligatory RMS [gnu.org]

Barn Door. (-1)

Anonymous Coward | about 6 months ago | (#46562067)

The G has done gotten all them doggies.

How effective is such an ... urging? (4, Insightful)

utnapistim (931738) | about 6 months ago | (#46562077)

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? (2, Informative)

QuasiSteve (2042606) | about 6 months ago | (#46562137)

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... [slashdot.org]

Re:How effective is such an ... urging? (1)

utnapistim (931738) | about 6 months ago | (#46562207)

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

Yes, that's what I meant.

Re:How effective is such an ... urging? (0)

Anonymous Coward | about 6 months ago | (#46562479)

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.

Adult people who make bad decisions and then suffer are not victims. A human agent facilitating the damage of their bad decision-making does not change that. If the person saw clearly that a bunch of sharks were in the water and decided to jump in anyway, would you blame the sharks for victimizing them or the person for jumping in? Until people wake up and figure this out, computer security will always have extremely low hanging fruit with lots of script kiddies feeding on it, like racoons eating from garbage cans.

Re:How effective is such an ... urging? (4, Insightful)

thaylin (555395) | about 6 months ago | (#46562659)

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? (0)

Anonymous Coward | about 6 months ago | (#46563947)

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.

Ah see that is the difference between us. Your primary concern is blame and where to best assign it. My primary concern is preventing security breaches.

Preventing a breach means "don't do stupid shit like this". Whether the evil hackers go to hell for eternity as punishment for their evildoing or not, is irrelevant. Whether the "victim" should be considered blameless is irrelevant. Fact is, doing certain things invites security breaches. Not doing those things makes them much less likely.

I know what I do with *my* systems, and it doesn't involve deciding which hackers are naughty or nice. Coincidentally I don't have these problems.

Re:How effective is such an ... urging? (1)

thaylin (555395) | about 6 months ago | (#46565555)

And that has to do with the original post, which was specifically about assigning blame, how? Claiming someone is not a victim if they do x is just shifting the blame from the perpetrator of the attack to the victim.

Or was the first one just some sort of troll attempt so you could come back and sound smart, by moving the goal post?

I never stated that what the people are doing was ok, in fact I called it silly, but the thing to remember is that EVERYONE does "stupid shit like this" on their machines, even you. It may not be as bad, but we all do stupid shit.

Re:How effective is such an ... urging? (0)

gnick (1211984) | about 6 months ago | (#46564285)

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

Agreed. AND you ticket the speeder.

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

Agreed. AND you raise the home-owner's insurance rates because they leave without locking their door and putting themselves at higher risk.

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

I still agree. I think the debate here is more similar to noticing that there are unlocked doors and then posting an article announcing that people need to start locking them or risk burglary. If it's reasonable to notify each homeowner with an unlocked door that they and their family are at risk of burglary, then you do that. If that's not reasonable, you just tell everyone that there's a potential of burglary if they leave their doors open.

Re:How effective is such an ... urging? (1)

parkinglot777 (2563877) | about 6 months ago | (#46565595)

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 his meaning is that there would be more people searching/looking for the secret-key which is in plain text. If I remember correctly, Streisand Effect is the effect of trying to hide something from others, but instead it becomes more obvious to public because of certain disclosure. In this case, the AWS disclosed the information which is supposed to be hidden from public. Now it is obvious to others.

Re:How effective is such an ... urging? (1)

Anonymous Coward | about 6 months ago | (#46562237)

No, bad guys are already exploiting the AWS keys in github and there are already hundreds of documented cases. The advice from Amazon is sound and doesn't increase the risks for their users.

Re:How effective is such an ... urging? (4, Insightful)

gweihir (88907) | about 6 months ago | (#46562423)

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? (2)

bill_mcgonigle (4333) | about 6 months ago | (#46563777)

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.

Re:How effective is such an ... urging? (1)

gweihir (88907) | about 6 months ago | (#46572047)

Amazon does not own the data. In Europe, for example, what you propose may well be criminal for them to do unless they can show a clear and present danger.

Re:How effective is such an ... urging? (1)

gbjbaanb (229885) | about 6 months ago | (#46562821)

they could change the locks - and then tell every AWS client that a) the locks have changed so they need to regen a new key, b) change the T&C to say keys are private and are not to be publicly shared, if you do you lose that AWS account.

Then they can search github for keys and lock the relevant accounts, in the interest of security - as I guess the scammers will be happily helping themselves to those keys to create whatever nasties they can get away with on their new free hosting until they are detected.

Block their accounts (0)

Anonymous Coward | about 6 months ago | (#46563403)

What else could Amazon have done? Terminate their accounts immediately. These people violated the TOS by publishing their secret key.

Re:How effective is such an ... urging? (1)

scottbomb (1290580) | about 6 months ago | (#46565845)

Congratulations! Out of 16 posts so far, yours is the first one that's actually ON TOPIC.

Ban 'em (5, Insightful)

undulato (2146486) | about 6 months ago | (#46562087)

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 (2)

gweihir (88907) | about 6 months ago | (#46562455)

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 (2)

Bacon Bits (926911) | about 6 months ago | (#46562729)

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:Ban 'em (1)

bill_mcgonigle (4333) | about 6 months ago | (#46564119)

If that's the case, why should Amazon care that someone who had the correct authentication keys installed bitcoin miners?

Two reasons:

1) they will probably wind up issuing refunds for some amount of it. Even if they don't refund then it will take up CSR time to deal with the upset user. Upset users may go elsewhere. It might also be cheaper to refund than to pay humans to deal with not refunding. Automated systems to prevent this may well be worth the investment.

2) bitcoin miners are probably the least of their worries. Spammers will get a whole netblock blacklisted, and that definitely has a cost to deal with. Paying customers won't do these kinds of things nearly as often because they have some consequence for doing so (being shut down). The thieves _expect_ to be shut down eventually and have already built that into their economic model.

Re:Ban 'em (1)

Eric Green (627) | about 6 months ago | (#46570945)

Spammers definitely will *not* get a whole Amazon netblock blacklisted. Amazon firewalls outgoing port 25 traffic. If you want to send email from AWS you need to bounce it via authenticated port 465 or 537 through a mail service on some other ISP.

Failtoban confirms (1)

sjwest (948274) | about 6 months ago | (#46562101)

Run it, log it and you too will see a lot of aws

54.193.36.150
54.193.50.3
54.193.73.95
54.193.95.230
54.194.121.137
54.194.145.249
54.194.178.152
54.194.198.11
54.194.198.139

Wont bore you further, not sure informing abuse at amazon does anything though

Isn't This A Bit Irresponsible? (0)

Anonymous Coward | about 6 months ago | (#46562111)

I don't mean to be negative, but if there is a known vulnerability out there, advertising it publicly is just going to be a banner for the criminals and script kiddies to go cause damage. It seems as though Amazon have scored an utterly stupid own goal here...

Re:Isn't This A Bit Irresponsible? (2)

mlk (18543) | about 6 months ago | (#46562131)

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:Isn't This A Bit Irresponsible? (1)

QuasiSteve (2042606) | about 6 months ago | (#46562243)

Depends on how public the knowledge already is

Readily public - even if not specific to AWS:

http://it.slashdot.org/story/1... [slashdot.org]

Re:Isn't This A Bit Irresponsible? (0)

Anonymous Coward | about 6 months ago | (#46562185)

But it isn't a vulnerability, it's people being stupid and now amazon says that they have noticed alot of people being stupid and asks them to stop being so stupid. They were already told not to be stupid when they signed up with aws but they obviously didn't listen.

Re:Isn't This A Bit Irresponsible? (0)

Anonymous Coward | about 6 months ago | (#46562233)

Wat? The secret key is supposed to be kept secret? Who the hell knew that already?

Re:Isn't This A Bit Irresponsible? (0)

Anonymous Coward | about 6 months ago | (#46564421)

Wat? The secret key is supposed to be kept secret? Who the hell knew that already?

Move fast and break things. Put everything on a publicly-accessible DVCS. Make your project dependent on stuff that someone else puts on a publicly-accessible DVCS. Agile! Cloud! Brogrammers can Lean In, too!

web development company in chennai (-1)

Anonymous Coward | about 6 months ago | (#46562147)

Wow Really very useful information.
Thanks a lot for sharing it with us. I will look forward to read more from you. Could I share this information on my site.Web Designing in Chennai [slashdot.org]

Re:web development company in chennai (0)

Anonymous Coward | about 6 months ago | (#46563963)

Hehhee, you botched the link. Stupid spammer.

Opensource and web services keys (0)

zarlino (985890) | about 6 months ago | (#46562177)

Many web services require developers to get keys for their applications. Open source applications cannot provide users with working apps without disclosing the keys.

Re:Opensource and web services keys (1)

kthreadd (1558445) | about 6 months ago | (#46562217)

Can't you just ship the software and let the user provide the key?

Re:Opensource and web services keys (1)

zarlino (985890) | about 6 months ago | (#46562277)

Getting the key requires registering an application and may be validated by the company providing the web service. How a normal non-technical user could do it? Even if it is was just creating an account it would be too much for a casual user of an application.

Re:Opensource and web services keys (5, Insightful)

kthreadd (1558445) | about 6 months ago | (#46562293)

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.

Re:Opensource and web services keys (1)

zarlino (985890) | about 6 months ago | (#46562313)

Of course.

Re:Opensource and web services keys (0)

Anonymous Coward | about 6 months ago | (#46562559)

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.

Tell that to the DRM people, they still haven't figured that out for some reason.

Re:Opensource and web services keys (1)

gnasher719 (869701) | about 6 months ago | (#46563681)

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.

The amount of effort can have major legal effects. For example, an easily circumventable copy protection measure turns copying from "copyright infringement" to "DMCA violation". Where I was raised, theft came in different categories for "taking away unprotected items", "taking by circumventing locks or other protection measures", "taking by using force or threat of force against persons", and "armed robbery". So the fact that a user extracted a key from a binary might have strong legal consequences, and that alone may be enough to make a difference.

Re:Opensource and web services keys (1)

mrchaotica (681592) | about 6 months ago | (#46564251)

But why would a script kiddie on some other continent give a shit about any of that?

Re:Opensource and web services keys (1)

tepples (727027) | about 6 months ago | (#46564519)

But why would a script kiddie on some other continent give a shit about any of that?

Because a country on some other continent has entered into a bilateral trade agreement with the United States.

Re:Opensource and web services keys (1)

Eric Green (627) | about 6 months ago | (#46570965)

Which, in combination with $1, will buy you a cup of coffee. I haven't noticed that Eastern European or Chinese spammers and attackers have been deterred one whit by those bilateral trade agreements.

Re:Opensource and web services keys (3, Informative)

Richard_at_work (517087) | about 6 months ago | (#46562439)

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 (1)

zarlino (985890) | about 6 months ago | (#46564281)

Hosted? I was mainly referring to desktop applications.

Re:Opensource and web services keys (1)

Richard_at_work (517087) | about 6 months ago | (#46564339)

Then your post makes even less sense.

The AWS keys referred to in the article are for the storage accounts et al, so theres no "registration" or "validation" of an application going on, you just sign up to AWS, create a bucket for S3 or whatever, and supply the connection credentials to the app.

And that is something that the end user most definitely should be doing.

Re:Opensource and web services keys (0)

Anonymous Coward | about 6 months ago | (#46562509)

Getting the key requires registering an application and may be validated by the company providing the web service. How a normal non-technical user could do it? Even if it is was just creating an account it would be too much for a casual user of an application.

If you are going to treat users like children (which is what you are doing here), do it right. Expect them to learn new things just like children do in school. You will find that users will figure it out if you stop coddling them and legitimizing their laziness. In other words, if you treat them like responsible adults and expect that to be normal.

Re:Opensource and web services keys (1)

zarlino (985890) | about 6 months ago | (#46564489)

What if I'm developing apps for kids?

COPPA (1)

tepples (727027) | about 6 months ago | (#46564533)

Then you shouldn't be collecting personally identifying information from them in the first place without verifiable parental consent.

Re:Opensource and web services keys (1)

Lumpy (12016) | about 6 months ago | (#46562499)

Yes you can. and real developers do just that.

Recurring developer fee (1)

tepples (727027) | about 6 months ago | (#46562647)

Not if each developer key costs a recurring fee. For example, Amazon Marketplace Web Service requires both the developer of the application and the seller using the application to be current on a $480/yr subscription. Not sure about the rest of AWS though.

Re:Recurring developer fee (1)

Slashdot Parent (995749) | about 6 months ago | (#46562883)

Not sure about the rest of AWS though.

There is no annual fee to have AWS keys. With AWS, you pay only for your usage.

Re:Opensource and web services keys (1)

gweihir (88907) | about 6 months ago | (#46563121)

No. They could just refuse service to complete morons. Other than that, there is nothing they can do.

Re:Opensource and web services keys (1)

gnasher719 (869701) | about 6 months ago | (#46562357)

Many web services require developers to get keys for their applications. Open source applications cannot provide users with working apps without disclosing the keys.

Depends on your definition of "working app". The source code can contain a random number, and it will work correctly in the sense that it sends the random number to the server to identify itself, and correctly determines that the server rejected it. Like a CD player application; you wouldn't expect the developer to supply CDs with it. Or an app processing credit card numbers for payment.

Re:Opensource and web services keys (3, Insightful)

Richard_at_work (517087) | about 6 months ago | (#46562449)

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.

Re:Opensource and web services keys (1)

zarlino (985890) | about 6 months ago | (#46564373)

I have a fair understanding of software licensing, thank you. I was not referring to the GPL in particular, nor any other license. It's not a licensing problem and I don't know why you misread my comment in this sense.

Re:Opensource and web services keys (1)

PhilHibbs (4537) | about 6 months ago | (#46563457)

Closed source applications that access web services have to ship with a key as well. The only difference is how easy it is to access the key. It's the same issue as DVD players. Eventually someone cracked a key, because the DVD player has to be able to read the key.

Re:Opensource and web services keys (1)

gnasher719 (869701) | about 6 months ago | (#46563609)

Closed source applications that access web services have to ship with a key as well. The only difference is how easy it is to access the key. It's the same issue as DVD players. Eventually someone cracked a key, because the DVD player has to be able to read the key.

I think the problem is that with a closed source application, the API key can be somewhere in the source code, and I compile it, and then the API key is invisible except to a determined hacker. That's fine because I don't give you the source with the API key. With open source, I don't mind at all if you get the complete source code - with the exception of the single line with the API key. You would be free to get your own API key and put it into that single line of code and build your own version.

The API key is basically a promise to the service provider "you have my name and email address, and I promise not to abuse the API key by doing DOS attacks against your server or trying to hack into it". I can't make that promise for you, if you get a copy of the source code.

Re:Opensource and web services keys (1)

dalias (1978986) | about 6 months ago | (#46564601)

If your FOSS application interacts with a web-based service that requires an API key, the correct way to implement it is to instead have it interact with your own servers, and in turn have your servers interact with the web service via the API key. You should of course then publish the source to the server-side part of your application as well, and advanced users can then (if they really want to) setup their own server, with their own API key for the web service; this also protects users from the possibility that you disappear and shtudown your server or let it rot.

Of course this design assumes it's a web service your users are accessing anonymously. If they have to login to their own accounts, then this model is usually wrong. They should never be providing their account credentials to you, and it can only work correctly with more advanced authentication methods that avoid the need for them to provide credentials to you, which the web service is unlikely to support.

I urge them to (-1)

Anonymous Coward | about 6 months ago | (#46562183)

AWS Urges Devs To Scrub Secret Keys From GitHub

I urge them to scrub my bollocks with a stiff brush

Re:I urge them to (-1, Offtopic)

Chrisq (894406) | about 6 months ago | (#46562213)

AWS Urges Devs To Scrub Secret Keys From GitHub

I urge them to scrub my bollocks with a stiff brush

The original post was a euphemism; they want the same thing.

Fuck Beta (0)

Anonymous Coward | about 6 months ago | (#46562259)

Beta ate my comment.

Re:Fuck Beta (0)

Anonymous Coward | about 6 months ago | (#46564579)

Please describe more accurately what happened, so that the Slashdot development team can fix the bug.

And? (5, Insightful)

ledow (319597) | about 6 months ago | (#46562309)

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? (0)

Anonymous Coward | about 6 months ago | (#46562683)

That's exactly right. This is neither Github's nor Amazon's fault. Blame lies squarely on the user who uploaded their code to a public repository without first sanitizing it properly of all confidential information.

All Amazon is doing here is trying to highlight the problem and get in front of it in order to prevent a public relations nightmare for AWS. I see no issue with that.

Re:And? (2, Interesting)

gweihir (88907) | about 6 months ago | (#46563111)

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? (2)

Slashdot Parent (995749) | about 6 months ago | (#46563159)

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:And? (0)

Anonymous Coward | about 6 months ago | (#46563331)

Fyi: slashcode is an abortion. Don't bother making ordered or unordered lists—that has been broken for years. As you see from your post, it is rendered as an indent. WTF?

Re:And? (1)

jones_supa (887896) | about 6 months ago | (#46564161)

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.

I have sympathy towards them. At least they did not act maliciously on other people but instead they mistakenly published their own private information. People make stupid mistakes...hey, I make stupid mistakes. Let's educate them to be smarter, instead of having them suffer of the outcomes of their stupidity. Let's make the world a more secure place for everyone. And that is precisely what Amazon is doing here.

Re:And? (0)

Anonymous Coward | about 6 months ago | (#46564549)

Amazon is at fault, as are the developers. Like too many other companies, they have services designed to be embedded in other applications but haven't designed their security in a way to account for this. Even if GitHub never existed the deployed applications all have these keys in them in a way that should be very easy to snoop, meaning that this could be just the start of an avalanche of AWS account problems.

Re:And? (1)

gunnaraztek (1077439) | about 6 months ago | (#46566673)

hear hear *clapping*

we need something for this, kinda like the darwin awards but for this kinda fails :)

Supid is as stupid does... (2)

Lumpy (12016) | about 6 months ago | (#46562491)

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:Supid is as stupid does... (1)

phantomfive (622387) | about 6 months ago | (#46564591)

There are a lot of rookie developers out there these days. And some more experienced ones who say bugs are not a big deal [google.com] .

With that kind of outlook, it's not surprising they are making rookie mistakes.

In related news... (1)

WPIDalamar (122110) | about 6 months ago | (#46562991)

In related news...

Google suggests you don't post your username & password to GitHub.
The locksmith's union suggests you don't tape your key to your front door.
The TSA suggests you don't write your combination on your luggage.

Re:In related news... (1)

jpvlsmv (583001) | about 6 months ago | (#46563651)

In related news...

Google suggests you don't post your username & password to GitHub.
The locksmith's union suggests you don't tape your key to your front door.
The TSA suggests you DO write your combination on your luggage.

FTFY. Or at least that you use the same key that everybody else does.

AWS needs to fix things up (0)

AtomicDevice (926814) | about 6 months ago | (#46563053)

People aren't putting their secret keys into code _just_ because they are dumb, it's also by far the simplest way to write code that uses amazon services from inside ec2. There are other (not particularly complicated and very secure) ways to do it, but amazon should probably look into making those so dead-simple no one would even think of using something else.

Re:AWS needs to fix things up (1)

gweihir (88907) | about 6 months ago | (#46563143)

Sorry, but people doing that are worse than dumb. They do not care! Anything they get as result of their utter stupidity is well-deserved.

Re:AWS needs to fix things up (1)

jones_supa (887896) | about 6 months ago | (#46564217)

Why is it deserved?

Re:AWS needs to fix things up (1)

dlgeek (1065796) | about 6 months ago | (#46563833)

You mean like IAM Roles for EC2 [typepad.com] which makes credentials show up on your instance and the SDK uses them automatically? And which launched in 2012?

Seriously, it's as easy as S3Client s3 = new S3Client(); and the SDK does the rest. If devs are still hardcoding credentials, I have no sympathy.

Umm (0)

azav (469988) | about 6 months ago | (#46563065)

> the users files

Um, that should be "the user's files".

users = more than one user

How the poster can have problems with the difference between possessive and plural and still be allowed to use a computer is beyond me. Aren't you supposed to learn fourth grade English before you get to college?

Re:Umm (0)

Anonymous Coward | about 6 months ago | (#46563199)

i dont lick you your dum

Re:Umm (1)

jones_supa (887896) | about 6 months ago | (#46564249)

I do not know why you are modded down. There indeed is that error in the summary which should have been fixed by the submitter or the editor.

ESL (1)

tepples (727027) | about 6 months ago | (#46564587)

Aren't you supposed to learn fourth grade English before you get to college?

English is not necessarily required if you go to college somewhere other than the United States, Canada, Great Britain, Ireland, Australia, New Zealand, South Africa, or India.

Better way to handle this (1)

sideslash (1865434) | about 6 months ago | (#46563443)

Amazon should assign a junior engineer to personally be responsible to search/scrape the web for leaked keys, and privately contact the owners of those accounts. That would make for good PR.

Nice job obfuscating the key (0)

El_Muerte_TDS (592157) | about 6 months ago | (#46563603)

When posting screenshots containing secret keys, just remove a large part of it. Don't use blur or swirl like filters, these can be reversed quite well.

The blurred key posted by itnews is pretty much reversible with the naked eye.

Re:Nice job obfuscating the key (1)

DigitAl56K (805623) | about 6 months ago | (#46564545)

When posting screenshots containing secret keys, just remove a large part of it. Don't use blur or swirl like filters, these can be reversed quite well.

The blurred key posted by itnews is pretty much reversible with the naked eye.

According to the summary the blurred key, and others, are already available in plaintext on Github meaning countless people could have already captured them and possibly still can.

start telling the truth aws (1)

gerald krug (3590867) | about 6 months ago | (#46565615)

Bull ! Aws has a bad problem with billing because you can't terminate instances until you delete what the instance is running. It re starts after you terminate CRAZY

Re:start telling the truth aws (1)

Eric Green (627) | about 6 months ago | (#46570919)

I'm not quite sure what you're talking about. Auto-scaling groups are the only thing that can restart a terminated instance (actually, they start a *new* instance). If you somehow managed to create an auto-scaling group and don't know how to set its parameters (min/max/desired) down to zero, when it's right there on the GUI, I don't know what to tell you.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?