- GitHub에서는 삭제된 포크, 삭제된 저장소, 심지어 비공개 저장소의 데이터에 액세스할 수 있음
- 이는 GitHub에서 알고 있으며 의도적으로 설계된 방식임
- GitHub를 사용하는 모든 조직에 엄청난 공격 벡터가 되므로 "크로스 포크 객체 참조(CFOR)"라는 새로운 용어를 도입함
- CFOR 취약점은 한 저장소 포크가 다른 포크(비공개 및 삭제된 포크의 데이터 포함)의 중요한 데이터에 액세스할 수 있을 때 발생함
삭제된 포크 데이터 액세스하기
- GitHub에서 일반적인 워크플로우를 고려해 보면 공용 저장소를 포크하고, 포크에 코드를 커밋한 다음, 포크를 삭제하는 경우가 있음
- 포크에 커밋한 코드는 여전히 액세스 가능하며 영원히 액세스 가능함
- 커밋 해시를 알아야 보호된다고 생각할 수 있지만 해시는 발견할 수 있음
- 삭제된 포크에서 데이터를 찾는 것은 꽤 자주 발생함
삭제된 저장소 데이터 액세스하기
- GitHub에 공용 저장소가 있고, 사용자가 저장소를 포크하고, 포크 후에 데이터를 커밋한 다음 전체 저장소를 삭제하는 시나리오를 고려해 보면,
- 포크 이후에 커밋한 코드는 여전히 액세스 가능함
- GitHub는 저장소와 포크를 저장소 네트워크에 저장하며, 원래 "업스트림" 저장소가 루트 노드 역할을 함
- 포크된 공용 "업스트림" 저장소가 "삭제"되면 GitHub는 루트 노드 역할을 다운스트림 포크 중 하나에 재할당함
- 그러나 "업스트림" 저장소의 모든 커밋은 여전히 존재하며 모든 포크를 통해 액세스할 수 있음
비공개 저장소 데이터 액세스하기
- GitHub에서 새로운 도구를 오픈 소스화하는 일반적인 워크플로우를 고려해 보면,
- 결국 공개될 비공개 저장소를 만들고, 해당 저장소의 비공개 내부 버전을 만들어(포크를 통해) 공개하지 않을 기능에 대한 추가 코드를 커밋하고, "업스트림" 저장소를 공개하고 포크를 비공개로 유지하는 경우가 있음
- 비공개 기능 및 관련 코드(2단계에서)가 공개적으로 볼 수 있는지 여부는 공용 저장소에서 액세스할 수 있음
- "업스트림" 저장소를 공개한 후 비공개 포크에 커밋한 모든 내용은 볼 수 없음
실제로 데이터에 어떻게 액세스하나요?
- 커밋에 직접 액세스함으로써
- GitHub의 저장소 네트워크에서 파괴적인 작업(위에서 언급한 3가지 시나리오와 같은)은 표준 GitHub UI 및 일반 git 작업에서 커밋 데이터에 대한 참조를 제거함
- 그러나 이 데이터는 여전히 존재하며(커밋 해시를 알고 있는 경우) 액세스할 수 있음
- 커밋 해시는 SHA-1 값이며, 사용자가 보려는 특정 커밋의 SHA-1 커밋 해시를 알고 있다면 https://github.com/<user/org>/…; 엔드포인트에서 해당 커밋으로 직접 이동할 수 있음
- 커밋 해시는 GitHub의 UI를 통해 무차별 대입될 수 있음
- GitHub의 public events API 엔드포인트를 통해 커밋 해시를 쿼리할 수도 있음
GitHub의 정책
- 최근 GitHub의 VDP 프로그램을 통해 이러한 결과를 제출했으며, GitHub는 저장소가 이와 같이 작동하도록 설계되었음을 명확히 했음
- 문서를 검토한 결과 GitHub가 위에서 문서화된 인스턴스에서 사용자가 기대해야 하는 바를 명확하게 문서화했음을 알 수 있음
영향
- 포크가 하나라도 존재하는 한 해당 저장소 네트워크에 대한 모든 커밋("업스트림" 저장소 또는 "다운스트림" 포크의 커밋)이 영원히 존재할 것임
- GitHub의 저장소 아키텍처는 이러한 설계 결함을 필요로 하며, 대다수의 GitHub 사용자는 저장소 네트워크가 실제로 어떻게 작동하는지 이해하지 못하고 덜 안전할 것임
- 시크릿 스캐닝이 진화함에 따라 저장소 네트워크의 모든 커밋을 스캔할 수 있게 되면 자신의 것이 아닌 시크릿에 대해 경고할 수 있게 됨
- 이러한 3가지 시나리오는 충격적이지만 GitHub가 저장소에서 삭제된 데이터를 저장할 수 있는 모든 방법을 다루지는 않음
GN⁺의 의견
- 이 기사는 GitHub를 사용하는 조직에게 중요한 보안 문제를 제기함. 삭제되거나 비공개로 설정된 저장소의 데이터가 여전히 액세스 가능하다는 점은 충격적임. 이는 GitHub의 저장소 네트워크 아키텍처로 인한 근본적인 설계 결함으로 보임
- 개발자들은 이러한 문제를 인식하고 중요한 데이터나 시크릿을 GitHub에 커밋할 때 주의해야 함. 일단 공개 저장소에 푸시되면 영원히 액세스 가능할 수 있음. 중요한 시크릿이 유출된 경우 키 로테이션을 통해서만 완전히 해결할 수 있음
- GitHub는 이러한 문제를 투명하게 공개하고 문서화하고 있지만, 대다수의 사용자는 저장소 네트워크의 작동 방식을 완전히 이해하지 못할 것임. GitHub는 이러한 문제에 대한 인식을 높이고 사용자를 교육하는 데 더 많은 노력을 기울여야 함
- 다른 버전 관리 시스템에서도 이와 유사한 문제가 존재할 수 있음. 개발자와 조직은 중요한 데이터를 관리할 때 사용 중인 도구의 아키텍처와 한계를 잘 이해해야 함
- 중요한 데이터의 유출을 방지하기 위해서는 엄격한 접근 통제와 최소 권한의 원칙 적용, 정기적인 시크릿 스캐닝과 모니터링 등 다각도의 보안 조치가 필요함. 무엇보다 개발자의 높은 보안 인식이 중요함