## https://sploitus.com/exploit?id=PACKETSTORM:162363
(Original blog post here:
https://wwws.nightwatchcybersecurity.com/2021/04/25/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.
NOTE: Paid GitHub.com plans and the GitHub enterprise server were not tested.
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.
REFERENCES
Example repository: https://github.com/nightwatchcyber/gh_release_test
GitHub.com docs:
- https://docs.github.com/en/github/administering-a-repository/about-releases
- https://docs.github.com/en/github/administering-a-repository/managing-releases-in-a-repository
- https://docs.github.com/en/rest/reference/repos#releases
HackerOne report # 1167780
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