CISA 관리자, 깃허브에 AWS GovCloud 키와 내부 비밀번호를 공개해버림

‘Private-CISA’라는 공개 저장소

• 미국 사이버보안·인프라보안청(CISA) 계약자가 공개 깃허브 저장소에 민감한 내부 자료를 대량으로 올려둔 사건이 드러남

  • 저장소 이름은 “Private-CISA”였지만 실제로는 공개 상태였음
  • 내부 CISA/DHS 인증정보, 클라우드 키, 토큰, 평문 비밀번호, 로그, 빌드·테스트·배포 관련 파일이 포함됐다고 보도됨
  • 보안 전문가들은 최근 정부 데이터 유출 중에서도 상당히 심각한 축이라고 평가함

• 이 사건은 GitGuardian 연구원이 먼저 발견함

  • GitGuardian은 공개 코드 저장소를 스캔해 노출된 비밀정보를 찾는 보안 업체임
  • 연구원 기욤 발라동은 저장소 소유자가 경고에 반응하지 않고, 노출 정보가 너무 민감해 KrebsOnSecurity에 제보함
  • 이후 보안 컨설팅 업체 Seralys도 CISA에 알렸고, 저장소는 내려감

노출된 내용이 꽤 심각함

• 파일 중 하나에는 AWS GovCloud 서버 3개의 관리자급 인증정보가 들어 있었다고 함

  • 파일명은 “importantAWStokens”였음
  • Seralys 창업자 필리프 카투렐리는 키가 아직 유효한지, 어떤 내부 시스템에 접근 가능한지 확인하는 수준으로 테스트했다고 밝힘
  • 그 결과 3개 AWS GovCloud 계정에 고권한으로 인증 가능했다고 함

• 또 다른 파일에는 내부 CISA 시스템의 사용자명과 비밀번호가 평문으로 들어 있었음

  • “AWS-Workspace-Firefox-Passwords.csv” 파일에 수십 개 내부 시스템 계정이 적혀 있었다고 함
  • 그중에는 “LZ-DSO”라는 시스템도 있었고, 이는 기관의 보안 코드 개발 환경인 “Landing Zone DevSecOps”로 보인다고 설명됨
  • 비밀번호를 CSV에 평문으로 저장한 시점에서 이미 경보음이 크게 울리는 상황임

• 더 황당한 포인트는 깃허브의 기본 비밀정보 차단 기능을 꺼둔 흔적이 있었다는 점임
  • 발라동은 커밋 로그에 SSH 키나 기타 비밀정보 공개를 막는 기본 설정을 비활성화한 흔적이 보인다고 설명함
  • “평문 CSV 비밀번호, 깃에 백업, 비밀정보 탐지 기능을 끄는 명령까지 있었다”는 코멘트가 나옴
  • 개인 실수라 해도, 조직의 내부 작업 방식이 얼마나 허술했는지 보여주는 단서가 될 수 있음

공급망 공격으로 이어질 수 있었던 이유

• 내부 아티팩토리는 공격자에게 특히 맛있는 표적임

  • 아티팩토리는 조직이 소프트웨어를 빌드할 때 쓰는 패키지와 산출물을 모아두는 저장소임
  • 여기에 악성 패키지를 넣으면 새로 빌드되는 소프트웨어 곳곳에 백도어가 배포될 수 있음
  • 카투렐리는 “옆으로 이동하기에 최적의 장소”라고 표현함

• 저장소 사용 패턴은 정리된 프로젝트라기보다 개인 작업용 동기화 폴더에 가까웠다고 함

  • CISA 관련 이메일과 개인 이메일이 모두 보인다는 점도 언급됨
  • 2025년 11월 13일 생성된 저장소에 이후 꾸준히 커밋이 올라온 정황이 있음
  • 한 보안 전문가는 업무 노트북과 집 컴퓨터 사이에서 파일을 맞추려고 쓴 것 같다고 추정함

sequenceDiagram
    participant 계약자
    participant 공개깃허브
    participant 보안연구원
    participant CISA
    participant 내부시스템
    계약자->>공개깃허브: 키와 비밀번호가 든 파일 커밋
    공개깃허브->>보안연구원: 공개 저장소에서 비밀정보 탐지
    보안연구원->>CISA: 민감 정보 노출 신고
    보안연구원->>내부시스템: AWS 키 유효성 제한 확인
    CISA->>공개깃허브: 저장소 오프라인 처리
    공개깃허브-->>내부시스템: 일부 AWS 키는 48시간 더 유효

대응도 깔끔하지 않았음

• CISA는 현재 조사 중이며, 민감 데이터가 침해됐다는 징후는 없다고 밝힘

  • 다만 노출 기간에 대해서는 답하지 않았음
  • 저장소는 신고 직후 내려갔지만, 카투렐리에 따르면 노출된 AWS 키는 이상하게도 48시간가량 더 유효했음
  • 클라우드 키 유출 대응에서 즉시 폐기와 권한 회수가 기본이라는 점을 생각하면 꽤 불안한 대목임

• 저장소는 Nightwing이라는 정부 계약업체 직원이 관리한 것으로 확인됨

  • Nightwing은 별도 코멘트를 거부하고 CISA로 문의를 넘김
  • CISA는 예산과 인력 축소 상태에 놓여 있고, 두 번째 트럼프 행정부 시작 이후 인력의 거의 3분의 1을 잃었다는 배경도 기사에 언급됨
  • 인력 부족이 변명은 아니지만, 보안 운영 통제의 빈틈이 커질 수 있는 조건인 건 맞음

• 쉽게 추측 가능한 비밀번호까지 쓰였다는 점도 치명적임

  • 일부 내부 리소스 비밀번호는 플랫폼 이름 뒤에 현재 연도를 붙인 형태였다고 함
  • 외부 노출이 없었더라도 내부망에 들어온 공격자가 권한을 넓히는 데 매우 좋은 재료임
  • 보안 기관에서 이런 패턴이 나왔다는 게 이번 사건의 가장 씁쓸한 부분임

기술 맥락

• 이 사건에서 제일 중요한 건 ‘키가 깃허브에 올라갔다’보다 ‘그 키가 어떤 배포 체인에 닿아 있었나’예요. AWS GovCloud 계정, 내부 개발 환경, 아티팩토리까지 연결되면 단순 계정 탈취가 아니라 소프트웨어 공급망 전체가 공격면이 되거든요.

• Secrets detection을 끈 흔적이 치명적인 이유도 여기에 있어요. 사람은 실수할 수 있으니 저장소, CI, 클라우드 쪽에서 여러 번 막아야 하는데, 그중 첫 번째 안전망을 직접 꺼버린 셈이에요.

• Artifactory 접근권은 특히 위험해요. 공격자가 소스코드를 직접 고치지 않아도, 빌드가 의존하는 패키지를 바꾸면 정상 배포 파이프라인을 타고 악성 코드가 퍼질 수 있거든요. 그래서 패키지 저장소 권한은 운영 서버 권한만큼 엄격하게 봐야 해요.

• 유출 대응에서 48시간 키가 살아 있었다는 부분도 실무적으로 뼈아파요. 클라우드 키가 공개 저장소에 노출되면 즉시 폐기, 접근 로그 확인, 권한 범위 점검, 관련 토큰 회전이 한 세트로 움직여야 하거든요.