GitHub 계정 탈취: wfx-loot 비밀키 유출

GitHub wfx-loot 캠페인이란 무엇인가요?

wfx-loot는 공격자가 탈취한 GitHub 자격 증명으로 해당 계정이 쓰기 권한을 가진 저장소에 악성 워크플로를 밀어 넣어 GitHub Actions 시크릿과 클라우드 자격 증명을 훔치는 캠페인입니다 ^[1]. 이를 처음 보고한 Aikido Security는 공격자가 악성코드를 부르는 이름(“wfx”)과 탈취한 시크릿을 가리키는 단어(“loot”)를 따서 이름을 붙였습니다 ^[1]. SafeDep도 최초 보고를 Aikido의 공으로 돌립니다 ^[5].

StepSecurity는 같은 악성코드를 “wfx”라고 부르며 핵심을 강조합니다. 공격자는 GitHub Actions의 버그를 악용하지 않습니다 ^[2]. 대신 실제 개발자와 봇 계정의 유효한 토큰을 사용해 개발자처럼 풀 리퀘스트를 열고 커밋을 푸시합니다 ^[2][4].

Aikido는 주된 목적이 소프트웨어 패키지를 통한 확산이 아니라 CI 시크릿이라고 보지만, 자동 배포 트리거를 통해 페이로드가 최소 하나의 Packagist 패키지와 하나의 Go 패키지에 도달하기도 했습니다 ^[1]. BleepingComputer는 Aikido의 분석을 근거로 침해된 계정 일부가 대형 조직 소속이었다고 보도합니다 ^[3].

wfx-loot 공격의 규모는 어느 정도인가요?

Aikido는 침해된 계정 4,837개가 저장소 61,764곳에 탐색용 풀 리퀘스트를 열었고, 악성코드는 최소 1,806개 저장소에서 실행되었다고 집계합니다 ^[1]. 연구자마다 캠페인이 진행 중인 서로 다른 시점에 GitHub를 검색했기 때문에 수치가 조금씩 다릅니다.

• Aikido: 계정 4,837개, 저장소 61,764곳. 풀 리퀘스트 10,431건이 계정 소유가 아닌 저장소로 들어갔고, 92%는 아직 열려 있으며, 침해된 사용자 최소 50명이 npm, Go, Packagist, PyPI, crates에 패키지를 배포합니다 ^[1].
• Aikido(요약 수치): 최소 1,835개 저장소에서 페이로드가 실행되어 자격 증명이 탈취되었으며, BleepingComputer는 이 수치를 씁니다 ^[1][3].
• StepSecurity: 11월 12일 07:40 UTC 기준 63,000건이 넘는 탐색용 풀 리퀘스트가 있고 약 90%가 아직 열려 있습니다 ^[2].
• SafeDep: 11월 10일부터 12일 사이 악성 커밋을 받은 저장소는 8,093곳이며, SecurityWeek가 지적하듯 이것이 악성코드가 실행되었다는 뜻은 아닙니다 ^[5][4].

Aikido는 영향을 받은 저장소에서 실행 로그가 삭제되었기 때문에 자사의 실행 건수가 피해를 과소 반영할 수 있다고 경고합니다 ^[1].

wfx-loot 악성코드는 어떻게 작동하나요?

탈취된 토큰이 쓸 수 있는 저장소마다 공격자는 탐색하고, 페이로드를 푸시한 뒤, 약 1분 안에 흔적을 정리합니다 ^[1].

1. 탐색: wfx-docs라는 브랜치에서 “docs: dependency audit notes”라는 제목의 풀 리퀘스트가 작은 메모 파일을 추가합니다. StepSecurity는 “이 풀 리퀘스트 자체는 아무 일도 하지 않는다”고 말하며, 이는 토큰에 쓰기 권한이 있음을 보여 줄 뿐입니다 ^[2][4].
2. 페이로드: 약 1,500줄의 셸 스크립트가 세 가지 방식 중 하나로 들어옵니다. 기존 워크플로에 주입(“ci: refresh build cache”), 스크립트와 npm postinstall 훅의 조합(“chore: add ci helper”), 또는 일회용 chore/ 브랜치의 새 워크플로(“chore: add dependency audit workflow”)입니다 ^[1].
3. 정리: 공격자는 변경을 되돌리고 워크플로 실행과 그 로그를 삭제합니다 ^[1]. 비어 있는 실행 번호가 유일한 흔적인 경우가 많습니다 ^[1].

