GitHub代码删了也无用，任何人仍可永久访问？！微软：这不是Bug而是有意设计...

「动手亲自在 GitHub 存储库中删掉的数据可能只是表面，实际上并未被删除成功，任何人都有机会访问」，这两天，来自开源安全软件公司 Truffle Security 研究人员的最新发现震惊整个开源圈。

要知道早在去年年初，GitHub 的用户量就突破了 1 亿，其代码库数量在 2022 年时已达到了 1.9 亿，由此成为了世界上最大的代码托管网站。如今这项调查研究发现，「删除」似乎形同虚设，这也使得不少网友开始怀疑，点击删除键究竟有什么用？倘若密码在数据中泄露，那是否任何人都可以随意查看？

更甚的是，研究人员称通过 GitHub 官方回复中可以得知，后者对此事是知情的，并且有意设计成这样的。而这究竟是怎么一回事？Truffle Security 研究人员在官方博客上发布了长文说清了来龙去脉。

定义 CFOR 漏洞

在研究人员看来，对于所有使用 GitHub 的组织来说，这是一个巨大的攻击媒介，为了更好地解释这个问题，他们引入了一个新术语：跨分叉对象引用（Cross Fork Object Reference，CFOR）。当一个存储库 fork 可以访问另一个 fork 中的敏感数据（包括来自私有和已删除 fork 中的数据）时，就会发生 CFOR 漏洞。

与不安全的直接对象引用有些类似，在 CFOR 中，用户提供提交（Commit）哈希值就可以直接访问提交数据，否则这些数据对他们不可见。

访问已删除的 Fork 数据

在使用 GitHub 时，想必不少人都有过这样的操作：

第一步，你见到了一个不错的项目，然后 Fork 了这个公共存储库；

第二步，你将代码提交到你的 Fork 存储库中；

第三步，你删除了你的 Fork 存储库。

想象一下，删除之后，你提交到 Fork 存储库的代码还能访问吗？

按理来说，应该不能，对吧？毕竟你在上面第三步时，你已经做了删除处理。

然而，现实却是，你不仅可以永久访问，而且它不受你的控制。

对此，研究人员分享了一段视频，你可以看到 fork 了一个存储库，向其提交数据，然后删除了 Fork 存储库，结果可以通过原始存储库访问“已删除”的提交数据。

过去，你可能会认为只要知道提交了哈希值，你就会受到保护。但如今事实并非如此，哈希值是可以被发现的。

时隔多久可以从已删除的 fork 中找到数据呢？

答案是：这种情况非常常见。研究人员也调查了一家大型 AI 公司的 3 个经常被 fork 的公共存储库，从中轻松地找到了 40 个来自已删除 fork 存储库的有效 API 密钥。

其推测正常用户的行为模式似乎是这样的：

1. Fork 存储库。

2. 将 API 密钥硬编码到一个示例文件中。

3. <做自己的编码工作>

4. 删除 fork 存储库。

但这样做，情况会变得更糟，还会造成反向效果。

访问已删除存储库的数据

考虑以下场景：

你在 GitHub 上有一个公开存储库。

某个用户 fork 了你的存储库。

在他们 fork 之后，你提交了新的数据或代码（用户从不将他们在 fork 存储库提交的代码修改与你的更新合并）。

然后你删除了自己的公共存储库。

那么，你在他们 fork 了你的存储库之后提交的代码还能访问吗？

是的。

GitHub 将存储库和 fork 存储库存储在一个存储库网络中，原始的“上游”存储库作为根节点。当一个已被 fork 的公共“上游”存储库被“删除”时，GitHub 会将根节点角色重新分配给一个下游 fork 存储库之一。然而，所有来自“上游”存储库的提交仍然存在，并且可以通过任何下游的 fork 存储库进行访问。

在下面的视频中，研究人员创建了一个 repo，对其进行 fork，然后展示了在原始存储库被删除后，仍可以通过 fork 存储库访问未与其同步的原始存储库的数据。

这种情况绝非个例。上周就发生了这样的事情：

研究员向一家大型科技公司提交了一个 P1 级别的漏洞报告，显示他们意外地提交了一名员工的 GitHub 账户的私钥，该账户拥有对其整个 GitHub 组织的访问权限。他们立即删除了该仓库，但由于它已经被分叉，研究员仍然可以通过 fork 访问包含敏感数据的 Commit，即使该 fork 存储库从未与原始的“上游”存储库同步。

这里的意义在于，只要有至少一个 fork 存储库，Commit 到公共存储库的任何代码可能会永远可访问。

这也引出下一个问题，情况变得更糟了。

访问私有存储库数据

回想一下，你在 GitHub 上开源新工具的常见工作流程：

你创建一个私有存储库，最终会将其公开。

创建该存储库的一个私有、内部版本（通过 fork）并提交额外的代码，这些代码的功能你不打算公开。

你将你的“上游”存储库设为公开，并保持你的 fork 存储库私有。

那么，请问你的私有功能和相关代码（步骤 2 中的）是否可以被公众查看？

答案同样是肯定的。在你创建工具的内部分支和开源工具期间提交的任何代码都可以在公共存储库中访问。

在将“上游”存储库公开后，对私有 fork 存储库所做的任何提交都不可查看。这是因为更改私有“上游”存储库的可见性会产生两个存储库网络——一个用于私有版本，一个用于公共版本。

在下面的视频中，研究员演示了组织如何在开源新工具的同时维护私有的内部 fork 存储库，然后展示了某人如何通过公共版本访问私有内部版本的 Commit 数据。

不幸的是，这种工作流程是用户和组织开发开源软件时最常用的方法之一。因此，机密数据和秘密可能会无意中暴露在组织的公共 GitHub 存储库中。

如何实际访问数据？

这就引出一个更为重要的话题，即如何访问到真实的数据。对此，研究人员表示，其实很简单，只要直接访问 Commit 就可以。

GitHub 存储库网络中的破坏性操作（如上面提到的三种情况）会从标准 GitHub UI 和正常 git 操作中删除对 commit 数据的引用。

不过，删除之后，这些数据仍然存在，而且可以访问（如果你知道提交哈希值的话）。这就是 CFOR 和 IDOR 漏洞之间的联系——如果知道 commit 哈希值，就可以直接访问不属于自己的数据。

commit hash 使用 SHA-1 值。

如果用户知道他们想看的某个 commit 的 SHA-1 commit hash 值，他们可以直接通过以下端点导航到该 commit：https://github.com/<user/org>/<repo>/commit/<commit_hash>。他们会看到一条黄色横幅，说明 “此 commit 不属于此存储库的任何分支，可能属于存储库之外的 fork”。

那么，从哪里获取这些哈希值？

commit hash 值可以通过 GitHub 的 UI 进行暴力破解，特别是因为 git 协议允许在引用 commit 时使用短 SHA-1 值。短 SHA-1 值是避免与其他 commit hash 值发生冲突时所需的最少字符数，绝对最小值为 4。所有 4 字符 SHA-1 值的密钥空间为 65,536 (16^4)。相对来说，暴力破解所有可能的值是比较容易的。

例如，看一下 TruffleHog 存储库中的此 commit：