We learned about a bug in GitHub that for about five days at the end of February allowed third-party applications connected to GitHub to generate new scoped installation tokens with elevated permissions. For example, if you connected the Codecov app to your GitHub account with read-only access to your repositories, during that window the app could have created a new token with write access to them. This bug could have led to major security issues, including data loss and leaks of secrets and credentials. Since GitHub disclosed the bug only late last week, the actual scope of impact has yet to be determined.
What are GitHub Apps?
GitHub Apps are the officially recommended way to integrate applications with GitHub. They allow you to change GitHub’s surface-level functionality through webhooks and GitHub’s APIs. Developers can build integrations to add their own GitHub feature, automate routine processes, and extend workflows in their projects. Currently, there are more than 580 apps on GitHub Marketplace, and the most popular apps have reached hundreds of thousands of installs.
GitHub Apps can be installed on both organization and individual accounts and can be granted access to specific repositories. To install a GitHub App, you must be an organization owner or have admin permissions in a repository. By default, only organization owners can manage the settings of GitHub Apps in an organization.
How do GitHub Apps authenticate using tokens?
According to GitHub, GitHub Apps should authenticate using either a JSON web token (JWT), OAuth token, or installation access token. The bug we’re reviewing is relevant to the latter. Installation tokens are generated with JWT, so let’s understand what they are and how they’re used.
JWT is an open standard that defines a secure way for transmitting information as a JSON object. This information can be verified and trusted because it’s digitally signed. JWT is commonly used for authorization by major technology companies. It allows for secure access delegation, enabling third-party apps to exchange credentials information securely without users giving away their passwords.
For example, you’d like to give a game access to your Facebook friend list. The game can use OAuth, with JWT as the token, to ask for that resource from your Facebook account with your approval. OAuth tokens usually live for less than an hour to prevent them from leaking and being maliciously used.
After it gets your approval, the game (and any third-party app for that matter) can ask for this scoped OAuth token anytime it needs to access that resource, getting a new valid — but time-limited — access token.
What went wrong with these tokens?
Generally, GitHub Apps create scoped installation tokens based on the scopes and permissions granted when an app was installed in a user account or organization. For example, if you granted the app access to read a user’s profile data, the scoped token that the app generates would have the read:user
permission.
The recent bug allowed GitHub Apps to generate scoped installation tokens with elevated permissions for about five days between February 25, 2022 and March 2, 2022. For example, an app could have generated a token with write:user
permission, which is elevated from the originally granted read:user
permission. Each of these tokens was valid for up to one hour.
However, the app wouldn’t have been able to get new permissions for additional scopes other than the scopes originally granted, for example, packages
.
GitHub says that it started an investigation right away and quickly fixed the bug.
Potential impact
The exposure for this bug is wide, and the potential impact could be massive. Every company that uses GitHub and has a GitHub App installed — basically everyone — could have been affected by this. However, GitHub doesn’t have evidence that this bug was ever exploited for malicious purposes.
Potentially, each token that was generated during the bug window could have gained admin access, which can be very damaging to an organization. For example, if a software vendor’s private repository containing their source code and intellectual property was leaked or deleted, it could literally mean the end of that company.
Mitigation and recommendations
The actual impact of this issue on your environment will depend on the permission scopes that you granted to third-party apps when they were installed. GitHub was unable to determine whether this bug was ever exploited, and the short-lived tokens that may have been generated and used in a malicious way are long gone.
Nonetheless, we recommend reviewing all your installed GitHub apps and their scopes and permissions. You can use this guidance for assessing GitHub Apps, their permissions, and their access to your private organization repositories.
In the long term, a dedicated solution that properly governs third-party access in your software supply chain can help avoid such risk in the future. For instance, Aqua’s Cloud Native Application Protection Platform (CNAPP) provides a solution for software supply chain security, based on its recent acquisition of Argon’s technology, and can protect against such supply chain threats.
Conclusion
This GitHub issue underscores that third-party apps and packages are a growing security risk for organizations. The lack of management, control, and visibility into these third-party apps and the software supply chain in general is why attackers are increasingly targeting them to gather information and infiltrate organizations. In 2021 alone, software supply chain attacks increased by more than 300%.
What’s more, third-party apps don’t always behave as we expect them to and can even reveal sensitive data “by design”. That was the case in the latest research from Aqua’s Team Nautilus, in which we found that tens of thousands of tokens of free-tier users were exposed via the Travis CI API.