近日，Truffle Security的研究人员再次强调，已删除的GitHub存储库（公共或私有）以及已删除的存储库副本（分叉）中的数据不一定真会被删除。

该机构的安全研究员Joe Leon在周三的一份公告中表示，这种情况是在上周向一家大型科技公司提交一份严重漏洞报告时发现的，该报告涉及员工GitHub 帐户的私钥（该帐户在整个组织中拥有广泛的访问权限），该密钥已公开提交到GitHub存储库。

意识到这一点后，该公司立即删除了存储库。但由于它已被分叉，Leon仍然可以通过分叉访问包含敏感数据的提交，尽管该分叉从未与原始上游存储库同步。Leon还补充说，在审查了来自大型AI公司的三个广泛分叉的公共存储库后，Truffle Security研究人员从已删除的分叉中发现了 40 个有效的API密钥。

Truffle Security联合创始人兼首席执行官Dylan Ayrey解释说，这个问题归根结底是由于所谓的“悬空提交”(dangling commit) 造成的。git 提交捕获存储库在特定时间点的状态快照，包括对代码和数据的更改。每个提交都由加密哈希唯一标识。例如，删除分支会删除对特定提交链的引用，但提交本身不会从存储库的对象数据库中删除。

Ayrey 表示，即使与代码树的连接被切断，如果有直接访问它们的标识符，则仍然可以下载相关数据。例如，以TruffleHog 存储库中的此提交作为示范：

要访问此提交，用户通常会访问包含完整 SHA-1 提交哈希的 URL：https://github.com/trufflesecurity/trufflehog/commit/07f01e8337c1073d2c45bb12d688170fcd44c637

但实际上用户并不需要知道整个 32 个字符的 SHA-1 值。提交哈希可以通过 GitHub 的 UI 进行暴力破解，特别是因为git 协议允许在引用提交时使用短 SHA-1 值。短 SHA-1 值是避免与另一个提交哈希发生冲突所需的最小字符数，绝对最小值为 4。所有 4 个字符 SHA-1 值的密钥空间为 65536 (16^4)。暴力破解所有可能的值可以相对容易地实现。

Truffle Security最后从中得出了如下结论：

① 只要一个分叉存在，对该存储库网络的任何提交（即上游存储库或下游分叉上的提交）都将永远存在。

② 安全修复公共 GitHub 存储库上泄露的密钥的唯一方法是通过密钥轮换。

③ GitHub 的存储库架构决定了其必然存在此缺陷，不幸的是，许多GitHub用户不理解存储库网络的实际工作原理，并且会因此而降低安全性。

编辑：左右里

资讯来源：Truffle Security

转载请注明出处和本文链接

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！