This post is written in response to GitHub’s security alert from April 15th about abusing OAuth app integrations, and it includes the technical details to identify and prevent such attacks.
GitHub application exploitation is yet another software supply chain attack vector to compromise multiple organizations rapidly, and there is no code dependency or hardened CI/CD pipeline that will mitigate this risk or provide sufficient context to such attack.
GitHub supports two types of application integrations – OAuth App and GitHub App. The key difference is that OAuth Apps could potentially access the user's accessible resources (e.g., all organizations, unless a restriction policy is enabled, or application is pre-approved for each organization). OAuth App creators can limit the access scope of their apps; however, these scopes are not as granular as GitHub Apps.
From an operational standpoint, it is better to use GitHub Apps since an OAuth App will stop working when the user’s account becomes inactive (e.g., when an employee leaves a company).
From a security standpoint, it is also preferred to use GitHub Apps since the attack surface can be reduced via more fine-grained access controls.
Check out this breakdown of the differences between GitHubApps and OAuth Apps.
GitHub Apps can request almost any permission from the list of API actions supported by GitHub Apps. Currently, users are not able to edit or reduce permissions, but only to reduce the repositories it has access to. This means that users can either grant all app permissions requested, or not use the app. Below is an illustration for a GitHub App installation request.
Each of the permissions can have a justification on the application developer side, but we have noticed many apps request more than seems necessary. It could be out of convenience, or to support some subset of features that are not applicable to all users at a given point of time. Therefore, many applications can have excessive permissions.
Below is an example of Slack’s permissions, which is excessive at first glance:
Why should Slack access my source code? According to the Slack App Integration readme this is used to render code snippets in Slack when you paste a GitHub file link. The risk is that the app can clone your entire codebase, but it might be a tolerable risk as it may improve developer productivity.
However, why should the App have written permissions to deployments? We have not seen any use cases where Slack needs to use that permission across our customer base, but please let us know if you find a good reason for it by tagging us on Twitter.
Use our scheduling link here to book a demo to see how Arnica can help you mitigate this risk as well as prevent many other software supply-chain attacks.