Github OAuth Apps Security: How to protect yourself against GitHub/OAuth Apps Supply Chain Attacks

Introduction: Comparing OAuth Apps vs. GitHub Apps

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.

Risky API Permissions

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.

What can you do?

OAuth Apps  

1. Ensure OAuth App Access Restrictions are enabled
   With your Organization Owner account, navigate to the Third-Party Application Access Policy page on GitHub and Make sure that the policy is enabled, as in the screenshot below. A link to the right location is also added here (replace with your org name).

https://github.com/organizations/[YOUR_ORGANIZATION]/settings/oauth_application_policy

2. Review Organization-wide OAuth Authorization Activity
   Validate all authorized apps. Make sure the person who approved them is known to you and the approval date & time match your expectations. You can see that in the audit trail log. The log should look like in the screenshot below. A link to the right location is also added here (replace with your org name).

https://github.com/organizations/[YOUR_ORGANIZATION]/settings/audit-log?q=action%3Aorg.oauth_app_access_approved+or+action%3Aorg.oauth_app_access_denied

‍

3. Review Personal OAuth Authorization Activity  
   If you are not an org owner and would like to see the history of OAuth App related activity, you can use this link (also provided here below). If you see any suspicious activity, please contact your GitHub org owner immediately.

https://github.com/settings/security-log?q=action%3Aoauth_authorization.create+OR+action%3Aoauth_authorization.destroy

GitHub Apps

1. Review App permissions
   The web interface exposes partial application description. Use GitHub’s API to get more details about the app to assess the risk of installing it. For example, for slack, use the following link: https://api.github.com/apps/slack.  

2. Limit GitHub App permissions to specific repositories
   Modify the permissions of the Apps to specific repositories to reduce the attack surface. It is important to mention that managing these permissions can be overwhelming, as repositories can be created and deleted with high frequency, which will cause the application to miss repositories that should be in scope.  
   Keep in mind that application permissions can be granted in 3 levels – repository, organization, and user. This action handles the repositories only.

3. Get context on the behavior of each application
   Many installed applications pose a risk to the GitHub organizations, but not all companies have the context on who uses them, who installed them, which permissions they use, and in which repositories. To get this context, the audit trail of the organization needs to be inspected, at minimum.  
   Arnica’s App Inventory feature does this for you across all your GitHub organizations.  

4. Install the app in a Sandbox first
   Install the app on a dummy organization to inspect its behavior and functionality. Need a Sandbox? Use our open source GitGoat tool to set this up quickly: https://github.com/arnica-ext/GitGoat  

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.

‍