Gentoo Linux Github Organization repo hack was down to a series of security mistakes

The team behind Gentoo Linux has revealed the reasons for the recent hack of its GitHub organization account. The short version: shoddy security.

It seems that the hackers were able to gain access to the GitHub organization account by using the password of one of the organization administrators. By the team's own admission, poor security meant that the password was easy to guess. As the Register points out, "only luck limited the damage", but the Gentoo Linux team is keen to let it be known that it has learned a lot from the incident.

See also:

• Gentoo Linux Github Organization hacked and repo code compromised
• Microsoft officially announces agreement to acquire GitHub in $7.5 billion deal
• Google releases open source 'GIF for CLI' terminal tool on GitHub

In an entry on the Gentoo Linux wiki, there is a fairly detailed breakdown of what happened, how it happened, and what is being done to prevent it from happening again. The wiki entry summarizes the hack attack as follows: "An unknown entity gained control of an admin account for the Gentoo GitHub Organization and removed all access to the organization (and its repositories) from Gentoo developers. They then proceeded to make various changes to content. Gentoo Developers & Infrastructure escalated to GitHub support and the Gentoo Organization was frozen by GitHub staff. Gentoo has regained control of the Gentoo GitHub Organization and has reverted the bad commits and defaced content".

So how did this unknown entity gain access? Quite easily:

The attacker gained access to a password of an organization administrator. Evidence collected suggests a password scheme where disclosure on one site made it easy to guess passwords for unrelated webpages.

A lack of two-factor authentication helped to make the hacker's work much easier, and it seems it was really little more than luck that meant the attack didn't have a much greater impact. The Gentoo Linux team explains, honestly, what went badly wrong:

• 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 that.
• 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.

It seems that the project has learned a lot from the incident and has put a series of measures in place to help avoid something similar from happening in the future. But by its own admission, the project got off lightly -- things could have been worse; much worse.

The attack was loud; removing all developers caused everyone to get emailed. Given the credential taken, it's likely a quieter attack would have provided a longer opportunity window.