GitHub: Assume Your Account is Hacked, Company Tells Users Protected by Old SSH Keys

GitHub, the largest online code repository, has revoked an unknown number of cryptographic keys used to access user accounts, after a developer identified the keys contained severe flaws from seven years ago that could lead to password decryption.

The revoked keys, which are used to authorize specific users to log into the code repository accounts belonged to companies including Spotify, Yandex and select UK government developers. Github reported the company generated the keys using a buggy pseduo random number generator originally found in the Debian distribution of the Linux operating system.

According to the developer who identified Github’s keys, the company used the flawed generator for a 20-month span from 2006 to 2008, where the generated pool of numbers was so small it made the keys extremely easy to crack.

Seven years later, after the company patched the Debian flaw they did not revoke old keys and generate new ones, as the Debian developers had initially recommended. Ben Cartwright-Cox, a London-based developer, identified Github was still utilizing a number of insecure keys, allowing users to gain access to the secure shell (SSH) to access their accounts in the system.

“If you have just/as of late gotten an email about your keys being revoked, this is because of me, and if you have, you should really go through and make sure that no one has done anything terrible to you, since you have opened yourself to people doing very mean things to you for what is most likely a very long time,” Cartwright-Cox wrote in a blog post explaining GitHub’s mistake published Monday. “It would be safe to assume that due to the low barrier of entry for this, that the users that have bad keys in their accounts should be assumed to be compromised and anything that allowed that key entry may have been hit by an attacker.”

Cartwright-Cox told ArsTechnica that he identified 94 keys on GitHub had contained bits from the vulnerable Debian-based system. After reporting his findings to GitHub in March, he later found the actual number of affected users spanned much farther. GitHub began revoking the vulnerable keys as early as last month, and is continuing to contact affected users.

Another UK-based developer who investigated Github said he found nine SSH keys that contained a a stunningly insufficient number of bits. Two of the nine had only 256 bits, allowing him the possibility to factor them and clone the private SSH key in less than an hours time. The remaining seven contained as little as 512 bits.

During the time the Debian flaw was active, the pool of bits available on generated OpenSSH keys was so limited that only 32,767 possible outcomes were possible for a given architecture, key size and key type each time. Cartwright-Cox said hackers could have used the same methods listed to find weak keys and abuse them to gain unauthorized access into users accounts. Leading to many big name companies repositories becoming compromised.

Cartwright-Cox said the attack would go far more smoothly if the attacker obtained a list of insecure SSH keys generated by the Debian system. Speaking with Ars, he elaborated:

“So the breakdown of how this could have been done is the following:

Grab the bad key list. It contains the public and private parts of all the SSH keys that would have been made if the user had a version of OpenSSH that had Debian RNG bug, then get each private key on the list, and try to log into GitHub’s ssh with them. Depending on what key you succeed with it will tell you what user name it matches up with, in the example I provided since my key is loaded it tells me ‘Hi benjojo! You’ve successfully authenticated, but GitHub does not provide shell access.’ but if I was to try with a weak key that matched up with another user it would say ‘Hi {user}! You’ve successfully authenticated, but GitHub does not provide shell access.’ and then I know what user I can compromise with that.”

Technically speaking, attackers don’t even need the private key to see if the public facing domains accept authentication from a user, chief research officer at Rapid7, HD Moore, said.

Debian developers introduced the random number generator flaw in late 2006, when the developers had removed two lines of critical code in the OpenSSL code base, attempting to fix warnings a number of users had been reporting at the time. When the two lines were removed, it nearly wiped out all of the entropy the OpenSSL framework relied on for its random number generating engine. The critical flaw went unnoticed for a spam of 20 months, and by that time, the damage had been done, as hundreds of sites had generated cryptographic keys from the flawed distribution.

The path to the patch the flaw was brutal as the initial patch was only the beginning of mitigating the issue. To fully protect yourself and your users, any keys generated during the 20-month span had to be re-generated using the updated Debian distribution. Github remaining vulnerable to this flaw some eight years later shows you the extent the Debian flaw had on companies at the time.