Ben Cox, engineer at CloudFlare revealed that the official Github repositories of the UK Government, Spotify, and Python were accessed by using legitimate SSH keys. It seems that the keys were compromised by exploiting a flaw in the Debian OpenSSL random number generator seed, which was discovered and fixed in May 2008.
This exploitation of the flaw reduces the effort necessary to conduct a brute-force attack due to the significant reduction of the key space.
“In May 2008, a bug was discovered in the Debian OpenSSL package which affected the seeding of the random number generator (RNG) used to generate keys. Any SSH keys generated by affected systems should be considered compromised.” wrote Jason Blevins in a blog post.
Cox explains that the likely compromised keys have been revoked this month, they were managed to access high profile repositories after threat actors have scraped nearly 1.4 million SSH keys from Github. The impact could be devastating because according to Cox about two thirds of Github accounts utilize SSH keys.
“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. A little known feature of GitHub is the ability to look at the public SSH keys that other users have set to be authorised on their account (for example https://github.com/torvalds.keys) This is a great debugging feature and in addition a great way to share SSH public keys (for example when you are giving someone an user account on a server of yours, and you trust GitHub not to tamper with the contents.)” reported Github. “However one of the other side effects of this is that it means that everyone can see your public keys, and if someone cares enough, collect a massive database of everyone’s SSH keys”
Soon Cox realized that he was in possession of a public key database of most users on GitHub, by using the g0tmi1k’s set of keys to compare it against the content of his database he discovered an amazing number of users who are using compromised keys. According to the engineer there is the concrete risk that ill-intentioned could discover the vulnerable keys and brute force them.
“I used g0tmi1k’s set of keys to compare against what I had in my database, and found a very large amount of users who are still using vulnerable keys, and even worse, have commit access to some really large and wide projects,” said Cox. “The most scary part of this is that anyone could have just looped through all of these keys just trying to SSH into GitHub to see the banner it gives.” “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.”
A threat actor could exploit the access to popular projects to compromise the repositories and serve malware and other malicious codes. Cox provided a list of affected projects which includes:
Despite Github admitted the risks, it explained that it is a user security issue and it could do nothing to mitigate it, at same time Cox explains Github should do much more to block threat actors.
(Security Affairs – SSH, Github)
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.