In the recent codecov.io security incident, an attacker modified a shell script used by a common software development tool for code coverage. This modification did not take place at the original source code repository where it would have been visible to others, but after the code was packaged and placed on the web server from which it was served.
Prompted by this incident, we are now releasing new tools that provide information and detection of similar attacks against other projects. The scope is limited to attacks that modify the released code and do not touch the original source code. The following tools are now available:
dont_curl_and_bash – a list of projects that are installed directly off the Internet via a “curl | bash” manner along with possible mitigations
icetrust – a tool that can be used to verify a downloaded artifact such as a shell script before it is executed via methods such as checksums and PGP signatures
release_auditor – a tool that can be used to check if a GitHub release was modified after initial publication (see our earlier blog post for additional information)
Additionally, we are also providing two examples of how a continuous monitoring dashboard can be setup to detect such attacks by project maintainers. The following are available (screenshots below):
As part of our ongoing research into supply chain attacks, we have been looking into the overall security of various OSS projects. Homebrew is one such project – providing Linux packages for MacOS. The current bootstrap process is retrieving the bootstrap shell script directly from GitHub and piping it into bash without verification as follows:
We had a discussion with the project maintainers around the security of this approach, and while it is not great security-wise, it is somewhat safer than hosting the script on an intermediate web server (like codecov.io), since changes will be noticed within a GitHub repo fairly quickly (similar to what happened with PHP).
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.
The following steps can be used to replicate this issue:
Alice creates a public repository on GitHub.com, and adds some code including a shell script “test.sh”.
Alice invites Bob as a collaborator on this repository.
Alice publishes a release including the shell script “test.sh” as a separate asset.
Bob accesses the release, and modifies the “test.sh” script within the release.
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.
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
Nightwatch Cybersecurity 