Protect repositories on github against malicious commits
- Transfer
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.
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 jeopardize confidential repositories, and the admin repository sees nothing. The best he can do is notice the malicious commit after the fact. Neither GitHub nor Git can be configured to prevent or designate such kind of malicious commits. Only external monitoring.
The following recommendations are taken from our security system , only for this article the specific features of Mozilla have been removed. As far as possible, we borrow the best practices of the Internet, use the functions of GitHub and try not to make life too complicated for developers.
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
Now with locally cached data, you can generate any reports. For example, one report shows compliance with the above recommendations:
As we see, that only
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 .
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 jeopardize confidential repositories, and the admin repository sees nothing. The best he can do is notice the malicious commit after the fact. Neither GitHub nor Git can be configured to prevent or designate such kind of malicious commits. Only external monitoring.
Implementation
The following recommendations are taken from our security system , only for this article the specific features of Mozilla have been removed. As far as possible, we borrow the best practices of the Internet, use the functions of GitHub 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 with pre-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,FalseAs we see, that only
octo_org/react-starterincluded protection against forced pushing 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 .