스크립트는 GitHub Actions 시크릿과 토큰, 러너의 전체 환경, AWS, Azure, Google Cloud, Docker, Kubernetes, npm, PyPI, SSH 등의 자격 증명 파일, 셸 기록, AI 제공업체와 개발자 도구의 키를 수집합니다 ^[1][3]. 러너에서 실행 중인 프로세스의 메모리까지 읽습니다 ^[1][4]. Aikido는 분석한 사본이 탈취한 데이터를 오직 HTTP POST로 공격자가 통제하는 서버에 보낸다는 사실을 발견했습니다 ^[1]. StepSecurity는 나중에 변화를 포착했습니다. 11월 12일 05:30 UTC 무렵부터 새 사본은 데이터를 Telegram으로만 보내므로, 공개된 서버 주소를 차단하는 것만으로는 더 이상 막을 수 없습니다 ^[2].

시크릿을 교체하는 것만으로는 왜 충분하지 않나요?

악성코드가 자격 증명 교체 후에도 살아남는 백도어를 심으려 하기 때문입니다 ^[1][2]. Aikido는 세 가지 지속성 수법을 설명합니다 ^[1].

• 위조된 상태 검사: Aikido에 따르면 저장소의 필수 검사 이름을 사용해 가짜 “성공” 검사를 게시하며, 이는 브랜치 보호의 병합 관문을 통과시킬 수 있습니다 ^[1]. StepSecurity는 자신들이 조사한 샘플 101개 모두에서 이 기능이 꺼져 있음을 발견했습니다 ^[2].
• AWS 신뢰 정책 재작성: 역할의 신뢰 정책을 모든 AWS 계정에 허용하도록 설정할 수 있습니다 ^[1].
• Azure 페더레이션 ID 주입: Azure AD 애플리케이션에 wfx-ci-…라는 이름의 페더레이션 자격 증명을 추가해, 침해된 저장소의 워크플로가 저장된 시크릿 없이 인증하게 할 수 있습니다 ^[1].

또한 GitHub OIDC 토큰을 발급해 AWS, Google Cloud, Azure 세션으로 교환하고, 다른 IAM 역할로 연쇄 이동하며, 수명이 긴 AWS 액세스 키를 만들 수 있습니다 ^[1][3]. 그래서 StepSecurity는 “교체만으로는 해결되지 않으므로 지속성을 제거하라”고 말합니다 ^[2].

내 GitHub 저장소가 피해를 입었는지 어떻게 확인하나요?

11월 10일 이후의 탐색용 풀 리퀘스트와 공격자의 커밋 메시지를 검색한 다음, 워크플로 실행 번호의 빈 곳을 찾으세요 ^[2][1].

1. 풀 리퀘스트에서 “docs: dependency audit notes”와, wfx-docs 또는 chore/ 뒤에 8자가 붙은 브랜치 이름을 검색합니다 ^[1][2].
2. 11월 10일 이후의 커밋에서 “ci: refresh build cache”, “ci: restore”, “ci: cleanup”, “chore: add ci helper”, “chore: add dependency audit workflow”를 검색합니다 ^[2].
3. 일치하는 항목마다 Actions 탭을 열어 커밋 직후 실행 번호가 비어 있는지 살펴봅니다. StepSecurity는 이를 악성코드가 실행되었다는 가장 확실한 신호라고 부릅니다 ^[2].
4. 어떤 계정이 커밋을 푸시했는지 기록하세요. 그 계정의 토큰이 탈취된 것입니다 ^[2]. 탐색용 풀 리퀘스트가 존재한다면 페이로드가 실행되지 않았더라도 그 계정은 침해된 것입니다 ^[1].

없는 산출물에 의존하지 마세요. Aikido는 wfx-loot 아티팩트, wfx- 캐시 항목, 특별한 단계 요약이 없다고 해서 데이터가 탈취되지 않았다는 뜻은 아니라고 말하는데, 이 캠페인에서는 그러한 경로를 꺼 두었기 때문입니다 ^[1]. Aikido는 또한 페이로드가 공개 저장소뿐 아니라 비공개 저장소에도 배포되었을 수 있다고 봅니다 ^[1].

악성코드가 실행되었다면 어떻게 해야 하나요?

영향을 받은 워크플로가 접근할 수 있던 모든 시크릿과 클라우드 역할이 침해되었다고 가정하고, 이를 교체한 다음 지속성을 찾아내세요 ^[1][2].

