Mozilla tries to protect its GitHub repositories from malicious changes. As the recent incident with Gentoo has shown, such attacks are real.


Mozilla originally used GitHub as a backup hosting service. Like Gentoo, the original repositories were stored on their own infrastructure. And although most of the Firefox code is still distributed from its own infrastructure, many projects only exist on GitHub. Some are just experiments, while others are used in production (for example, Firefox Accounts ). Such “sensitive” repositories need to be protected from malicious edits without complicating commits for normal people.

Here are the real measures against the spread (or deployment) of the code from the compromised repository. We share experiences and some tools for auditing. Such protection almost does not interfere with normal workflows in GitHub.

We are here considering the risk of hacking a GitHub account through the unique mechanisms of this site. As the Gentoo case and other incidents have shown, in the case of a hack, all of the code that the user has access to is compromised.
')

The essence of the problem

GitHub is a great ecosystem with many extensions or “applications” to simplify certain workflows. Applications receive permission from the user to perform actions on their behalf. They may request permissions, including modifying or adding additional accounts. GitHub clearly shows these requests: the user must approve them via the web interface, but not everyone is familiar with the consequences. Many do not understand that permission to access the personal repository gives the same access to any repository on GitHub on behalf of the user.

Unnecessary permissions compromise confidential information repositories, and the admin repository sees nothing. The best thing he can do is notice a malicious commit after the fact. Neither GitHub nor Git can be configured to prevent or flag such kind of malicious commits. Only external monitoring.

Implementation

The following recommendations are taken from our security system , only for this article, specific Mozilla features have been removed. As far as possible, we borrow the best practices of the Internet, use the GitHub functions and try not to make life too complicated for developers.

Recommendations for organizations

• Mandatory 2FA for all employees.
• To all or at least users with elevated permissions:
  
  • Provide a contact (email, IM) to the organization or admin (GitHub allows you to hide contact information for confidentiality).
  • Be sure to inform the organization or admin about a possible compromise of your account (for example, about the theft of a laptop).

Repository recommendations

• Important repositories should be located only in the organization that follows the recommendations above.
• Define and set up production branches:
  
  • Ban forced pushing.
  • Permission to commit only a small number of users.
  • Apply these restrictions also for admins and owners.
  • Sign all commits in advance with known GPG keys.

Workflow Recommendations

• Deployments, releases and other events that are worthy of an audit should be marked with a tag, signed with a previously known GPG key.
• All deployments and releases should be released only after an audit of all signed commits and tags for the correct keys.

The implementation of these protection measures incurs certain costs, especially in connection with the signing of commits. We have developed tools for auditing configurations and are planning to release tools for auditing commits. All of them are in our repository .



Here is an example of an audit. First we get a local copy of the data for the organization octo_org , and then a report is made for each repository:

 $ ./get_branch_protections.py octo_org 2018-07-06 13:52:40,584 INFO: Running as ms_octo_cat 2018-07-06 13:52:40,854 INFO: Gathering branch protection data. (calls remaining 4992). 2018-07-06 13:52:41,117 INFO: Starting on org octo_org. (calls remaining 4992). 2018-07-06 13:52:59,116 INFO: Finished gathering branch protection data (calls remaining 4947). 

Now with locally cached data, you can generate any reports. For example, one report shows compliance with the above recommendations:

 $ ./report_branch_status.py --header octo_org.db.json name,protected,restricted,enforcement,signed,team_used octo_org/react-starter,True,False,False,False,False octo_org/node-starter,False,False,False,False,False 

As you can see, only octo_org/react-starter turned on protection from forced push on the production branch. The result is given in CSV format to easily insert into the spreadsheet.

How can you help

We are still implementing these recommendations and learning along the way. If you think that our recommendations on repository security are right for you, help simplify implementation. Share your experience on the tips page or open a ticket in the GitHub-Audit repository.