Slashdot Mirror

← Back to Stories (view on slashdot.org)

Github Kills Search After Hundreds of Private Keys Exposed

Posted by Soulskill on from the take-care-what-you-make-public dept.

mask.of.sanity writes "Github has killed its search function to safeguard users who were caught out storing keys and passwords in public repositories. 'Users found that quite a large number of users who had added private keys to their repositories and then pushed the files up to GitHub. Searching on id_rsa, a file which contains the private key for SSH logins, returned over 600 results. Projects had live configuration files from cloud services such as Amazon Web Services and Azure with the encryption keys still included. Configuration and private key files are intended to be kept secret, since if it falls into wrong hands, that person can impersonate the user (or at least, the user's machine) and easily connect to that remote machine.' Search links popped up throughout Twitter pointing to stored keys, including what was reportedly account credentials for the Google Chrome source code repository. The keys can still be found using search engines, so check your repos."

22 of 176 comments (clear)

  1. At least... by Anonymous Coward · · Score: 5, Funny

    they've been seen by 'many eye balls'.

    That's good right?

    1. Re:At least... by ArsenneLupin · · Score: 4, Funny

      But on the other hand, you certainly wouldn't object to any gals exposing their pubic "locks"...

  2. This is why developers are not sysadmins by h4rr4r · · Score: 3, Insightful

    This is why developers are not sysadmins.

    These kinds of repositories need to learn that and not let these folks do this sort of thing. If would be simple to use a regex to filter out the posting of these sorts of files. Maybe Devs should even be charged a couple dollars to get a decent review of these things.

    1. Re:This is why developers are not sysadmins by Anonymous Coward · · Score: 5, Insightful

      No. This is actually completely absurd. A developer that cannot grasp the concept that private keys have to be kept private, cannot be trusted to do anything but screw up the most basic security provisions when writing code.

      They should get a kick in the ass, such as three months without any sort of commit privileges, and mandatory code review for an year. THAT should be enough to make it stick, and impress on them the real gravity of their failure. Otherwise, they will just chalk it up as "an annoyance done by those uninteresting people who should learn to code before they go pestering code-gods".

    2. Re:This is why developers are not sysadmins by h4rr4r · · Score: 4, Interesting

      Sysadmins should also know how to code. Nothing better than showing them their screwup and the solution to it.

      Plus, since all sysadmins, real ones anyway, are already competent in several scripting languages it is not that hard a skill to add if all you need to do is be better than bottom of the barrel programmers.

    3. Re:This is why developers are not sysadmins by ArsenneLupin · · Score: 5, Insightful
      In some of these instances, all of ~/.ssh/ did actually end up in the project directory. Or maybe they used their entire home directory as the project root? Stoopid, stoopid people.

      (Yes, there is also a nice ~/.ssh/config file, so that you also know which locks those key fits...)

    4. Re:This is why developers are not sysadmins by Raumkraut · · Score: 3, Insightful

      I've seen several people comment that they have their home directory config files under version control. If you're using git for that, it's a fairly simple next step to then "backup" the repo to github.
      "It's only config files; nobody would be interested in those."

    5. Re:This is why developers are not sysadmins by KingMotley · · Score: 3, Interesting

      I dunno about that here. Ever since they rolled out Sophos Full Disk Encryption on every desktop and server here, it's contributed more to downtime than any virus/malware ever has. I think literally every person in this office has had to have their machine completely rebuilt after it got corrupted somehow, and that includes our testing servers as well.

      All I can say is, thank god our production servers are out of our company's control. They haven't had any issues, but then again, they also don't have Sophos malware on them either.

    6. Re:This is why developers are not sysadmins by 1s44c · · Score: 3, Insightful

      Developers are the best sysadmins you can have, since they're actually somewhat competent.
      It's just that they've got better things to do and are paid more.

      Developers are normally careless sysadmins. Sysadmins are usually inept programmers. Someone that really can do both well is a great asset.

      Good sysadmins get paid about the same as good developers. At least that's my experience.

  3. Search engines by ArsenneLupin · · Score: 5, Informative
    On google, the following search string still turns up a goldmine...:

    site:github.com inurl:id_dsa

    Idiots...

    1. Re:Search engines by robmv · · Score: 4, Funny

      Stop, Google will shutdown search because of that

    2. Re:Search engines by tlhIngan · · Score: 4, Interesting

      Heck, Google disabled searching number ranges after some enterprising folks used them to harvest credit card numbers - doing searches for numbers between 4000000000000000 and 5999999999999999 which will get back lists of credit cards (Visa/MC) that Google indexed because someone put the list up.

  4. I just saw this, sort of by slashmydots · · Score: 5, Interesting

    I was cruising ebay yesterday and saw that one of the laptops had their windows license keys exposed in pictures in a readable format. I poked around some more and found that isn't terribly uncommon. Some people just don't think no matter what website it is.

  5. Re:Deserving by GameboyRMH · · Score: 5, Insightful

    Exactly, GitHub shouldn't disable a site feature to protect the stupid.

    --
    "When information is power, privacy is freedom" - Jah-Wren Ryel
  6. overreaction? by __aaltlg1547 · · Score: 3, Insightful

    Seems like the wrong response. Instead of killing search, why not just erase the keys files and lock out the accounts of the offending devs?

    1. Re:overreaction? by h4rr4r · · Score: 3, Insightful

      Because some of these might be test keys or place holders. If the key is not valid on any system and is just test data, it should not be a big deal to post publicly.

  7. Stupid people... by Lisias · · Score: 3, Insightful

    These stupid people should be had their accounts suspended.

    People should be accountable for their actions, and these idiots are potentially compromising third party data security!

    ICO didn't fined Sony for the information leak on that Anonymous attack? Why in hell GITHUB user's should be less accountable for things THEY ARE FSCKING COMMITING in their accounts?

    --
    Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
  8. Nothing has changed... by 140Mandak262Jamuna · · Score: 5, Funny
    Back in the days when I was the root (of all evil according my fellow grad students) of our lab, one of the constant problems was people blindly doing chmod 777 .* on the $home. They have .emacs or .profile or .cshrc that was customized ages ago by some grad student, and they want to share it with a new student. Somehow they stumbled on to "chmod 777 .*" as a solution to all their file sharing problems. Now this "magic command" was also being blindly passed around without worrying about security implications. Oh, yeah, they think they are clever and tape the login credentials to the underside of the keyboard and laugh at secretaries who tape it to their monitors.

    Looks like these grad students have all growned up and uploading it all to the cloud.

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
    1. Re:Nothing has changed... by WankersRevenge · · Score: 4, Funny

      Yeah ... I was "that guy". The first time I installed Linux in 2000, I was annoyed that I needed "permission" to write to a directory outside of my home directory. I was coming from a Windows world, after all.

      I solved this "problem" by chmod 777 the entire filesystem. Hah. Problem solved. Needless to say, I couldn't start the machine back up again. I'm guessing it killed itself from the shear embarrassment. After that, I decided it may be in my best interest to read the manual.

      I'll do that one of these days :)

    2. Re:Nothing has changed... by xaxa · · Score: 3, Interesting

      Someone in my class installed a game in the officially-public network share. He was writing an AI for it, for a project. Other students found it, and played it.

      It had taken a lot of hacking to get the game to run on Linux, and he was annoyed other students had played it without putting in that effort. So, he altered the 'start.sh' script to generate an ssh key, add the public part to the user's authorized_hosts file, and move the private key somewhere obscure.

      He then got bored with the AI project.

      Some time later, while helping in a tutorial, I was showing a student how to set up an SSH key. The authorized_keys file already contained about 20 entries. The AI guy was sitting at the next computer, and told me what he'd done (I knew him quite well, but he hadn't told me what he'd done until now). He found over 200 private keys in the obscure place. He deleted them, chown -R go-rwx'd the game, and we thought that was the end of it...

      About a year later, Debian had that OpenSSL bug. The sysadmins ran a script across everyone's authorized_keys file, and removed any entries from keys generated by Debian OpenSSL. The email ended (I still have it):

      By the way: some of you have FAR TOO MANY authorized_keys ENTRIES
        and we seriously recommend that you radically shrink these down.
        As I said, we recommend kerberos tickets or ssh-agent instead!

      ...so I don't think they knew how they got there.

  9. Not so many by Shimbo · · Score: 3, Insightful

    Hundreds of keys from a million accounts; less than one in a thousand developers screwed up. Call a doctor at once! Then ask him about outliers in large populations.

  10. A big mess to clean up by NightHwk1 · · Score: 4, Informative

    git rm id_rsa*; git commit -a -m "problem solved\!"

    Not quite. They're already out there. The keys are still in the revision history. People have forked and cloned it.

    Hopefully the developers who created these keys know that besides removing them from the repo, the keys can no longer be used. They must be removed from every .ssh/authorized_keys file, every service like Github that uses them for deploying code, etc.