Auditing GitHub users’ SSH key quality

https://blog.benjojo.co.uk/post/auditing-github-users-keys

by benjojo12 • 11 years ago

490 177 11 years ago

blog.benjojo.co.uk

scrollaway• 11 years ago

How does one even go about getting a 256-bit key? You have to do it on purpose somehow, or it has to be seriously old, in which case you're likely aware somehow that that's a terrible idea.

Is there outdated ssh keygen software out there that still generates sub-768 keys?

benjojo126• 11 years ago

To be honest, I have no idea. I had hack about to get Go's crypto/rsa package to give me a key that size, I really would love to know what can make these keys

makomk• 11 years ago

256 bits is a perfectly respectable length for an ECDSA key, so I'm guessing people tried to generate those and accidentally created RSA keys instead.

xorcist• 11 years ago

No, ssh-keygen won't create that small RSA keys. It is a limitation that's been around since long before OpenSSH (although I believe it used to be 512, the limit now seems to be 768).

TazeTSchnitzel• 11 years ago

Perhaps someone is on an obscure platform whose only SSH key generator is subpar.

Or perhaps someone has a system that generates keys automatically, and it was poorly configured.

dfox• 11 years ago

I vaguely remember that 10 or 15 years ago I've seen obscure ssh client for relatively obscure platform that could not handle RSA keys that were longer than some X, with X being something like 640.

Even then, generating such key with OpenSSH was not something one could do by accident.

pdw• 11 years ago

And where do the odd numbers come from? 1023 bits? 799 bits??

benjojo126• 11 years ago

So this one is kinda fun.

IIRC PuTTYGen had a bug in it for a very long time that you would ask for a 1024 key, and it would subtract a bit off it. You can see the same with 2047 keys in the data that I will be publishing on the next post.

baby15• 11 years ago

Same kind of people who write 1338 instead of 1337, for the lulz

88e282102ae2e5b• 11 years ago

They may have been assuming that appropriate key lengths for AES would work for SSH keys as well.

Marcus316• 11 years ago

I'm pretty sure the first 256 bit key listed in his output is/was mine.

It was a key generated and used as a test (years ago). It has never been used to access my Github account. Also, my account is pretty bare as it is.

To be safe, though, I have now removed the key.

rocky1138• 11 years ago

I'm pretty sure the first 256 bit key listed in his output is/was mine.

Post the private key to prove it!

baby15• 11 years ago

Now you can also test several attacks on them, compare them to a larger database to see if you have common divisors, check for low primes, check for bad primes (fermat factorization)...

benjojo126• 11 years ago

Yup, this is what I will be trying next.

baby15• 11 years ago

Oh and check for low private keys as well, I did that before here's the code: http://cryptologie.net/article/265/small-rsa-private-key-pro...

LunaSea2• 11 years ago

It could be interesting to try to match those keys to the ones generated by Debian during the OpenSSH vulnerability [1] period.

[1] http://jblevins.org/log/ssh-vulnkey

ryan-c3• 11 years ago

I'd also suggest looking at the rsa public exponents. PuTTY and OpenSSH (at least used to) use their own values when generating keys, so you can somewhat reliably identify which keys were generated by these tools

martincmartin2• 11 years ago

It would be interesting to see, what's the public key that's used by the largest number of accounts? I wonder if some people, instead of generating their own, use a public/private pair they downloaded from the internet somewhere, not realizing the vulnerability.

facetube• 11 years ago

Do you have any (anonymized) stats for the largest key sizes you encountered? I ask as the owner of a comically-large key.

quux• 11 years ago

Kudos to Github for not charging him with "Unauthorized Access of a Computer"

jessaustin• 11 years ago

