Slashdot Mirror

← Back to Stories (view on slashdot.org)

Users With Weak SSH Keys Had Access To GitHub Repositories For Popular Projects

Posted by samzenpus on from the protect-ya-neck dept.

itwbennett writes: Earlier this year, researcher Ben Cox collected the public SSH (Secure Shell) keys of users with access to GitHub-hosted repositories by using one of the platform's features. After an analysis, he found that the corresponding private keys could be easily recovered for many of them. The potentially vulnerable repositories include those of music streaming service Spotify, the Russian Internet company Yandex, the U.K. government and the Django Web application framework. GitHub revoked the keys, but it's not clear if they were ever abused by attackers.

5 of 25 comments (clear)

  1. Vote with your feet by Anonymous Coward · · Score: 5, Funny

    That is it. I'm moving over to sourceforge!

    1. Re:Vote with your feet by Anonymous Coward · · Score: 2, Funny

      After you come back, you should get tested.

  2. If Only by OverlordQ · · Score: 4, Insightful

    > GitHub revoked the keys, but it's not clear if they were ever abused by attackers.

    If only GIt allowed a way to see what was changed.

    --
    Your hair look like poop, Bob! - Wanker.
    1. Re:If Only by Antique+Geekmeister · · Score: 3, Interesting

      Unfortunately, many git authors refuse to use signed tags for a variety of reasons. For a large scale example of this as a matter of corporate policy, review https://git.centos.org./ This is now the official public repository for Red Hat Enteprise Linux 7 public source code. I'm afraid that they adamantly refuse to use "tags" for publishing particular software versions of their content and instead rely on the word "import" in their git logs to indicate the released versions of source code.

      A great deal of similarly casual handling of git security is in use at github, at Sourceforge, and was in use at gitorious. Not all software authors are very careful about ensuring the security of their published code.

  3. User's fault? by CurryCamel · · Score: 2, Interesting

    TFA:

    the Debian developers and the security research community advised everyone who was possibly affected at the time to regenerate their keys.

    However, it seems that a lot of people didn't listen and those weak keys are still used today

    Didn't listen? How about that for a elitistic attitude! This is the main problem and cause for computer insecurities. I would give long odds that the number of people who both herad AND understood the warning, yet failed to take action can be counted with your fingers without even using base-2.

    We end-users need to be spoon-fed (force-fed) the security. The correct action here would have been for (e.g. Github) to revoke these sort of keys already back then. Because while it is unreasonable to expect all end-users to take action, it is reasonable to expect (e.g. Github) to have a security professional to be alert and make that descision for us.
    Well, better late than never, and slip-ups happen sometimes. Lets hope there wasn't too much damage.