개인 데이터 및 삭제된 콘텐츠에 영구적으로 액세스할 수 있습니다. GitHub 공식: 의도적으로 설계됨

最近，一个消息震惊开源社区：在 GitHub 上删掉的内容、私有存储库的数据都是可以永久访问的，而且这是官方故意设计的。

开源安全软件公司 Truffle Security 在一篇博客中详细描述了这个问题。

Truffle Security 引入了一个新术语：CFOR（Cross Fork Object Reference）：当一个存储库 fork 可以访问另一个 fork 中的敏感数据（包括来自私有和已删除 fork 的数据）时，就会出现 CFOR 漏洞。

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

以下是 Truffle Security 博客原文内容。

访问已删除 fork 存储库的数据

想象如下工作流程：

• 在 GitHub 上 fork 一个公共存储库；

• 将代码提交到你的 fork 存储库中；

• 你删除你的 fork 存储库。

那么，你提交给 fork 的代码应该是不能访问了对吧，因为你把 fork 存储库删除了。然而它却永久可以访问，不受你控制。 

如下视频所示，fork 一个存储库，向其中提交数据，再删除 fork 存储库，那么可以通过原始存储库访问「已删除」的提交数据。

这种情况普遍存在。Truffle Security 调查了一家大型 AI 公司 3 个经常被 fork 的公共存储库，并从已删除的 fork 存储库中轻松找到了 40 个有效的 API 密钥。

访问已删除存储库的数据

考虑如下工作流程：

• 你在 GitHub 上有一个公共存储库；

• 用户 fork 你的存储库；

• 你在他们 fork 后提交数据，并且他们从不将其 fork 存储库与你的更新同步；

• 你删除整个存储库。

那么，用户 fork 你的存储库后你提交的代码仍然可以访问。

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

这种情况不是个例，上周就发生了这样一件事情：

Truffle Security 向一家大型科技公司提交了一个 P1 漏洞，显示他们意外地提交了一名员工 GitHub 帐户的密钥，而该帐户对整个 GitHub 机构拥有重要访问权限。该公司立即删除了存储库，但由于该存储库已被 fork，因此仍然可以通过 fork 存储库访问包含敏感数据的提交，尽管 fork 存储库从未与原始「上游」存储库同步。

也就是说，只要存储库有至少一个 fork 存储库，那么提交到公共存储库的任何代码都可以永久访问。

访问私有存储库数据

考虑如下工作流程：

• 你创建一个最终将公开的私有存储库；

• 创建该存储库的私有内部版本（通过 fork），并为不打算公开的特征提交额外的代码；

• 你将你的「上游」存储库公开，并将你的 fork 存储库保持私有。

그러면 비공개 기능 및 관련 코드를 공개적으로 볼 수 있습니다. 도구를 만든 저장소의 내부 포크와 도구의 오픈 소스 간에 커밋된 모든 코드는 공용 저장소를 통해 액세스할 수 있습니다.

"업스트림" 저장소를 공개로 설정한 후에는 개인 포크 저장소에 대한 모든 커밋이 표시되지 않습니다. 이는 비공개 "업스트림" 저장소의 가시성을 변경하면 두 개의 저장소 네트워크(비공개 버전용과 공개 버전용)가 생기기 때문입니다.

안타깝게도 이 워크플로는 오픈 소스 소프트웨어를 개발할 때 사용자와 기관이 사용하는 가장 일반적인 방법 중 하나입니다. 결과적으로 기밀 데이터가 GitHub 공개 저장소에 실수로 노출될 수 있습니다.

데이터에 액세스하는 방법은 무엇인가요?

GitHub 저장소 네트워크의 파괴적인 작업(예: 위의 3가지 시나리오)은 표준 GitHub UI 및 일반 Git 작업에서 커밋 데이터에 대한 참조를 제거합니다. 그러나 데이터는 여전히 존재하며 액세스할 수 있습니다(커밋 해시). 이는 CFOR과 IDOR 취약점 사이의 연결고리입니다.

커밋 해시는 GitHub의 UI를 통해 무차별 대입 공격이 가능합니다. 특히 git 프로토콜은 커밋을 참조할 때 짧은 SHA-1 값을 사용할 수 있도록 허용하기 때문입니다. 짧은 SHA-1 값은 다른 커밋 해시와의 충돌을 방지하는 데 필요한 최소 문자 수이며 절대 최소값은 4입니다. 모든 4자리 SHA-1 값의 키 공간은 65536(16^4)입니다. 가능한 모든 값을 무차별 대입하는 것은 비교적 쉽게 달성할 수 있습니다.

흥미롭게도 GitHub는 공개 이벤트 API 엔드포인트를 노출합니다. 또한 타사에서 관리하는 이벤트 아카이브에서 커밋 해시를 쿼리하고 저장소가 삭제된 후에도 지난 10년 동안 GitHub 외부의 모든 GitHub 이벤트를 보관할 수 있습니다.

GitHub 조항

Truffle Security는 GitHub의 VDP 프로그램을 통해 GitHub 관계자에게 조사 결과를 제출했습니다. GitHub는 "이것은 의도된 것입니다"라고 응답하고 문서를 첨부했습니다.

문서: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/what-happens-to-forks -저장소가 삭제되거나 변경될 때 가시성

Truffle Security는 GitHub의 아키텍처에 대한 투명성에 박수를 보내지만 Truffle Security는 다음과 같이 믿습니다. 일반 사용자는 개인 저장소와 공용 저장소의 분리를 보안 경계로 간주합니다. 공용 사용자는 개인 저장소의 데이터에 액세스할 수 없는 것으로 간주됩니다. 불행히도 위에서 언급한 것처럼 항상 그런 것은 아닙니다.

Truffle Security는 포크 저장소가 존재하는 한 해당 저장소 네트워크에 대한 모든 커밋(예: "업스트림" 저장소 또는 "다운스트림" 포크 저장소에 대한 커밋)이 영원히 유지된다는 결론을 내렸습니다.

Truffle Security는 공개 GitHub 리포지토리에서 손상된 키를 안전하게 수정하는 유일한 방법은 키 순환을 통해서만 가능하다는 점을 강조합니다.

GitHub의 저장소 아키텍처는 이러한 설계 결함으로 인해 어려움을 겪고 있습니다. 불행하게도 대다수의 GitHub 사용자는 저장소 네트워킹이 실제로 어떻게 작동하는지 결코 이해하지 못하며 결과적으로 보안을 손상시킬 것입니다.

^{원본 링크: https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github}

위 내용은 개인 데이터 및 삭제된 콘텐츠에 영구적으로 액세스할 수 있습니다. GitHub 공식: 의도적으로 설계됨의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!