Megalodon 공격, 6시간 만에 GitHub 저장소 5,561개 침해

Megalodon이라 명명된 GitHub CI/CD 공급망 공격이 자동화된 대규모 저장소 침해의 새로운 기준을 세웠습니다. 단 6시간이라는 짧은 시간 동안 공격자들은 5,561개의 GitHub 저장소에 걸쳐 5,718건의 악성 코드 업데이트를 푸시했으며, 가짜 신원을 이용해 클라우드 자격 증명, SSH 키, 소스 코드 시크릿을 조용히 탈취하도록 설계된 워크플로 파일을 주입했습니다. 이 캠페인의 압도적인 속도와 규모는 대부분의 팀이 실시간으로 탐지하거나 대응할 수 있는 능력을 초과하는, 산업화된 파이프라인 공격으로의 전환을 예고합니다.

Megalodon 공격의 작동 방식: 가짜 신원과 자동화된 워크플로 주입

Megalodon의 배후 공격자들은 제로데이 익스플로잇이나 최종 사용자 기기에 전달되는 정교한 악성 코드에 의존하지 않았습니다. 대신 그들은 GitHub의 CI/CD 인프라 자체가 가진 신뢰성을 악용했습니다. 가짜 기여자 신원을 구성하여 풀 리퀘스트를 제출하거나, GitHub Actions가 자동화된 빌드 및 배포 파이프라인을 정의하는 데 사용하는 YAML 파일, 즉 워크플로 구성 파일을 직접 수정했습니다.

악성 워크플로 파일이 저장소에 삽입되면, 파이프라인이 트리거될 때마다 — 일반적으로 푸시 이벤트나 풀 리퀘스트 병합 시 — 자동으로 실행됩니다. 이 실행은 GitHub 자체의 러너 환경 내에서 이루어지며, 해당 환경은 저장소 시크릿, 환경 변수, 클라우드 공급자에 범위가 지정된 토큰에 접근할 수 있는 경우가 많습니다. Megalodon 워크플로는 저장소 관리자가 변경 사항을 검토할 틈도 없이, 이 접근 창을 이용해 공격자가 통제하는 인프라로 데이터를 외부로 유출했습니다.

이 캠페인의 결정적인 특징은 자동화입니다. 6시간 만에 5,500개 이상의 저장소에 걸쳐 거의 5,720건에 달하는 별도의 코드 푸시를 실행하는 것은 수동으로 할 수 있는 작업이 아닙니다. 이를 위해서는 대상을 식별하고, 가짜 신원으로 인증하며, 그럴듯해 보이는 워크플로 수정본을 만들고, 이를 병렬로 제출할 수 있는 스크립트 기반 도구가 필요합니다. 이러한 수준의 자동화는 어떤 인적 모니터링 팀도 추적할 수 없는 속도로 공격 표면이 확장되었음을 의미합니다.

어떤 자격 증명이 도난당했으며 개발자에게 왜 중요한가

각 악성 워크플로의 페이로드는 자격 증명 수집이었습니다. 대상에는 클라우드 공급자 자격 증명, 특히 GitHub Secrets에 저장되거나 워크플로 환경 변수 내에 참조된 AWS, GCP, Azure 액세스 키가 포함되었습니다. 서버 접근이나 서비스 간 인증에 사용되는 SSH 개인 키, 그리고 소스 코드나 구성 파일에 평문으로 포함된 모든 시크릿도 대상이 되었습니다.

이러한 유형의 자격 증명은 연쇄적인 위험을 초래합니다. 광범위한 권한을 가진 IAM 역할에 연결된 AWS 액세스 키가 도난당하면 공격자는 몇 분 안에 인프라를 구축하고, 데이터 저장소를 유출하거나, 연결된 서비스로 수평 이동할 수 있습니다. SSH 키는 원래 침해가 탐지되고 GitHub 저장소가 정리된 후에도 오랫동안 프로덕션 서버에 대한 지속적인 접근을 제공할 수 있습니다. 이 데이터의 가치는 저장소 자체를 훨씬 넘어섭니다.

이것은 가상의 위험 패턴이 아닙니다. 올해 초, CISA 계약업체가 공개 GitHub 저장소에 AWS 키와 평문 비밀번호를 노출시킨 사건은 개발 환경에서의 자격 증명 관리 실패가 전담 보안 책임을 가진 조직에도 영향을 미친다는 것을 보여주었습니다. Megalodon은 개별적인 인적 오류가 이미 반복적으로 입증한 동일한 익스플로잇 경로를 단순히 산업화한 것입니다.

또한 자격 증명 탈취 도구와 파이프라인 자체도 공격 대상이 된다는 점을 짚고 넘어갈 필요가 있습니다. 최근의 Bitwarden CLI 공급망 공격은 개발자들이 시크릿을 관리하는 데 사용하는 도구조차 업스트림에서 침해될 수 있음을 보여주었으며, 이는 신뢰 체인이 단일 저장소나 파이프라인 구성을 넘어서까지 확장된다는 것을 의미합니다.

