Development

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

Nir Valtman
May 11, 2022

TL;DR

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.

Arnica is now live in Beta!
Arnica is now live in Beta. Come see how Arnica is mitigating software supply chain risks.
Get Started Today

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.

Ease of 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:

What can you do to minimize the 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.

Arnica is now live in Beta!
Arnica is now live in Beta. Come see how Arnica is mitigating software supply chain risks.
Get Started Today