{"id":118226,"date":"2024-07-25T15:43:00","date_gmt":"2024-07-25T13:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/dostup-k-dannym-iz-udalyonnyh-i-privatnyh-repozitoriev-na-github-imeyushhih-forki"},"modified":"2024-07-25T15:43:00","modified_gmt":"2024-07-25T13:43:02","slug":"dostup-k-dannym-iz-udalyonnyh-i-privatnyh-repozitoriev-na-github-imeyushhih-forki","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/dostup-k-dannym-iz-udalyonnyh-i-privatnyh-repozitoriev-na-github-imeyushhih-forki","title":{"rendered":"Access to data from remote and private repositories on GitHub that have forks","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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. <\/p>\n
The ability to access commits by hash across all related forks of a repository is driven by GitHub's optimization efforts and the avoidance of duplicates, storing all objects from the main repository and forks together while logically separating commit ownership. This storage method allows viewing any commit from any fork in the main repository by explicitly providing its hash in the URL. For example, a user can create a fork of the repository \"\/torvalds\/linux\" and add any code to it, after which this code becomes accessible via a direct hash link in the repository \"\/torvalds\/linux\". If the repository is deleted, the data from the deleted repository remains available through the commit hash as long as there is at least one public fork. <\/p>\n
Three scenarios are proposed that represent a security threat: <\/p>\n
\n
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.\n
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.
<\/center>\n
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).
<\/center> <\/ul>\n
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. <\/p>\n
Finding a commit hash, generated based on the SHA-1 algorithm and consisting of 32 characters, is impractical, but it turns out that it is not necessary. GitHub supports a shortened form of referencing commits, allowing changes to be addressed by the first few characters of the hash if there are no overlaps with other commits. The minimum number of characters for a shortened hash reference is 4, which corresponds to checking all 65 thousand combinations (16^4). Moreover, this check may not even be necessary, as the GitHub API allows connecting handlers to intercept events that are used by third-party projects maintaining an archive with a complete log of all operations, where information about commit hashes remains even after repositories are deleted. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Access](\"\/wp-content\/uploads\/2024\/07\/45381deb03eaa5be40baf8b4dbf7b481.png\")
<\/center>\n![\"Access](\"\/wp-content\/uploads\/2024\/07\/23342cf907bd300699e913297d29b310.png\")
<\/center> <\/ul>\n