GitHub Missing Audit Logging exploit

Share

## 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