Skip to content

2024-07-26-anyone-can-access-deleted-and-private-repository-data-on-github-◆-truffle-security-co..md

Latest commit

 

History

History
52 lines (43 loc) · 3.25 KB

2024-07-26-anyone-can-access-deleted-and-private-repository-data-on-github-◆-truffle-security-co..md

File metadata and controls

52 lines (43 loc) · 3.25 KB
Raw

Anyone can Access Deleted and Private Repository Data on GitHub ◆ Truffle Security Co.

TL;DR

GitHub允许访问已删除和私有仓库的数据，这些数据永久可用。通过跨分支对象引用（CFOR）漏洞，用户可以访问不应见的提交数据。常见工作流程中，分叉和删除仓库后，提交的代码仍可访问，导致API密钥等敏感信息泄露。GitHub已知此设计并文档化，用户应预期上述情况发生。

Summary

  1. 概述：GitHub上可以访问已删除和私有仓库的数据，这些数据永久可用。GitHub已知此情况，并有意设计成这样。

  2. 定义：引入新术语跨分支对象引用（CFOR），当一个仓库分支可以访问另一个分支的敏感数据（包括私有和已删除分支的数据）时，发生CFOR漏洞。用户通过提供提交哈希直接访问本不应可见的提交数据。

  3. 访问已删除分支数据：

    • 常见工作流程：
      1. 用户分叉公共仓库。
      2. 用户向分叉提交代码。
      3. 用户删除分叉。
    • 结果：提交的代码仍然可访问，且永久不可控。
    • 示例：调查三家大型AI公司的常见分叉公共仓库，轻松发现40个有效的API密钥。

  4. 访问已删除仓库数据：

    • 场景：
      1. 用户拥有一个公共仓库。
      2. 用户分叉该仓库。
      3. 用户在分叉后提交数据。
      4. 用户删除整个仓库。
    • 结果：分叉后提交的数据仍然可访问。
    • 解释：GitHub的仓库网络中，删除的公共“上游”仓库会将根节点角色重新分配给下游分叉，所有提交数据仍可通过任何分叉访问。

  5. 访问私有仓库数据：

    • 常见工作流程：
      1. 用户创建一个最终将公开的私有仓库。
      2. 用户通过分叉创建私有内部版本，并提交不公开的代码。
      3. 用户将“上游”仓库公开，保持分叉私有。
    • 结果：私有分叉中的代码在公开仓库中可访问。
    • 解释：私有“上游”仓库公开后，会形成两个仓库网络，私有版本和公开版本分开。

  6. 数据访问方法：

    • 直接访问提交：通过知道提交哈希，可以直接访问数据。
    • 哈希值获取：
      • 通过GitHub的UI暴力破解短SHA-1值。
      • 查询GitHub事件存档，第三方管理的事件存档保存了过去十年的所有GitHub事件，即使仓库被删除。

  7. GitHub政策：

    • GitHub已知此设计并明确文档化，用户应预期上述情况发生。
    • 普通用户视私有和公共仓库的分离为安全边界，但实际情况并非如此。

  8. 影响：

    • 只要存在一个分叉，任何提交到该仓库网络的数据将永久存在。
    • GitHub的仓库架构导致这些设计缺陷，大多数用户不会理解仓库网络的实际工作方式，从而降低安全性。
    • 随着秘密扫描的发展，可能需要更谨慎地处理不属于我们自己的秘密（例如，属于分叉仓库的秘密）。
    • 这些场景未涵盖GitHub存储已删除仓库数据的所有方式。