Given their customer base, that sort of response would have kicked off a shit-storm. ISTM that any "responsible disclosure" ought to at least rate a T-shirt. (If GH don't want to pony up the T-shirt, that's fine, but they can't send customer notifications before the researcher publishes.)

robzyb• 11 years ago

(If GH don't want to pony up the T-shirt, that's fine, but they can't send customer notifications before the researcher publishes.)

In my uneducated opinion, that seems like a really good way to judge whether something qualifies as worthy of a bug bounty etc.

benjojo126• 11 years ago

I'm not saying that I didnt get anything for it what so ever, The peer of mine did manage to send over some swag as a thanks, I now have http://i.imgur.com/d2f7mcD.png on my work desk :)

kardos4• 11 years ago

Sure, but as I understand it, he doesn't/didn't need to actually try it on github's servers. If he put the public keys in question into the authorized_keys list of a second account on his personal system, he can locally verify that the brute forced private key is correct. I think the wording agrees with this:

<snip> and then a few more minutes to transform those back into a SSH key that I could log into systems with.

dimino11• 11 years ago

To be wildly pedantic, GitHub wouldn't charge him with anything, the DoJ would, regardless of what GitHub does/doesn't do.

grkvlt• 11 years ago

List public keys for a user - Lists the verified public keys for a user. This is accessible by anyone.

Hardly 'kudos' for them; the API to list public keys is listed by GitHub as 'accessible by anyone' in the documentation, it would be difficult to construe what they did as 'unauthorized' because of that.

est• 11 years ago

that https://github.com/anybody.keys feature, how on earth did OP find this?

lucaspiller• 11 years ago

I've heard of it before, the same is available in their API too:

https://developer.github.com/v3/users/keys/#list-public-keys...

helper• 11 years ago

Its a documented feature [1].

[1] https://developer.github.com/v3/users/keys/

tyrel2• 11 years ago

Seeing a key with substring of "Tyr" as the username and that substring of my key matching scared me a bit.

If you want to check how many bits your key is, use

ssh-keygen -l -f ~/.ssh/your_key.pub

(It wasn't mine, while it is an older key, mine is larger than 768 thankfully)

Edit: look at timdorr's example for a better visual.

timdorr• 11 years ago

Most people will want to run this verbatim:

  ssh-keygen -l -f ~/.ssh/id_rsa.pub

You'll get an output like so:

  ⚡~ $ ssh-keygen -l -f ~/.ssh/id_rsa.pub
  2048 f6:2d:94:54:c0:96:18:64:24:fb:c2:ad:ed:6a:1d:68  timdorr@Pixelicious.local (RSA)

tyrel2• 11 years ago

True, this will be default if you don't namespace your keys and use ssh config files like I do, I should have just said that.

Killswitch• 11 years ago

    4096 63:f2:23:00:c9:0d:07:3b:6d:ad:4d:a9:98:32:f5:25  ***@*** (RSA)

Am I good?

_lce0• 11 years ago

how much safe are we, with a 2048 bits key?

is this something we should be upgrading (like to 4096) in the near future?

philo23• 11 years ago

There's probably a better way of doing it, but this should check all your public keys if you use more than one, assuming they're in ~/.ssh

  for file in $(ls ~/.ssh/*.pub); do ssh-keygen -lf $file; done

atombender• 11 years ago

If you use ssh-agent, you can do:

    ssh-add -l

to list all your registered keys.

finicky• 11 years ago

i had the same moment of panic and ended up removing old keys and regenerating my keys that are in use. i wish i'd seen this comment beforehand -_-

Someone1234• 11 years ago

Maybe GitHub themselves should just stop accepting keys of a certain length. For example <2048 RSA keys (and <256 ECDSA keys). They could also check against the Debian set.

As the article says, GitHub could be being proactive rather than reactive here. They don't "have" to, but they could.

benjojo126• 11 years ago

GitHub now, after reporting this to them do not allow keys below 1023 to be added, and all keys that had been smaller than that, have been removed and owners of those keys got a email like screenshot on the top of the post

Noelkd3• 11 years ago

According to a 2009 blog post[1]:

Thanks to our new servers, known bad keys[2] from Debian and Ubuntu are now blacklisted. We estimate that about 1000 keys in our database were impacted by this. If you get authentication errors using keys that worked a day ago, please double-check that they are not on our blacklist. If they are, you should ensure your software is updated and generate new keys. We’ve got a guide to help you out with this.

[1] https://github.com/blog/500-state-of-the-hub-rackspace-day-0

[2] https://github.com/blog/63-ssh-keys-generated-on-debian-ubun...

scintill7614• 11 years ago

Woah, this new article says a lot of weak-Debian keys were found. Does this mean Github had a regression in their blacklisting since 2009? Or maybe they didn't blacklist enough originally?

madsushi• 11 years ago

Rachel talked about Github and public keys a while ago (saw on HN): https://rachelbythebay.com/w/2013/04/07/ssh/

Noelkd3• 11 years ago

Comments here: https://news.ycombinator.com/item?id=5508235

rb12345• 11 years ago

It would be far more effective to add a "log in with Facebook/Twitter/GitHub" button and oAuth than mess with SSH keys, surely?

3pt141593• 11 years ago

This is a very grave error. If this caused damage to open source projects then I could see a class action suit against GitHub.

1. Duty of care - should never have accepted keys provably weak.

2. Poorly communicated that username.keys was available, thus many users may have thought their keys weren't at risk.

3. No countermeasures from crawlers mass collecting keys. (Not they they should even need to do this - they should just have done #1 in the first place!)

This isn't a game man, GitHub hosts a ton of the world's open source code and they're supposed to be experts in cryptography and security. Russian mobsters, NATO spooks, bitcoin drug cartels, and even high school script kiddies are all constantly trying shit and it impacts us all not just the people with weak keys. If python core gets backdoored I get backdoored, no matter how careful I am with the software I install.

baby15• 11 years ago

Instead of downvoting, let's educate people a bit more:

1. Picking a small key is all on the user. It's like choosing the single letter 'a' as a password. If you want to do so why not?

2. The key you give to github is a "public" key. It is made to be public so this should be irrelevant.

3. There is 'almost' no known countermeasures against mass crawls of public keys. Look at the recent attacks: https://blog.hboeck.de/archives/872-About-the-supposed-facto...

What they could do: check against databases of public keys to see if your key is weakened by such attacks.

3pt141593• 11 years ago

Edit:

In response to your #1:

Picking a password is all on the user too. But magically GitHub is competent enough to stop users from picking the password "ilovecake". Most users of GitHub are not security professionals. Just like most people opening a bank account are not bank vault security professionals.

Original:

They are downvoting me because they love / work at GitHub or don't understand how critical software security is. If you think about the physical life equivalent here (say a bank leaving keys out in the open for safe deposit boxes) there is no way to rationalize it. But all of a sudden it's our favorite social coding startup we can't actually call them out on a huge security fuck up. If this were Microsoft we'd be laughing.

Tharkun4• 11 years ago

I strongly disagree with #2. Your public key should NOT be public, especially without your explicit consent. Specifically because, at least theoretically, it could be used to derive your private key. From a parandoid point of view that's just Bad.

This is one of the reasons why should use different key pairs for different purposes.

jp_sc• 11 years ago

Nice try Sourceforge. ;) You should complain with those core commiters.

Phemist• 11 years ago

Especially the guy with commit access to PyCrypto should reconsider his position in the project..

Tharkun4• 11 years ago

At least Github were "kind" enough to strip the comments from the public keys they publish without permission. I would've been even more upset if they were leaking things like username@workdomain....

c225• 11 years ago

But the keys are public...

Dylan168072• 11 years ago

So is the writing on a postcard; doesn't mean you want it published.

Tharkun4• 11 years ago

That's my point. They shouldn't be. I never gave Github permission to publish my keys. The "public" part in the key is merely there to distinguish it from the "private"-part ("never share this with anyone"). It should signify "share this with people whose machine you want to access", not "share this with the whole world".

From a healthy paranoid point of view: you don't share your public key unless you have to. Sure, there are no known attacks on strong RSA keys today, but that doesn't mean there will never be. Why take that risk with, literally, thousands of keys and people's security? It's rude at the very least.

Of course, you should never use your Github keys for anything else, but that's beside the point entirely.

As for the comments: key comments are useful but often contain information that can identify a person (e-mail address, username@machine etc). Publishing that would have been even worse.

fensipens4• 11 years ago

I agree, this is rude and as far as I remember, it's not mentioned anywhere in the key upload interface.

It's equivalent to uploading someones PGP key to a keyserver without his or her permission.

uxcn2• 11 years ago

I hoped my key wasn't effectively public by using it with github, but I honestly tend to assume the worst whenever I use a service like it.

baby15• 11 years ago

from the public keys they publish without permission

Public Keys are supposed to be public. It's OK not to know that, but blaming Github for doing crypto right is not really clever...

If you don't want your public key to be traced back to you, generate a new pair just for github.

fensipens4• 11 years ago

blaming Github for doing crypto right

So github is doing crypto right by unnecessarily exposing data that is _only_ relevant to a) the user and b) his personal access to his repos?

By this logic, why not make crypto even better and add something like github.com/user.address, github.com/user.mail or github.com/user.phone?

nandhp• 11 years ago

I still use a 1024-bit DSA key I generated ~10 years ago. How bad is that? Should I replace it with a 2048-bit RSA key?

newman314• 11 years ago

Yes

baby15• 11 years ago

We go on to consider Diffie-Hellman with 768- and 1024-bit groups. A small number of fixed or standardized groups are in use by millions of TLS, SSH, and VPN servers. Perform- ing precomputations on a few of these groups would allow a passive eavesdropper to decrypt a large fraction of Internet traffic. In the 1024-bit case, we estimate that such com- putations are plausible given nation-state resources, and a close reading of published NSA leaks shows that the agency’s attacks on VPNs are consistent with having achieved such a break. We conclude that moving to stronger key exchange methods should be a priority for the Internet community.

From: https://weakdh.org/imperfect-forward-secrecy.pdf

floatboth• 11 years ago

210 | ssh-ed25519 AAAAC

Does this mean GitHub finally supports Ed25519?

mjevans• 11 years ago

As someone who's put an ed25519 key on github... I'm not actually sure (didn't verify). I also still have compatibility keys there, I merely installed it so that, opportunistically, it could be used when supported.

glass-• 11 years ago

I've been using an Ed25519 key on github for about 6 months now.

lcd047• 11 years ago

In the mean time, Bitbucket still doesn't accept ECDSA keys:

https://bitbucket.org/site/master/issue/4222/no-support-for-...

7ewis• 11 years ago

What is the easiest way to manage SSH keys?

I can't remember where half of mine have been saved. I should really revoke everything and start again, as I use it for accessing my VPS too.

How do you revoke all keys on Ubuntu and OS X?

semi-extrinsic• 11 years ago

There is no concept of revoking ssh keys, so you have to remove them from the ~/.ssh/authorized_keys file on every server you have access to, and delete the public keys at every service you've uploaded them to.

For a revoking mechanism to be possible you would need a trusted third party (like a certificate authority) to verify the keys for each and every connection you make.

shabble2• 11 years ago

For managing large infrastructure, it's possible with semi-recent openSSH (5.4+ I think?) to validate and revoke keys[1] by signing them with a different key which the server (or client) trusts.

[1] http://www.lorier.net/docs/ssh-ca

nodesocket• 11 years ago

I'd be interested in the script used to scrape the GitHub public key endpoint? I assume it just throttled back to stay under the GitHub API rate limit?

scintill7614• 11 years ago

Pitting two well-known security principles (or at least watered-down versions) against each other: "security by obscurity is evil" and "defense in depth". Which trumps here? Should the public keys be printed in every phone book, just because it says "public" in the name? Or should they be kept semi-secret, since publishing them could lead to them being factored offline?

akerl_2• 11 years ago

Defense in depth doesn't conflict with "security by obscurity is evil": Defense in depth is that I keep my private key secured with a passphrase, on an encrypted volume, and that I take measures to protect against applications having access to it unless they require it. It's the layer of physical security where I don't leave my laptop where it's easily accessed, and everything else that goes into securing a workstation.

Defense in depth recommends having multiple layers of security, such that a breach of a single layer doesn't constitute a full breach. There's no requirement (and in fact I'd argue there's no solid recommendation) for including obscurity as one or more of the layers.

kelnos4• 11 years ago

The parent may not have used the best terminology, but the point still stands: your "defense in depth" example utterly fails to protect your private key if your public key is widely-available and easily-factorable.

If I didn't have my public key on GitHub, it's unlikely that even that could fall into an attacker's hands. Not that I would rely on that assumption, but it would reduce my attack surface.

scintill7614• 11 years ago

What if, in 10 years, 1024-bit keys are factorable in <10 days on commodity hardware? I could call that a "breach of a single layer." If 1024-bit keys have been widely publicized, it turns into a "full breach", because the defenses weren't deep enough. If the keys had not been publicized, then the entire 1024-bit key space has to be iterated online in order to find weak keys.

Now, of course the user can take some responsibility for not upgrading their key in 10 years, etc.

I don't see why it's, like, some moral obligation to invite factoring attacks just because of the name of the key and knee-jerk hatred for "obscurity."

Put another way, it makes sense to avoid pure obscurity when adding it takes extra work. In this case, GitHub is going out of their way to add theoretical weakness, but apparently we must do it, because security bible!

scintill7614• 11 years ago

So, all the "it's called a public key for a reason!" people: when are you going to submit a patch for OpenSSH allowing unauthenticated users to query arbitrary users' public keys, and maybe a list of users while you're at it? You vehemently support one particular operator of an SSH server doing it, citing good security practice, so why not do it everywhere?

Edit: to be fair, there is the difference that GitHub has already added it and probably didn't have to write C code to do it. So maybe this feature should be requested for things like, say, cPanel, and users' $HOME/.ssh/authorized_keys should be world-readable by default. Still, maybe it's worth doing in OpenSSH so everyone can get the huge benefits of this currently only enjoyed by GitHub's users.

hugomarisco• 11 years ago

Good article. Very detailed and thoughtful!

Auditing GitHub users’ SSH key quality

Related Stories