Afraid of your source code leaking? I can tell by the Twitch in your eye…!

Introduction: Excessive access to source code is a serious concern

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?

Default Access to Source Code

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:

1. Owner: full administrative rights to the organization and have complete access to all repositories and teams.
2. Member: can see all other members, and can be granted access to repositories. A member can also create new teams and repositories.

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.

Common causes of source code exploitation

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:

• Bribing an employee to share the access token with the adversary, as we’ve seen in the past with a Russian criminal who tried to convince a Tesla employee to plant a malware.
• Compromising developer tools with malicious extensions to enable remote code execution and even implanting a backdoor in your code.

Best practices for minimizing source code risk

1. Modify the base permissions in your Source Control Management to be less permissive or manage micro-organizations within the enterprise.
2. Use SSH keys with a passphrase to authenticate into the Source Control Management tool. Worth knowing that if the user stores the passphrase in the built-in key storage (such as keychain), it beats the purpose.
3. User entitlements review is common practice for regulated companies. The challenge is that these reviews tend to be rubber stamped by the employee managers or repository owners. To minimize the risk, measure the user entitlements over time and expect to see a trend of decreasing user entitlements from time to time.
4. Educate yourself about how permissions are constructed by playing with them in a sandbox. For this purpose, we created GitGoat, which is an open source tool that was built to enable DevOps and Engineering teams the opportunity to design and implement a sustainable misconfiguration prevention strategy. It can be used to test products (such as OpenSSF) with access to GitHub repositories without risking your production environment.

‍