Users With Weak SSH Keys Had Access To GitHub Repositories For Popular Projects 25
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.
Vote with your feet (Score:5, Funny)
That is it. I'm moving over to sourceforge!
Re: (Score:2, Funny)
After you come back, you should get tested.
VLC expired key (Score:1)
can someone please inform the VLC developers of their expired signing key?
Here it is:
https://get.videolan.org/keys/... [videolan.org]
While it will still sign new VLC releases, it is listed as expired when you import it into GPG.
If Only (Score:5, 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.
Re: (Score:1)
Well, it actually doesn't, at least not reliably. With the ability to retroactively alter history, you can never be 100% sure that someone didn't sneak a change into the repository without reviewing every line of every diff. Have fun!
Yes it does. It's called signed tags.
Re: (Score:2)
Brilliant idea. I can sign my tags with my ssh key... ... oh, wait....
Re: (Score:2)
gpg, not ssh ...
Re:If Only (Score:4, 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./ [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.
Re: (Score:2)
On the other hand, you do not need signed tags to sign git. YOU can check it out today and add a signed tag. Now you can check everyday, if the new commits are based on your signed version.
Re: (Score:2)
wouldn't matter. there would already be 1000's of downloads of the infected code getting deployed.
you see, these companies use git as distribution method for their sdks.
that same reason is why a commercial company like spotify or whoever would have stuff on github.
Re: (Score:2)
Well, it actually doesn't, at least not reliably. With the ability to retroactively alter history, you can never be 100% sure that someone didn't sneak a change into the repository without reviewing every line of every diff. Have fun!
You can rewrite history, but it will break compatibility with any forks or mirrors of the repository - and for popular github projects, there are hundreds or thousands of those. No way to alter commits that have already been published without making it very obvious.
Re: (Score:2)
Its not just a case of if stuff was changed - what if users had checked in credentials or other keys into private repositories on GitHub? A git clone doesn't show up in a repositories logs, so you would never know that your credentials or keys had been compromised, potentially allowing attackers further access to your infrastructure.
Yes, we all know that credentials and keys should not be checked into source control, but we all know that it happens on a frequent basis, even if accidentally done.
Re: (Score:2)
what if users had checked in credentials or other keys
Then they're idiots.
User's fault? (Score:3, 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.