Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Open Source Security IT

AWS Urges Devs To Scrub Secret Keys From GitHub 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."
This discussion has been archived. No new comments can be posted.

AWS Urges Devs To Scrub Secret Keys From GitHub

Comments Filter:
  • 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: (Score:3, Informative)

      by QuasiSteve ( 2042606 )

      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

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

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

    • by Anonymous Coward

      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.

    • by gweihir ( 88907 ) on Monday March 24, 2014 @06:57AM (#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.

      • 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

        • by gweihir ( 88907 )

          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.

          • unless they can show a clear and present danger.

            I won't pretend to understand the mind of European bureaucrats - do you think they would hold that having a criminal take over a computer system is not sufficient grounds for the owner of that system to take corrective action?

            If that truly is the case, then Amazon should just nuke the vm in those jursidictions and tell the machine owners to take it up with their government or choose a hosting zone with different regulations.

            • by gweihir ( 88907 )

              You do not understand the problem at hand either: It is not a clear and present danger to Amazon if a key leaks. They may only interfere it it endangers the operation of their network and servers. While the US may be a complete nanny-state now (well, bad nanny that punishes and lest people starve but that does insist of control in everything), in Europe, you are expected to understand what you are doing to some degree and your service provider has no obligation to protect you against your own stupidity.

    • 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 detecte

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

    • You and I both, frankly.
  • Ban 'em (Score:5, Insightful)

    by undulato ( 2146486 ) on Monday March 24, 2014 @04:21AM (#46562087) Homepage
    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.
    • by gweihir ( 88907 )

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

    • 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 j

      • 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

        • by Eric Green ( 627 )

          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.

  • 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

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

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

      • by zarlino ( 985890 )

        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.

        • by kthreadd ( 1558445 ) on Monday March 24, 2014 @06:10AM (#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.

          • by zarlino ( 985890 )

            Of course.

          • 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 tha

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

              • by tepples ( 727027 )

                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.

                • by Eric Green ( 627 )

                  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.

        • by Richard_at_work ( 517087 ) on Monday March 24, 2014 @07:03AM (#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.

          • by zarlino ( 985890 )

            Hosted? I was mainly referring to desktop applications.

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

      • by Lumpy ( 12016 )

        Yes you can. and real developers do just that.

      • 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.
      • by gweihir ( 88907 )

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

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

    • by Richard_at_work ( 517087 ) on Monday March 24, 2014 @07:05AM (#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.

      • by zarlino ( 985890 )

        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.

    • by PhilHibbs ( 4537 )

      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.

      • 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

    • by dalias ( 1978986 )

      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 possibilit

  • And? (Score:5, Insightful)

    by ledow ( 319597 ) on Monday March 24, 2014 @06:15AM (#46562309) Homepage

    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: (Score:3, Interesting)

      by gweihir ( 88907 )

      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 dema

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

    • hear hear *clapping*

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

  • by Lumpy ( 12016 ) on Monday March 24, 2014 @07:15AM (#46562491) Homepage

    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.

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

    • by jpvlsmv ( 583001 )

      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.

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

    • by gweihir ( 88907 )

      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.

      • Why is it deserved?
        • by gweihir ( 88907 )

          If you have to ask, then you are not capable to understand the answer. But you may want to visit a shrink sometime.

          • I think you may be the one that needs to visit the shrink sometime, because you somehow think that people should be punished just for being stupid, even when they did not cause any harm to other people in the process.
    • by dlgeek ( 1065796 )
      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.
  • by azav ( 469988 )

    > 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?

    • 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.
    • by tepples ( 727027 )

      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.

      • by azav ( 469988 )

        If that is true, it's pretty pathetic.

        How can people be allowed in if they don't show a basic competence with the very basics of the language they are supposed to converse in?

        • English is not necessarily required if you go to college somewhere other than [Britain or one of its ex-colonies].

          How can people be allowed in if they don't show a basic competence with the very basics of the language they are supposed to converse in?

          In countries whose official language is not English, conversing in English is not necessarily required. For example, universities in France likely conduct classes in French.

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

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

  • 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
    • by Eric Green ( 627 )

      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.

There are new messages.

Working...