토큰은 만료되지만, 키는 그렇지 않습니다.
GitHub App 인증은 최대 10분의 수명을 가진 JSON Web Token(JWT)을 생성하는 private key에 의존합니다. 이 JWT는 최대 1시간 동안 유효한 설치 액세스 토큰을 요청합니다. GitHub는 이러한 하위 토큰 만료를 엄격하게 시행하여 일시적인 액세스라는 환상을 만들어냅니다.
그러나 이러한 자격 증명의 원천인 루트 private key에는 기본적으로 설정된 TTL(Time-to-Live)이 없습니다. 명시적으로 취소되지 않는 한 영구적으로 새로운 토큰을 생성할 수 있습니다. 이러한 근본적인 아키텍처 선택은 손상되거나 잊혀진 키가 그것이 생성하는 단기 토큰과 달리 지속적인 위협으로 남는다는 것을 의미합니다.
일부에서는 이를 플랫폼에서 강제하는 만료 기한이 없는 SSH 키 동작과 유사하다고 주장하지만, GitHub App 권한의 범위는 위험을 극적으로 높입니다. 앱은 종종 다음과 같은 광범위한 다중 리포지토리 액세스 권한을 가집니다:
- 조직 관리자 권한
- 비공개 코드에 대한 쓰기 액세스
- 자체 호스팅 러너 및 워크플로우 실행 제어
GitGuardian의 연구에 따르면 474개의 활성 키가 발견되었으며, 그중 44개는 전체 조직 관리자 권한을 부여했습니다. 미국 CDC와 연결된 한 키는 유출된 후 17개월 동안 비공개 코드에 대한 쓰기 액세스를 제공했습니다. 이는 관리되지 않는 GitHub App 키가 일반적인 SSH 키를 훨씬 뛰어넘는 중대하고 지속적인 거버넌스 위험을 초래하는 이유를 잘 보여줍니다.
474개의 유출된 키가 여전히 문을 열어두고 있습니다
GitGuardian의 최근 연구는 냉혹한 현실을 밝혀냈습니다. 50만 개 이상의 노출된 RSA 키 중 4,802개가 GitHub App ID와 연결되어 있었습니다. 놀랍게도 이 중 474개의 키는 공개적으로 노출되었음에도 여전히 인증이 가능했으며, 이는 440개의 서로 다른 앱을 나타냅니다. 이는 보안 체인의 치명적인 취약성을 보여줍니다.
이러한 지속적인 노출의 영향은 심각합니다. 44개의 유효한 앱이 전체 조직 관리자 액세스 권한을 가지고 있었고, 72%는 비공개 리포지토리를 읽을 수 있었습니다. 또한 207개의 앱이 쓰기 권한을 보유하고 있어 임의의 코드 삽입 및 파이프라인 오염을 가능하게 하며, 이는 심각한 공급망 보안 위험입니다.
이 문제의 지속성은 우려스럽습니다. 한 Crusher.dev 키는 2020년부터 공개 상태였으며 여전히 활성 상태였습니다. 미국 CDC와 연결된 키는 노출 후 17개월 동안 유효했던 것으로 보고되었습니다. 널리 사용되는 또 다른 앱인 "Access Tokens for GitHub Actions"는 2024년 1월에 private key를 유출하여 방위 산업체인 Sierra Nevada Corp를 포함한 약 300개의 조직에 영향을 미쳤습니다.
이러한 사례들은 GitHub App private key의 위험성을 강조합니다. 그들이 생성하는 단기 JWT 및 설치 액세스 토큰과 달리, 루트 private key 자체에는 기본 만료 기한이 없습니다. 이러한 아키텍처적 간과로 인해 단 한 번의 유출이 영구적인 보안 위협으로 변하며, 즉각적인 주의와 강력한 키 순환 전략이 요구됩니다.
잊혀진 앱은 공급망의 거점이 될 수 있습니다
잊혀진 앱은 중요한 공급망 거점을 제공합니다. 유출된 키를 통해 공격자는 비공개 코드를 읽고, 리포지토리에 쓰며, 워크플로우를 조작하거나 자체 호스팅 러너를 관리할 수 있습니다. 이러한 액세스는 코드 변조, CI/CD 침해, 궁극적으로는 조직 장악을 직접적으로 가능하게 합니다.
오래된 통합은 간과되기 쉽습니다. GitGuardian은 활성 키가 있는 440개의 개별 앱 중 59%가 단 하나의 설치만 가지고 있으며, 이는 주로 임시 자동화를 위한 것임을 발견했습니다. 엔지니어가 떠나거나 프로젝트가 중단되면 이러한 앱의 소유권이 사라지는 경우가 많아 지속적인 취약점이 남게 됩니다. 2020년부터 노출된 Crusher.dev 앱 키는 프로젝트 유지 관리가 중단된 후에도 수년간 활성 상태로 유지되었습니다.
예를 들어, 미국 질병통제예방센터(CDC) 조직은 Microsoft Azure 인프라에 대한 액세스를 중재하는 비공개 저장소에 대한 쓰기 권한이 있는 유출된 개인 키를 17개월 동안 보유하고 있었습니다. 마찬가지로, 널리 사용되는 "Access Tokens for GitHub Actions" 앱도 개인 키를 유출하여 약 300개의 조직을 노출시켰습니다.
유효한 키가 즉각적인 악용을 증명하는 것은 아니지만, 지속적인 노출을 의미합니다. 공격자는 유효한 키를 획득하면 언제든지 앱에 부여된 권한으로 행동할 수 있습니다. 이러한 지속적인 위협에 대한 자세한 내용은 GitGuardian의 연구를 참조하십시오: GitHub App Private Keys: 474 Leaked Keys Still Work. 이는 공급망 위험을 완화하기 위해 GitHub App private keys와 관련 권한을 엄격하게 관리해야 할 필요성을 강조합니다.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
다운타임 없이 교체하고, 소유자가 없는 것은 폐기하십시오
앱 소유자는 강력한 키 교체 전략을 구현해야 합니다. 새로운 private key를 생성하고, 배포 및 기능을 확인한 다음, 이전 키를 취소하십시오. GitHub는 앱당 최대 25개의 활성 private key를 허용하므로 서비스 중단 없이 단계적인 교체가 가능합니다.
문서화된 교체 주기와 안전한 키 저장 프로토콜을 수립하고, 개발자가 소유한 공개 포크를 포함한 모든 저장소에 secret scanning을 통합하십시오. 최소 권한 액세스를 시행하여 앱 권한을 기능에 엄격히 필요한 저장소와 작업으로만 제한하십시오. 이는 잠재적인 침해의 피해 범위를 최소화합니다.
조직 관리자는 설치된 앱을 감사해야 하는 중요한 임무를 안고 있습니다. 모든 통합에 대해 책임 있는 소유자를 식별하고 지정하십시오. 버려지거나 유지 관리되지 않는 앱은 지속적인 발판을 마련하려는 공격자의 주요 표적이 되므로 즉시 제거하십시오.
마지막으로, 남아 있는 모든 앱이 필요한 최소한의 권한으로만 작동하는지 확인하십시오. 이러한 액세스 제어를 검토하고 강화하면 공격 표면이 줄어들어, 잊혀진 앱이 조직의 가장 민감한 자산으로 향하는 열린 문이 되는 것을 방지할 수 있습니다.
자주 묻는 질문
GitHub App private keys는 자동으로 만료됩니까?
아니요. GitHub App private keys에는 내장된 만료 날짜가 없으므로 소유자가 직접 교체하고 취소해야 합니다.
만료되지 않은 GitHub App 키는 어떻게 사용될 수 있습니까?
이 키는 단기 JWT를 서명하는 데 사용할 수 있으며, 이는 최대 1시간 동안 지속되는 설치 액세스 토큰으로 교환될 수 있습니다.
한 번에 활성화할 수 있는 GitHub App private keys는 몇 개입니까?
GitHub는 앱당 최대 25개의 private key를 허용하므로 팀이 이전 키를 삭제하기 전에 교체 키를 배포할 수 있습니다.
유지 관리되지 않는 앱에 대해 조직은 무엇을 해야 합니까?
설치된 GitHub Apps를 감사하고, 오래되었거나 소유자가 없는 통합을 제거하며, 남아 있는 앱에 부여된 권한과 저장소를 제한하십시오.