On April 15, GitHub Security announced that it experienced a software supply chain attack on many of its private repositories due to abuse of stolen OAuth user tokens from two popular integrations – Heroku and TravisCI. This GitHub OAuth compromise used these apps as entrance points into dozens of organizations.
The current motivation for this breach is unknown, but it is likely that the attacker is mining the downloaded private repository contents for secrets that could be used to pivot into other infrastructure. This includes critical infrastructure as well as production environments containing sensitive and proprietary information.
How Did Attackers Compromise OAuth Tokens
In late 2020, GitHub moved to no longer accept passwords when authenticating with REST API. Instead, they began requiring the use of token-based authentication (e.g., personal access, OAuth, or GitHub App installation token) for all authenticated API operations on the GitHub platform.
OAuth, short for Open Authentication, is an account integration technology used across the web to allow user information to be used across third-party websites in a less intrusive way than directly sharing data.
GitHub allows 3rd party applications to perform actions like accessing files, changing configurations, and running actions. The application vendor is responsible for providing OAuth tokens used to access GitHub programmatically through the 3rd party OAuth application.
Leveraging a weakness that was unknown at the time this post was written, attackers stole OAuth tokens from Heroku and Travis CI and used them to access and download the contents of private repositories. Over 2200 companies reportedly use Heroku, and over 1700 use Travis CI in their tech stack–the blast radius of this breach has the potential to be huge.
According to the security alert, the list of impacted OAuth applications include:
> Heroku Dashboard (ID: 145909)
> Heroku Dashboard (ID: 628778)
> Heroku Dashboard – Preview (ID: 313468)
> Heroku Dashboard – Classic (ID: 363831)
> Travis CI (ID: 9216)
These stolen OAuth tokens resulted in the compromise of private repositories from dozens of organizations, including GitHub itself and npm, GitHub’s open-source package manager.
Once GitHub identified stolen third-party OAuth tokens affecting GitHub users, GitHub took immediate steps to respond and protect users. GitHub contacted Heroku and Travis-CI to request that they initiate their own security investigations, revoke all OAuth user tokens associated with the affected applications, and begin work to notify their own users.
Impacts of this Software Supply Chain Attack
Impact on Heroku and Travis CI
Heroku recommended customers disconnect the Heroku integration from their GitHub repositories and check for evidence of exfiltration in their logs.
Travis CI revoked and reissued all private customer auth keys and tokens integrating Travis CI with GitHub to prevent compromise.
In the case of Travis CI, revoking keys can help prevent the later compromise of customers, especially if these keys have the potential to be leaked as part of a larger exfiltration campaign. However, if attackers still have access to the platforms, the vector of attack between the integration and the customer still exists.
For this reason, we recommend Heroku’s prescribed course of action for both Heroku and Travis CI. Until the platforms have been swept for tampering and backdoors, there is no guarantee that they can not be used to execute a later attack.
Impact on GitHub and npm
GitHub assesses that the attacker did not modify any packages or gain access to any user account data or credentials. GitHub is still working to understand whether the attacker viewed or downloaded private packages. npm uses a completely separate infrastructure from GitHub.com; GitHub was not affected by this original attack. Though investigation continues, GitHub has found no evidence that other GitHub-owned private repos were cloned by the attacker using stolen third-party OAuth tokens.
Impacts on Users and Organizations
GitHub is currently working to identify and notify all of the known-affected victim users and organizations. They have vowed to continue to notify any additional affected users or organizations as they are identified.
How Organizations Can Protect Themselves from GitHub OAuth Compromise
Periodically review OAuth applications
OAuth access is given to users and not to organizations, so tracking it could be tough in organizations with complex access relations. Each user could review their OAuth authorized apps by navigating to “Settings” -> ”Applications” -> ”Authorized OAuth Apps”.
GitHub allows us to restrict third-party access to the organization by enabling “Third-party application security policy” in organization “Settings” -> ”Third-party access”.
Once this is allowed, we can deny any access to the organization using any OAuth app to any of the organization users:
We also recommend using GitHub App instead of the OAuth app whenever possible because it provides more granular control over permissions and repository access granted to third-party applications.
Review Logs
It is recommended to periodically review organization audit logs, user account security logs, and OAuth applications authorized to access your organization.
Organization logs may be found by navigating to “Settings”->”Logs”->”Audit log”. This contains important information including security settings, such as third-party access, branch protection rules, and more.
How Cycode Can Help Prevent Software Supply Chain Attacks
Though life doesn’t end when a compromise occurs, it is difficult to regain customer trust once it is lost–especially if the breach of your application has directly resulted in the breach of your customers. Quick, open communication, once an attack is identified, helps. However, preventing the software supply chain attack in the first place is even better.
This aforementioned digital supply chain attack caused by a GitHub OAuth compromise was made possible due to two issues that Cycode can directly address: mitigating dependency attacks through third-party integrations and detecting secrets in code. Cycode can help to reduce the risk of vulnerability by:
- identifying anomalous activity (such as excessive repo cloning) which can serve as an early warning of an attack in progress,
- secret scanning in private and public repositories,
- granting visibility for all third-party integrations,
- supporting automated remediation of excess privileges,
- enforcing security policy across an organization, and
- providing contextual insights to help protect sensitive attack paths.
Cycode can monitor and enforce security policy across the entire SDLC, including user permissions, 3rd party applications, and cloud infrastructure. This functionality is made fundamentally possible because of Cycode’s knowledge graph.
This security platform is powered by a knowledge graph that helps establish strong governance over every point of the SDLC by providing a cross-SCM inventory of an organization’s users, contributors, teams, organizations, and repositories; this governance extends into providing more oversight into changes made to code as a means of further protecting key code.
Cycode also helps you automatically audit access and enforce the principle of least privilege; this helps mitigate the risk of code tampering and insider threat. Furthermore, Cycode helps ensure that strong authentication and secure development practices are in place.
Want To Learn More?
Schedule a demo to learn more about how Cycode can improve your software supply chain security.
Originally published: April 19, 2022
