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

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.

Comments

Vote with your feet

[Anonymous Coward]

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

Re:Vote with your feet

[Anonymous Coward]

After you come back, you should get tested.

VLC expired key

[Anonymous Coward]

can someone please inform the VLC developers of their expired signing key?

Here it is:
https://get.videolan.org/keys/...

While it will still sign new VLC releases, it is listed as expired when you import it into GPG.

My key is 1-bit

[Anonymous Coward]

I'll let you have two guesses what it is.

If Only

[OverlordQ]

> 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:If Only

[Anonymous Coward]

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!

Re:If Only

[lillgud]

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:If Only

[Richard_at_work]

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:If Only

[Anonymous Coward]

LOL. All the main contributors have offline caches of the tree, and git fetch tells you if there's a forced update, so they'd quickly figure out that something's up.

Unless you're seriously suggesting that there's a supercomputer somewhere that has succeeded in making a SHA256 hash-collision that includes a malicious custom change to a patch? And that some government really wasted several million CPU-years just to compromise a single project hosted on github?

Yeah, you can make an 128-bit MD5 collision in 2^64 attempts if you get to pick the hash due to the birthday "paradox", but there's basically zero chance of that attack working against SHA256: in this case the attacker does not get to choose the original hash, so the search space is 2^256 for brute force (not 2^128 for birthday attack).

p.s. Back when I said several million CPU-years, I was joking. We're really talking about heat death of the universe time frames here.

Re:If Only

[Anonymous Coward]

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!

But then everyone who's pulled the previous changes would have a conflict? That's why git, when it's all out there and shared, is so reliable. The backups are all the people who ever pulled at that commit or later.

Re:If Only

[Anonymous Coward]

You're clueless. To set the record straight, git uses SHA1. There were some discussion going on about changing to SHA256, but nothing real at the moment.

GPG-signed tags on the other hand ...

Re:If Only

[gl4ss]

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:If Only

[jeremyp]

Brilliant idea. I can sign my tags with my ssh key... ... oh, wait....

Re:If Only

[Antique Geekmeister]

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.

Re:If Only

[Arancaytar]

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:If Only

[allo]

gpg, not ssh ...

Re:If Only

[allo]

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:If Only

[DrVxD]

what if users had checked in credentials or other keys

Then they're idiots.

Users are attackers?

[Anonymous Coward]

So users are automatically attackers because of a companies bad implementation of security. Jesus the Internet is getting rough for the average guy these days.

At least it was incompetence

[Anonymous Coward]

...rather than malice.

https://8ch.net/sourcefraud/catalog.html

User's fault?

[CurryCamel]

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.

Re:User's fault?

[Anonymous Coward]

I get the feeling we find out about this sort of security lapse only when the NSA is done exploiting it.