Yesterday Okta announced a security breach that involved an attacker gaining access to their source code hosted in GitHub. This isn’t the first time, and it certainly won’t be the last time we see attackers targeting GitHub repositories. In this blog, I wanted to address why it’s such a popular target, and offer advice for protecting your own repositories.
GitHub is awesome - community-driven and open-source focused. It truly made open source collaboration accessible to a wider audience from the moment it was launched in 2008.
Now, 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. Let that sink in.
It’s no wonder that an attacker went after Okta’s source code. They’re 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. The attacker behind the Microsoft attack, Shiny Hunters, was known to specifically target private GitHub repositories. Shiny Hunters would go on to breach tens of companies using this technique, selling their data across various dark web marketplaces.
Marketplace listings from Shiny Hunters. Source: https://www.zdnet.com/article/a-hacker-group-is-selling-more-than-73-million-user-records-on-the-dark-web/
It’s not hard to understand why attackers target organizations’ GitHub accounts. In some cases, such as Okta, they might be able to gain access to source code. However, more often, there is sensitive information that can be used 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.
So if GitHub is so important, why haven’t these enterprise companies who host their most sensitive code in GitHub, done a better job of locking it down?
It’s a more complex and challenging problem than you might think. It’s a story about identity security. The beauty of the GitHub model allows for unfettered collaboration but 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 for 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 they announced the deprecation of usernames and passwords for git operations last year. A step in the right direction.
GitHub provides the tools we need to lock down the environment, you just need to know how to use them (and, in some cases, you need to be able to afford to pay for them). Unfortunately, some of the most important security capabilities require GitHub Enterprise.
Let’s unpack some of this to lay out the common issues with securing your organization in GitHub:
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 second factor authentication (2FA aka MFA) via your SSO and even if you are enforcing 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 (PAT) 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 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).
Proper identity and access management is just one part of securing GitHub. How you maintain a secure software development code lifecycle (SDLC) is an entirely different, yet equally important, topic that must build upon this solid IAM foundation.
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 heading into 2023. Expect more to come.
