There is another data breach in the news. In a pattern we’ve seen many times before, AWS credentials were committed to a private GitHub repository, which was then accessed by an attacker due to lax controls around GitHub access.
What happened
As part of a hackathon, in April 2018, an employee was granted access to the company’s GitHub organization. According to the FTC’s complaint the unnamed executive’s personal GitHub account had a 7-character password and did not have MFA. Neither MFA nor SSO were required to access the organization. Two years later, that GitHub account was compromised via a credential stuffing attack using credentials from an unrelated consumer breach.
Using the executive’s GitHub account, an unknown actor cloned a repository containing AWS credentials. Using the credentials, the attacker modified security group settings allowing the attacker direct access to an AWS RDS database with customer data. The attacker then exfiltrated 2.5 million consumer records.
This post isn’t intended to pick on Drizly. Since the FTC issued its final order, at least two more GitHub incidents hit the press involving Dropbox and AstraZeneca. Additionally, GitHub issued its own advisory around a phishing campaign impersonating CircleCI.
GitHub Security is hard
Proper GitHub security is hard. GitHub started as a consumer and open source platform, but its popularity and superior technical capabilities brought it to the attention of enterprise software development shops. Enterprise governance capabilities were not baked into the platform at inception. What capabilities that do exist were bolted on due to customer demand.
GitHub’s primary tenancy boundary is the Organization. Inside an organization there can be multiple git repositories.
Unlike many SaaS platforms, GitHub identities belong to the individual, not their employer. This means an employee can take their GitHub identity from job to job. It is incumbent on the organizational owner to manage who has access to their repositories, and to revoke access when the individual is no longer affiliated with the organization, or no longer has a business need for access.
Because GitHub identities belong to the individual and not the employer, you as an organizational owner have limited abilities:
- You do not have access to the email addresses of the individuals who are members of your organization.
- You cannot force password complexity or rotation policies on the users in your organization.
- You cannot audit or manage the personal access tokens users in your organization create.
- You cannot control what email address GitHub notifications are sent to. Notifications about your organization’s commits and pull requests can be sent to the user’s personal email address.
For a cost ($252 a year per user), organizations can upgrade to the enterprise tier. With Enterprise Cloud organizations can:
- Use Enterprise Managed Users - distinct identities owned by the enterprise, not the end user.
- View the email address of the personal accounts who are members of the organization.
- Implement Single Sign On, which requires personal GitHub accounts to also authenticate to the corporate identity provider before being granted access to resources in the enterprise’s GitHub organization.
- For an additional cost on top of the enterprise tier, you can get GitHub Advanced Security, which will also do secret scanning of private repositories.
For companies in the security 99% that can’t afford the enterprise tier, what can you do to govern your use of GitHub?
Some general best practices are:
- Set the Base permissions for all users to No Permission. Members will have to be explicitly granted permission to repositories.
- Enable MFA for the organization
- Prevent users from changing the visibility of repositories. This will prevent users from making a private repository public.
- Disable private forking of repositories.
- Implement pre-commit secrets scanning
- Audit who has access to your organization, and manage what repositories they can access.
Three FREE things you can do to improve your GitHub Security
The GitHub Compliance Mod for Steampipe can help identify some of these issues, even if you don’t have enterprise licensing. Note: you need to be an organization owner for most of these queries to work.
Make sure you’re running the latest version of the GitHub Plugin (version 0.24.0):
steampipe plugin update github
Configure Steampipe with your GitHub Credentials, and download the compliance mod with these commands:
git clone https://github.com/turbot/steampipe-mod-github-compliance.gitcd steampipe-mod-github-compliance
Audit the users in your organization and enable MFA
When you enable MFA, all the members who do not have MFA enabled are automatically kicked out of your organization. If you are an owner of a large organization, you can get a list of the members who will be potentially impacted by running:
steampipe check control.organization_all_members_enable_mfa+ All Members of the Organization have MFA enabled .................... 4 / 128 [==========]|ALARM: jcf-goat does not have MFA enabled .................................. fluent-cattleALARM: jcf-goat does not have MFA enabled .................................... fooli-mediaALARM: jcf-goat does not have MFA enabled ...................................... hardy-cubOK : Subhajit97 has MFA enabled ............................................ fooli-mediaOK : bigdatasourav has MFA enabled ......................................... fooli-mediaOK : jchrisfarris has MFA enabled .......................................... fooli-mediaOK : dboeke has MFA enabled .............................................. fluent-cattleOK : jchrisfarris has MFA enabled ........................................ fluent-cattleOK : luisffc has MFA enabled ............................................. fluent-cattleOK : rajlearner17 has MFA enabled ........................................ fluent-cattleOK : sdsubhajitdas has MFA enabled ....................................... fluent-cattle
You will need to notify the users that do not have MFA enabled they must add a 2nd-factor to their account before you enable MFA for the organization.
Ensure the base permissions are set to none
The principle of least privilege suggests that not everyone in your organization needs access to all repositories in your organization. Ensuring that everyone doesn’t have access to everything (“base permission is none”) could have prevented the Drizly incident.
steampipe check control.organization_base_permissions_none
steampipe check control.organization_base_permissions_none+ Organization base permissions should be set to None ................... 4 / 8 [==========]|ALARM: hardy-cub base permission is read. ...................................... hardy-cubALARM: fluent-cattle base permission is read. .............................. fluent-cattleINFO : Turbot base permission unknown, manual verification required. .............. turbotOK : Fooli Media base permission is none. .................................. fooli-mediaSummaryOK .......................................................................... 1 [== ]SKIP ........................................................................ 0 [ ]INFO ........................................................................ 3 [==== ]ALARM ....................................................................... 4 [===== ]ERROR ....................................................................... 0 [ ]TOTAL ................................................................... 4 / 8 [==========]
Where you see "base permission unknown, manual verification required."
, you are not an organization owner and don’t have permission to the GitHub API. You can set the base permissions via the GitHub Console.
Run the best practices check
The CIS Software Supply Chain Security Guide is a high-level guide for source code security. The Steampipe GitHub Compliance Mod interprets some of those requirements for GitHub. For example, by downloading the commit history for all the repositories in your organization, the mod can detect which users are inactive in a repository and highlight those users for removal.
steampipe check benchmark.cis_supply_chain_v100_1_3 --snapshot --snapshot-title "GitHub Organizations Access Report"
Conclusion
The techniques we've shown here hopefully give you a better idea how you can affordably manage the security of your GitHub organizations, but everyone's situation is unique and you may find a solution that works better for you. If so, please let us know: we love to learn from our community!