• 교체: 작업이 접근할 수 있던 모든 저장소, 환경, 조직 시크릿(워크플로가 지명한 것만이 아님), npm, PyPI 및 기타 배포 토큰, 시크릿으로 저장된 클라우드 키를 교체합니다 ^[2].
• 패키지 확인: 악성 커밋 이후에 배포된 패키지 버전이 있는지 찾아봅니다 ^[2].
• AWS: 모든 AWS 주체를 허용하는 신뢰 정책, 11월 10일 이후 생성된 IAM 액세스 키, wfx-로 시작하는 CloudTrail 세션을 찾아봅니다 ^[2].
• Azure: 앱 등록에서 wfx-ci-*라는 이름의 페더레이션 ID 자격 증명을 삭제합니다 ^[2].
• Google Cloud, Vault, Kubernetes: GitHub Actions 로그인 토큰으로 이루어진 토큰 생성과 로그인을 검토합니다 ^[2].
• GitHub: 남은 브랜치를 삭제하고, 탐색용 풀 리퀘스트를 닫고, 위조된 검사로 병합된 것이 없는지 확인하고, 해당 계정의 토큰, OAuth 권한 부여, SSH 키를 취소합니다 ^[2].
• 토큰, GitHub 문서에 따라: 설정, 개발자 설정에서 개인용 액세스 토큰을 검토하고 알아보지 못하거나 필요 없는 것은 삭제하세요. GitHub는 세분화된 토큰, 필요한 최소 권한, 만료일 사용을 권장하는데, 클래식 토큰은 사용자가 접근할 수 있는 모든 저장소에 접근할 수 있기 때문입니다 ^[6].

npm 훅은 개발자 컴퓨터에서도 실행됩니다. 짧은 시간대에 npm install을 실행한 사람은 로컬에서 악성코드를 실행한 것이므로 자신의 자격 증명도 교체해야 합니다 ^[2]. SecurityWeek는 여러 보안 업체의 조언을 이렇게 요약합니다. 침해된 토큰을 취소하고, 노출된 시크릿을 교체하고, 무단 클라우드 변경이 있는지 확인하라는 것입니다 ^[4]. 봇 계정에 대해 StepSecurity는 브랜치 보호를 우회할 권한이 애초에 필요한지도 검토하라고 제안합니다 ^[2]. 강력한 로그인 보호는 계정 탈취 캠페인을 더 어렵게 만듭니다. Two-Factor Authentication Explained: Which 2FA Method Is Safest?를 참고하세요.

어떤 패키지가 영향을 받았나요?

Aikido는 자동 배포를 통해 페이로드를 받은 Packagist 패키지 하나와 Go 모듈 하나를 나열합니다 ^[1].

• Packagist: digitalelvis/neuronai-studio 버전 3.14.3. Aikido는 이를 설치했거나 연 컴퓨터는 모두 침해된 것으로 취급하라고 말합니다 ^[1].
• Go: github.com/onuragtas/docker-env v1.0.278 및 v1.0.280. 페이로드는 GitHub Actions 워크플로 파일에만 있고 Go 소스와 바이너리는 바뀌지 않았으며 Go 빌드는 워크플로 파일을 실행하지 않지만, Aikido는 그래도 이 버전들을 제거하라고 권장합니다 ^[1].

집계는 서로 다릅니다. SafeDep은 Packagist와 Go 모듈 프록시의 패키지 세 개가 페이로드를 담고 있다고 하고, SecurityWeek는 Go 모듈 두 개의 버전을 언급합니다 ^[5][4]. SafeDep은 composer require나 go get으로 이 패키지를 설치하는 일반 사용자에게는 페이로드가 실행되지 않았다고 덧붙입니다 ^[5]. 어느 하나에 의존하기 전에 각 연구자의 최신 목록을 확인하세요.

wfx-loot의 배후는 누구이며 토큰은 어떻게 얻었나요?

여기서 언급한 어떤 보고서도 공격자를 특정하지 않으며, StepSecurity는 토큰을 어떻게 획득했는지 규명하지 못했다고 밝힙니다 ^[2][4].

StepSecurity는 Fly.io GitHub App에 발급된 토큰으로 이루어진 탐색용 풀 리퀘스트 173건을 계정 19개에서 발견했으며, 이를 어떻게 획득했는지 판단할 수 없었고 Fly.io의 인프라가 침해되었다는 증거도 없다고 밝혔습니다 ^[2][4].

Aikido는 10월 GhostAction 물결에 당한 계정들과 겹치는 부분을 발견했고, 저장소 100곳이 넘는 GhostAction 워크플로 파일에 wfx-loot가 주입된 것을 확인했지만, 탈취된 자격 증명이 여러 조직의 손에 들어가는 일이 흔하다는 점에서 두 캠페인은 서로 다른 행위자가 운영하는 별개의 캠페인으로 평가했습니다 ^[1]. 또한 일부 최신 악성코드 버전에서 인도네시아어 주석을 발견했습니다 ^[1]. 여기서는 토큰을 신중하게 보관하는 것이 중요합니다. Password Managers Explained: How They Work and Whether They Are Safe에서 기본 사항을 다룹니다.