Assume your GitHub account is hacked, users with weak crypto keys told

[socket]

GitHub has revoked an unknown number of cryptographic keys used to access accounts after a developer found they contained a catastrophic weakness that came to light some seven years ago.

The keys, which allow authorized users to log into public repository accounts belonging to the likes of Spotify, Yandex, and UK government developers, were generated using a buggy pseudo random number generator originally contained in the Debian distribution of Linux. During a 20-month span from 2006 to 2008, the pool of numbers available was so small that it made cracking the secret keys trivial. Almost seven years after Debian maintainers patched the bug and implored users to revoke old keys and regenerate new ones, London-based developer Ben Cartwright-Cox said he discovered the weakness still resided in a statistically significant number of keys used to gain secure shell (SSH) access to GitHub accounts.

"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 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 Ars that he found about 94 keys on GitHub that contained the Debian-derived weakness. He said that after he reported his finding to GitHub officials in March he learned the actual number of site users was much higher. GitHub revoked the keys early last month, he said. GitHub officials didn't respond to a request to comment.

Separately, the UK developer said he found nine GitHub SSH keys that contained woefully insufficient numbers of bits. Two of them had only 256 bits, making it possible for him to factor them and clone the private key in less than an hour. The remaining seven had only have 512 bits.

During the time the Debian bug was active, the pool of bits available when generating OpenSSH keys was so limited that there were only 32,767 possible outcomes for a given architecture, key size, and key type. Cartwright-Cox said attackers could have used the same methods he employed to find weak keys and then used several techniques to gain unauthorized access to the accounts the keys protected. The task would have been aided by obtaining the list of insecure Debian SSH keys off one or more public sites, such as this one. In an e-mail, he elaborated:

If I wanted to be more noisy I could have just done what I said [in the blog post] and looped though the keys, that may or may not have set off alarms at Github itself (I'd give it a 25% chance that it would).

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, attackers don't even need the private key to see if a site accepts authentication from a user, HD Moore, chief research officer at Rapid7 and co-founder of the Metasploit hacking framework, told Ars. Just the public key and this Metasploit module will do. "This trick can also be used to see what internet-facing servers allow logins from what public keys, even if the private key is not available, which is a neat reconnaissance/opsec technique," Moore said.

The randomness bug was introduced in late 2006, when Debian maintainers removed two lines of code in the OpenSSL code base in an attempt to fix warnings received by some users. In the process, the maintainers wiped out almost all of the entropy that OpenSSL relied on for its randomness engine. The epic mistake, which eventually migrated to the Ubuntu distribution of Linux as well, wasn't diagnosed for 20 months, and by that time an untold number of cryptographic keys had been generated.

The bug was unusual in that installing a patch was only the beginning of the healing process. To fully recover, users had to revoke any keys made during that 20-month period and generate new ones using the updated OS. The discovery that GitHub users continued to rely on these hopelessly weak keys eight years after they came to light is testament to just how monumental the Debian debacle was and how hard it is for users to mop up after the mess it created.

Source