Gentoo Hack Caused By Three Rookie Mistakes
The developers of Gentoo Linux have revealed how it was possible for its GitHub organization account to be hacked: someone deduced an admin’s password – and perhaps that admin ought not to have had access to the repos anyway.
The distro’s wiki has added a page describing the SNAFU. It describes the root cause of the cockup as follows:
Oops! Sounds like someone has a core password with predictable variations!
The wiki page also reveals that the project got lucky. “The attack was loud; removing all developers caused everyone to get emailed,” the wiki reveals. “Given the credential taken, its likely a quieter attack would have provided a longer opportunity window.”
Also helpful was that “Numerous Gentoo Developers have personal contacts at GitHub, and in the security industry and these contacts proved valuable throughout the incident response.”
But the project’s critical of itself for the following reasons:
- Initial communications were unclear and lacking detail in two areas.
- How can users verify their tree to be sure they had a clean copy?
- Clearer guidelines that even if users got bad copies of data with malicious commits, that the malicious commits would not execute.
- Communications had three avenues (www.gentoo.org, infra-status.gentoo.org, and email lists.) Later we added a wiki page (this page) and were inconsistent on where to get updates.
- GitHub failed to block access to the repositories via git, resulting in the malicious commits being externally accessible. Gentoo had to force-push over them as soon as this was discovered.
- Credential revocation procedures were incomplete.
- We did not have a backup copy of the Gentoo GitHub Organization detail.
- The systemd repo is not mirrored from Gentoo, but is stored directly on GitHub.
The project’s fix has a few elements. Two-factor authentication is now on by default in the project’s GitHub Organization and will eventually come to all users the project’s repos. A password policy that mandates password managers is planned. Also on the agenda is a review of who needs access to repos and cleanout of those who don’t, proper backups and an incident plan so that the project won’t need to rely on its luck if it’s popped again. ®
Sponsored: Minds Mastering Machines – Call for papers now open
READ MORE HERE