Why Attackers Target GitHub, and How You Can Secure It

Last week Okta announced a security breach that involved an attacker gaining access to its source code hosted in GitHub. That’s just the latest example in a long string of attacks gaining access to company source code in GitHub. Dropbox, Gentoo Linux, and Microsoft have all had their GitHub accounts targeted before.

With 90 million active users, GitHub is the most popular source code management tool for both open source and private enterprise code repositories. It’s a major piece of fundamental infrastructure and the keeper of some of the most sensitive assets and data in the world.

It’s no wonder that attackers are increasingly going after source code. In some cases, such as Okta, they might be trying to gain access to the source code. More often, the attackers are looking for sensitive information to use in a subsequent attack.

An attacker who can gain access to private source code can examine it for vulnerabilities and then exploit those vulnerabilities in subsequent attacks. Attackers can also harvest hardcoded keys, passwords, and other credentials that might be stored in GitHub to gain access to cloud services and databases hosted in AWS, Azure, or GCP. A single stolen repository can yield intellectual property, valid credentials, and a nice list of vulnerabilities in production software that are ready to be exploited.

Shiny Hunters, an attack group known to specifically target private GitHub repositories, has breached tens of companies using this technique, and sold their data across various Dark Web marketplaces.

Securing the Organization’s GitHub Environment

There is no question that GitHub is a critical part of the organization’s infrastructure, but locking it down is a complex and challenging identity security problem. The beauty of the GitHub model is that it allows for unfettered collaboration, but that also creates one of the biggest headaches in modern IT security.

Just think about it: Anyone remotely technical in 2022 has a GitHub account. And you can use your GitHub account for everything. We can use these accounts for personal side projects, open source contributions, and our work in public and private code repositories that are ultimately owned by our employers. That is a lot of heavy lifting for a single identity!

You can also use the “Sign in with GitHub” feature to use your GitHub identity in other websites and services outside of just GitHub itself. And there’s more: GitHub is unique in that you don’t just sign in to their website, you also pull, push, and clone code from GitHub’s servers down to your local machine via git operations over HTTPS and SSH, which themselves require your GitHub identity.

Clearly GitHub picked up on these security implications when it announced the deprecation of usernames and passwords for git operations last year — a step in the right direction.

7 Tips for Securing Your GitHub

While GitHub provides tools to lock down the environment, organizations need to know how to use them. Unfortunately, some of the most important security capabilities require GitHub Enterprise. Nonetheless, here are seven principles for better GitHub security.

1. Don’t allow personal accounts for work. We get it, your company has a few public repositories and you can build your credibility by showing off some public contributions in your next job interview. Your personal GitHub account is part of your brand. Unfortunately, this is also one of the biggest holes in organizations using GitHub today: They do not strictly govern the use of personal accounts for work purposes. As tempting as it might be, personal accounts should not be used for work. There’s just no way to control who has access to that personal Gmail address that you used to create your personal GitHub account.
2. Require authentication via company SSO. Unfortunately, GitHub shows up prominently on the SSO Wall of Shame. That’s right — you need to pay extra for SSO integration. Once you have GitHub Enterprise, you can connect GitHub to your company SSO, such as Okta or Azure AD or Google Workspace, and you can lock down your organization to only allow authentication via SSO.
3. Require 2FA on all accounts. Even if you enforce two-factor authentication (2FA, aka MFA) via your SSO and also require SSO authentication, the safest option is to still enforce 2FA for all GitHub users in your organization. Exemption groups and policy exceptions in your SSO provider can make SSO MFA easy to bypass.
4. Use SSH Keys for git operations. While GitHub has introduced fine-grained permissions control with personal access tokens (PATs), they remain susceptible to phishing as these tokens are often copied around in plaintext. By using SSH keys for authentication for git operations, your organization can use thoughtful PKI to govern how SSH keys are provisioned, and can also tie this to your company’s device management and your own certificate authority (CA).
5. Restrict repository member privileges using roles. GitHub offers several different repository roles that can be assigned based on the principle of least privilege. Base permissions can be controlled at the organization level. Always take care to assign the least privileged role that a member needs to be productive. Don’t make everyone an admin.
6. Don’t allow outside collaborators. Working with contractors is a normal part of managing large software projects. However, the governance surrounding outside collaborators in GitHub is insufficient to keep your organization secure. Instead, force outside collaborators to authenticate via your company SSO, and do not allow repository admins to invite them directly to your organization’s repositories.
7. Audit, analyze, and audit again. No organization is perfect; even with the best policies in place, accounts fall through the cracks and mistakes are made. Even before locking down your GitHub organization, take the time to implement a regular audit process to look for dormant accounts that are not using their access and to limit the number of privileged roles in your repositories. Once your environment is locked down, keep an eye out for policy violations, such as a user who is somehow still authenticating outside of your SSO or not using 2FA.

The breach of Okta’s GitHub repository is a powerful example of just how hard it is to protect identities within enterprises, but it isn’t a unique one. Every day we see what happens when employees and contractors experience account takeover. We see the effects of weak authentication, lax policies for personal email accounts, and the ever-expanding size of the identity attack surface.

Unfortunately, this latest incident is just one part of a growing trend of identity-related breaches to watch for in 2023.

Source: www.darkreading.com