개발 팀을 위한 심층 방어: 시크릿 관리, 암호화된 통신, 접근 제어

Megalodon은 오픈 소스 및 프라이빗 저장소 모두에서 공통적으로 나타나는 여러 취약점을 악용했습니다. 이를 해결하려면 단일 통제 수단이 아닌 다층적인 접근 방식이 필요합니다.

첫째, 시크릿은 워크플로 파일, 환경 구성 파일, 소스 코드 내에 절대 평문으로 저장해서는 안 됩니다. GitHub의 암호화된 Secrets 기능이 기본 수단을 제공하지만, 해당 시크릿은 최소 권한 원칙을 따라야 합니다. 스테이징 환경에 배포하는 워크플로에는 프로덕션 데이터베이스 자격 증명이 필요하지 않습니다. 시크릿 범위를 좁히면 워크플로가 침해되었을 때의 피해 반경을 제한할 수 있습니다.

둘째, 브랜치 보호 규칙과 워크플로 파일 변경에 대한 필수 검토자를 설정하면 자동화된 공격이 반드시 우회해야 하는 인적 검문소를 만들 수 있습니다. .github/workflows/ 파일에 대한 모든 수정 전에 최소 한 명의 승인된 검토를 요구하면 Megalodon이 의존했던 급속한 자동화 주입을 늦추거나 차단할 수 있습니다.

셋째, 서드파티 GitHub Actions를 부동 태그가 아닌 특정 커밋 SHA에 고정하면, 침해된 액션 게시자가 태그를 조용히 악성 코드를 가리키도록 업데이트하는 별개이지만 관련된 공격 벡터를 방지할 수 있습니다. 이는 최근 여러 GitHub Actions 공급망 사건의 메커니즘이었습니다.

마지막으로, 워크플로 실행에 대한 감사 로깅과 이상 탐지는 예상치 못한 외부 네트워크 연결이나 비정상적인 시크릿 접근 패턴을 드러낼 수 있습니다. GitHub의 감사 로그 API와 서드파티 CI/CD 보안 도구는 이러한 신호를 파악하는 데 도움이 될 수 있습니다.

지금 당장 GitHub 저장소와 CI/CD 파이프라인을 감사하는 방법

조직에서 활성 CI/CD 파이프라인이 있는 GitHub 저장소를 유지 관리하고 있다면, 즉시 우선순위를 두어야 할 몇 가지 조치가 있습니다.

.github/workflows/ 아래의 모든 파일에서 최근에 추가되거나 수정된 항목, 특히 인식하지 못하는 기여자가 추가한 항목을 검토하십시오. 기본 브랜치 보기만이 아닌, 워크플로 파일의 커밋 기록을 구체적으로 확인하십시오.

공격 기간 동안 활성 상태였거나 노출되지 않았다고 확신할 수 없는 모든 시크릿을 교체하십시오. 클라우드 자격 증명의 경우, 동일한 기간 동안의 비정상적인 API 호출에 대해 공급자 측 접근 로그를 검토하십시오.

저장소 기여자와 애플리케이션 중 쓰기 권한을 가진 대상을 감사하십시오. 가짜 신원 공격은 코드를 푸시할 수 있는 능력에 의존하므로, 기여자 권한을 강화하고 워크플로 변경에 대한 필수 검토를 활성화하면 핵심 진입점이 제거됩니다.

마지막으로, 모든 커밋에서 실행되어 자격 증명이 저장소에 커밋되기 전에 탐지하는 전용 시크릿 스캔 도구 도입을 고려하십시오. 여러 오픈 소스 및 상용 옵션이 GitHub와 직접 통합됩니다.

이것이 여러분에게 의미하는 바

Megalodon 캠페인은 CI/CD 파이프라인이 왜 주요 공격 표면이 되었는지를 실질적으로 보여주는 사례입니다. 파이프라인 보안을 애플리케이션 보안보다 부차적인 것으로 취급하는 개발자와 보안 팀은 자신들의 가장 민감한 자격 증명으로 향하는 활짝 열린 경로를 방치하고 있는 것입니다.

이번 주 시크릿 감사부터 시작하십시오. 누가 워크플로 파일을 수정할 수 있는지 검토하고, 안전하다고 확인할 수 없는 자격 증명을 교체하며, 아직 설정하지 않았다면 기본 브랜치에 브랜치 보호를 활성화하십시오. Megalodon 공격의 속도를 고려하면, 경보가 울리는 시점에 이미 유출이 완료되었을 수 있습니다. 예방과 접근 범위 설정만이 유일한 신뢰할 수 있는 방어 수단입니다.