Audit of GitHub SSH Keys Finds Many Still Vulnerable to Old Debian Bug

An audit of the SSH keys associated with more than a million GitHub accounts shows that some users have weak, easily factorable keys and many more are using keys that are still vulnerable to the Debian OpenSSL bug disclosed seven years ago.

An audit of the SSH keys associated with more than a million GitHub accounts shows that some users have weak, easily factorable keys and many more are using keys that are still vulnerable to the Debian OpenSSL bug disclosed seven years ago.

The public SSH keys that users associate with their GitHub account are visible to other users, a feature that enables users to share those keys with others. Last December researcher Ben Cox decided to collect as many of those keys as he could and see what he could find out about them. He began the project on Dec. 27 and by Jan. 9 he had collected more than 1.3 million SSH keys.

“I took a stab at this in 2013 but found that too many people didn’t use GitHub in SSH mode and thus had no keys set. This time however (with a new program that used the events api) I found that the majority of active users had some SSH keys in there,” Cox said in a blog post detailing the project.

After collecting the keys, Cox began analyzing them. One of the things he looked at was the strength of the key, and he discovered that seven of the keys in his set were just 512 bits, and two others were 256 bits. Those key lengths are short enough to be in the range of factorization on many modern machines.

“512 bit keys have been known to be factorable in less than 3 days. The main example of this is the Texas Instruments calculator firmware signing key that was broken, allowing the modding community to upload any firmware that they wanted,” Cox said.

“I tried on my own to make a 256 bit key and factor it, and the process took less than 25 minutes from having the public SSH key to the factoring of primes (on a subpar processer by today’s standards, and then a few more minutes to transform those back into a SSH key that I could log into systems with. This risk isn’t only real if someone had gathered together top of the line mathematicians or supercomputers worth of power, the 256 bit key I factored was factored on a i5-2400 in 25 mins.”

The bigger issue, however, is that Cox found what he calls a “very large amount” of SSH keys in the set that were vulnerable to the Debian OpenSSL bug from 2008. That vulnerability existed in certain versions of Debian and resulted from the fact that the OpenSSL random number generator included in those versions was predictable. That means that cryptographic keys generated with vulnerable versions could be guessable. The bug affected SSH keys, VPN keys, and DNSSEC keys, among others.

Cox compared the list of keys he had gleaned from GitHub to a list of keys affected by the Debian flaw and found that some of the accounts using vulnerable keys had access to some large and sensitive GitHub repositories. Some of those repositories include Yandex, the Russian search provider, Spotify, the cryptographic libraries for Python, and Python’s core.

Cox disclosed the problem to GitHub in early March and the vulnerable keys were revoked on May 5. The other weak and low-quality keys he discovered were revoked on June 1.

Suggested articles