Protection of repositories on GitHub from malicious commits
Mozilla tries to protect its repositories on GitHub from malicious changes. As shown by the recent incident with Gentoo , such attacks are real.
https://t.co/Mxtcxki9Ce
Today 28 June at approximately 20:20 UTC unknown individuals have gained control of the Github Gentoo organization, and modified the content of repositories as well as pages there. More see link.
- Gentoo Linux (@ gentoo) June 2? 2018
Initially Mozilla used GitHub as a spare hosting. Like Gentoo, the original repositories were stored on its own infrastructure. And although most of the Firefox code is still distributed from its own infrastructure, many projects exist only on GitHub. Some are just experiments, and others are used in production (for example, , Firefox Accounts ). Such "sensitive" repositories need to be protected from malicious changes, while not complicating commits for normal people.
some tools for the audit. Such protection almost does not interfere with normal working processes in GitHub.
We are here considering the risk of hacking the GitHub account through the unique mechanisms of this site. As shown by the case of Gentoo and other incidents, in the case of hacking, all code that is accessed by the user is endangered.
GitHub is a wonderful ecosystem with many extensions or "applications" to simplify certain workflows. Applications receive permission from the user to perform actions on his behalf. They can request permission, including changing or adding additional accounts. GitHub explicitly shows these requests: the user must approve them through 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.
Excess permissions expose the repository with confidential information, while the administrator of the repository does not see anything. The best thing that he can do is to notice the post-factum malicious commit. Neither GitHub nor Git can be configured to prevent or denote this kind of malicious commits. Only external monitoring.
The following recommendations are taken from our security system , only for this article are the specific features of Mozilla removed. As much as possible, we borrow the best Internet practices, use the functions of GitHub and try not to complicate the lives of developers.
Mandatory 2FA for all employees.
To all or even users with elevated permissions:
Provide a contact (e-mail, IM) to the organization or administrator (GitHub allows you to hide contact information for confidentiality).
Be sure to inform the organization or administrator about a possible compromise of your account (for example, about laptop theft).
Important repositories should be placed only in the organization that follows the recommendations given above.
Identify and customize the production branches:
Prohibition of forced push.
Permission to commits to only a small number of users.
Apply these restrictions also to admins and owners.
Sign all commits in advance with known GPG keys.
Deplays, releases and other events worthy of audit should be marked with a tag signed in advance with a known key of GPG.
All releases and releases must be released only after the audit of all signed commits and tags for the correct keys.
The implementation of these protection measures involves certain costs, especially in connection with the signature of the commits. We have developed tools for auditing configurations and plan to release tools for audit commits. All of them lie in our repository .
Here is an example of an audit. First we get a local copy of the data for the organization
Now with any locally cached data, you can generate any reports. For example, one report shows compliance with the above recommendations:
As you can see, only
We are still implementing these recommendations and are learning along the way. If you think that our recommendations on the safety of repositories help you, help to simplify implementation. Share your experience at page of tips or open the ticket in the repository GitHub-Audit .
https://t.co/Mxtcxki9Ce
Today 28 June at approximately 20:20 UTC unknown individuals have gained control of the Github Gentoo organization, and modified the content of repositories as well as pages there. More see link.
- Gentoo Linux (@ gentoo) June 2? 2018
Initially Mozilla used GitHub as a spare hosting. Like Gentoo, the original repositories were stored on its own infrastructure. And although most of the Firefox code is still distributed from its own infrastructure, many projects exist only on GitHub. Some are just experiments, and others are used in production (for example, , Firefox Accounts ). Such "sensitive" repositories need to be protected from malicious changes, while not complicating commits for normal people.
some tools for the audit. Such protection almost does not interfere with normal working processes in GitHub.
We are here considering the risk of hacking the GitHub account through the unique mechanisms of this site. As shown by the case of Gentoo and other incidents, in the case of hacking, all code that is accessed by the user is endangered.
The crux of the problem is
GitHub is a wonderful ecosystem with many extensions or "applications" to simplify certain workflows. Applications receive permission from the user to perform actions on his behalf. They can request permission, including changing or adding additional accounts. GitHub explicitly shows these requests: the user must approve them through 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.
Excess permissions expose the repository with confidential information, while the administrator of the repository does not see anything. The best thing that he can do is to notice the post-factum malicious commit. Neither GitHub nor Git can be configured to prevent or denote this kind of malicious commits. Only external monitoring.
Implementation of
The following recommendations are taken from our security system , only for this article are the specific features of Mozilla removed. As much as possible, we borrow the best Internet practices, use the functions of GitHub and try not to complicate the lives of developers.
Recommendations for organizations
Mandatory 2FA for all employees.
To all or even users with elevated permissions:
Provide a contact (e-mail, IM) to the organization or administrator (GitHub allows you to hide contact information for confidentiality).
Be sure to inform the organization or administrator about a possible compromise of your account (for example, about laptop theft).
Recommendations for repositories
Important repositories should be placed only in the organization that follows the recommendations given above.
Identify and customize the production branches:
Prohibition of forced push.
Permission to commits to only a small number of users.
Apply these restrictions also to admins and owners.
Sign all commits in advance with known GPG keys.
Recommendations for the workflow
Deplays, releases and other events worthy of audit should be marked with a tag signed in advance with a known key of GPG.
All releases and releases must be released only after the audit of all signed commits and tags for the correct keys.
The implementation of these protection measures involves certain costs, especially in connection with the signature of the commits. We have developed tools for auditing configurations and plan to release tools for audit commits. All of them lie 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 prepared for each repository: $ ./get_branch_protections.py octo_org
2018-07-???: 52: 4?584 INFO: Running as ms_octo_cat
2018-07-???: 52: 4?854 INFO: Gathering branch protection data. (calls remaining 4992).
2018-07-???: 52: 4?117 INFO: Starting on org octo_org. (calls remaining 4992).
2018-07-???: 52: 5?116 INFO: Finished collection branch protection data (call remaining 4947). Now with any 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 included protection from forced push on the production line. The result is given in the CSV format to easily insert into the spreadsheet.How can you help
We are still implementing these recommendations and are learning along the way. If you think that our recommendations on the safety of repositories help you, help to simplify implementation. Share your experience at page of tips or open the ticket in the repository GitHub-Audit .
