In a recent attack, Twitch had 6,000 internal git repositories and 3,000,000 documents – containing 6,600 secrets and over 150 API keys across services like Twilio, Google, and Stripe – exposed on 4chan. This leak represents yet another instance of a recurring problem — excessive permissions to Source Code Management. In this post we discuss the best practices to avoid source code leaks.
The publication about the Twitch source code leak represents yet another instance of a repetitive problem — excessive permissions to Source Code Management. Code exfiltration is easy to exploit, but what are the reasons for it?
Source Code Management tools are designed to enable collaboration with minimal impact on development velocity. For example, when a user is invited to collaborate on GitHub, there are generally 2 access levels:
In addition to these levels, there is an option to add membership in specific teams, which have more specific permissions. Below is an illustration of a user invitation to an organization with specific group membership.
By looking into this group membership, it can be determined what is the additional permission beyond the default access granted to members:
Permission management appears to be simple, but the challenge is that
permissions are derived from the most common denominator — having a READ access permission to all repositories. Below is a screenshot representing this default setting.
From adversarial perspective, an access to source code can be exploited by any of the following:
1. Leverage the git client on the developer’s workstation
Given access to a developer workstation, especially in the post COVID world with developers working from home in a less secure environment, it is simple to exploit as the access token already stored in the Git Credential Storage, which “serves” the token to the git client.
2. Leverage the browser’s context
In many cases, project and product management tasks are managed in the Version Control tool. It means that additional roles beyond developers typically have access to source code, such as project managers, which don’t use a git client. An adversary with a malware accessing the browser context can download the zip file containing the archive of the source code. It is harder to exploit but has much broader outreach.
3. Get an access token
Any access to private source code requires an access token or SSH key, regardless the source of the request. For example, a build system uses a short-lived token to clone repositories, a developer may use a long-lived token on the git client, and the project manager has a cookie with the token. There are many ways to get the access to these type of tokens, for example: