GitHub has recently started revoking SSH keys that were deemed to be compromised or insecure. Systems engineer Ben Cartwright-Cox was the author of the research that uncovered the issues. InfoQ has spoken with him.
Cartwright-Cox leveraged a “little known feature of GitHub” that allows to look at the SSH public keys of other users. This is a great way to share SSH public keys, Cartwright-Cox says, but it will also allow anyone interested to easily collect everyone’s keys. Indeed, Cartwright-Cox himself scanned GitHub through its Events API to collect about 1,376,262 keys at the beginning of 2015 and then analysed that wealth of data.
The most important findings Cartwright-Cox gathered through his analysis are the following:
- Only 30% of users who had committed to a repo had not set up SSH keys for their accounts.
- RSA keys are by far the most used, accounting for 97.7% of all keys; the rest of keys where mostly DSA, and a low number of users had ECDSA keys.
- Nine keys had only either 256 or 512 bits, which have been long been shown factorable.
- Many keys were found to be vulnerable due to the May 2008 Debian OpenSSH bug, which made the system able to generate only one of 32k keys in a set, thus strongly reducing randomness. In this last group of keys, Cartwright-Cox found Spotify’s and Yandex’s public repos, Python Crypto libraries, Django, Python’s core, Couchbase, and others. According to Cartwright-Cox, all of those accounts should be assumed to be compromised given the “low barrier of entry”.
It took a few months for GitHub to take any actions after Cartwright-Cox’s disclosure. Finally they revoked the Debian keys on May, 5th and weak and low quality keys on June, 1st.
InfoQ has spoken to Ben Cartwright-Cox to learn more about this topic.
How bad were the findings of your audit overall? In the end only a very small number of users did effectively put their accounts at risk.
The major finding of the my investigation is that a lot of very large projects could have, or have been compromised by a very hard to detect and non obvious issue in the keys that the contributors were using. While the number of accounts that were affected, the amount of users that were are massively higher.
As far as I know, there are at least two companies that are investigating in the fallout of my post and depending on what they will find out we will know if someone ‘evil’ found this out before I did.
One of the learnings here is that security is hard to guarantee, and this fact makes it all the more important, as you say, that organizations provide some kind of protection to their users. Could you elaborate on this?
It’s great that GitHub actually did revoke small keys. Most companies would not care. The lesson from this is, just because a computer gives you a cryptographic key, it does not mean its strong against a number of trivial attacks.
Are you satisfied with GitHub’s response, in the end? How would you like companies and other organizations to get an active role in helping their users to get security right?
They could have been much faster that they were, and could have actually noted that the research I did was worth “award” ( even with just a mention, I don’t care about money) on their bug bounty page. Other than that. Their response has been excellent.
Cartwright-Cox also announced a follow-up to its original post to further review GitHub SSH keys quality.
