Supply Chain Attacks via GitHub.com Releases

Summary

Release functionality on GitHub.com allows modification of assets within a release by any project collaborator. This can occur after the release is published, and without notification or audit logging accessible in the UI to either the project owners or the public. However, some audit information may be available via the GitHub APIs. An attacker can compromise a collaborator’s account and use it to modify releases without the knowledge of project owners or the public, thus resulting in supply chain attacks against the users of the project.

This issue was reported to the vendor – their response is that this is intended behavior and is an intentional design decision. While the vendor is planning improvements in this area, they are not able to provide additional details. GitHub.com paid plans and the GitHub enterprise server were not tested.

As a mitigation measure, project owners using GitHub.com are encouraged to use other methods for securing releases such as digitally signing releases with PGP. Users are encouraged to check digital signatures and use the GitHub.com release APIs to extract and verify release assets data.

Background

GitHub.com is a widely used tool for software development offering source code management (SCM) and other tools. It is used for hosting and distribution by many open source projects (OSS). The release functionality within GitHub.com offers a way to publish packaged software iterations as releases. These include a compressed snapshot of the source within the project as a .ZIP and .TAR.GZ file, as well as as additional binary assets. This functionality is a common way for open source projects to distribute their releases.

Vulnerability Details

The release functionality on GitHub.com allows modification of assets within a release by any project collaborator, after the initial release is published. An attacker can use this gap to modify releases without the knowledge of project owners by compromising an account of any project collaborator, thus resulting in supply chain attacks against those using the project. The following specific issues facilitate this:

  • Release assets can be modified after initial publication – except for the source code snapshots
  • Any project collaborator can modify a release – there are no fine-grained controls to allow code access and not release access.
  • There is no notification or indication within the UI that a release was modified – to either the project owners or other collaborators, or the public. However, some data is exposed via API.
  • A “verified” flag is displayed if the Git commit was verified – but this only applies to the source code snapshot and not the other release assets

The releases API provided by GitHub does expose additional information about release assets, which could potentially be used to see if a release was modified. This information includes the username of the uploader and the timestamp when the upload took place. This can be compared to the main release metadata. An example of using APIs for checking releases can be found at our release_auditor project.

NOTE: Paid GitHub.com plans and the GitHub enterprise server were not tested.

Example of a release (see here):

Example of API response exposing asset data:

Steps to Replicate

The following steps can be used to replicate this issue:

  1. Alice creates a public repository on GitHub.com, and adds some code including a shell script “test.sh”.
  2. Alice invites Bob as a collaborator on this repository.
  3. Alice publishes a release including the shell script “test.sh” as a separate asset.
  4. Bob accesses the release, and modifies the “test.sh” script within the release.
  5. When viewing the release via GitHub.com UI, there is no indication the script was modified. Downloading the script shows that it is different from what Alice published.

NOTE: Paid GitHub.com plans and the GitHub enterprise server were not tested.

Vendor Response and Mitigation

The issue was reported to the vendor via their bounty program. Their response is that this is intended behavior and is an intentional design decision. While the vendor is planning improvements in this area, they are not able to provide additional details.

GitHub.com paid plans and the GitHub enterprise server were not tested.

As a mitigation measure, project owners using GitHub.com are encouraged to use other methods for securing releases such as digitally signing releases with PGP. Users are encouraged to check digital signatures and use the GitHub.com release APIs to extract and verify release assets data.

An example of using APIs to check releases can be found in our release_auditor project.

References

Example repository: https://github.com/nightwatchcyber/gh_release_test
GitHub.com docs: here, here and here
HackerOne report # 1167780
release_auditor: see here

Credits

Advisory written by Y. Shafranovich

Timeline

2021-04-18: Initial report submitted to the vendor
2021-04-20: Automated response received
2021-04-21: Vendor response received, intended behavior
2021-04-21: Request to disclose sent
2021-04-23: Vendor ok with disclosure
2021-04-25: Public disclosure – added a link to the OSS project