Truffle Security has published attack scenarios for several common methods of working with repositories on GitHub that allow the extraction of data from remote repositories with public forks or those created as forks.
The ability to access commits by hash across all repositories related to forks stems from GitHub's optimization strategy, which stores all objects from the main repository and forks together, logically separating the ownership of commits. This storage method allows you to view any commit from any fork in the main repository by explicitly specifying its hash in the URL. For example, a user can create a fork of the repository "/torvalds/linux" and add any code, which then becomes accessible via a direct hash link in the repository "/torvalds/linux". If the repository is deleted, data from the remote repository remains accessible via the commit hash as long as there is at least one public fork.
Three scenarios are proposed that represent a security threat:
- The first scenario addresses situations where developers create forks of public repositories, make changes, experiment, and then delete them. Beyond the leakage of code not intended for publication, there is a danger when working keys to APIs are added in experimental code files with samples. In this case, an attacker can gain access to the modifications via the commit hash that is directed after the fork's deletion through the main repository. For instance, using the proposed method, researchers managed to identify 30 working API access keys by examining three machine learning-related repositories with a large number of forks.
- The second scenario concerns the possibility of accessing data after the primary repository has been deleted if forks for that repository were created. An example is given of a case where a public repository of a company accidentally published the private keys of one of its employees, granting full access to all the repositories of this company on GitHub. The company deleted the repository through which the leak occurred, but the keys remained accessible for extraction through commit hash queries in repositories with forks.
- The third scenario is related to the project development model, where a basic open version is developed in a public repository and an extended proprietary version in a private one. If a company initially developed the project in a private repository and then, after opening the project's code, moved it to a public status while continuing to develop a closed internal or extended version in a private fork, there is a possibility of accessing the changes added to the private fork via commit hashes through the public repository. However, access is only possible to the changes added to the private fork before the main repository was converted to public (the storage of private and public repositories is separated, but when two repositories were private, commits were stored together, thus they remained in the repository after it was converted to public).
The trick to accessing commits in the repository forks through a link to the main repository has been known for many years and is periodically used for various pranks and to mislead developers (for example, pranksters periodically create the illusion of backdoor injections in the Linux kernel repository on GitHub in this manner). As a countermeasure against such pranks, GitHub added a warning that the requested commit does not belong to any branches in the current repository and may belong to a fork. Nevertheless, the ability to access commits by hash in any associated repository forks is considered harmless, as knowledge of the commit hash is required to query data in remote and private forks.
Finding a commit hash generated based on the SHA-1 algorithm and consisting of 32 characters is unrealistic, but it turns out this is not necessary. GitHub supports a shorthand way to reference commits, allowing changes to be addressed using just the first few characters of the hash, provided there are no overlaps with other commits. The minimum number of characters for short-hash addressing is 4, which corresponds to a total of 65,000 combinations (16^4). Moreover, exhaustive searching might not even be needed, as the GitHub API allows connecting handlers to intercept events used by third-party projects maintaining an archive with a complete log of all operations, in which information about commit hashes remains even after repositories are deleted.
Source: opennet.ru
