기술 요약: 테이크다운을 넘어: 야생에서의 악성 Go 모듈 지속성 측정

문제 정의

현대 소프트웨어 인프라의 중추인 Go 생태계는 공급망 공격의 표적이 되고 있습니다. npm이나 PyPI와 같은 기존 생태계와 달리, Go는 그 실행 모델과 배포 인프라로 인해 독특한 과제를 안고 있습니다. 공격자들은 공격자가 제어하는 계정 아래에 합법적인 Go 모듈을 재포장하고, 임포트(import) 시 트리거되는 난독화된 코드를 삽ల్లి하고 있습니다.

호스팅 계층의 테이크다운(GitHub에서 저장소 제거)과 생태계 차원의 복구(remediation) 사이에는 심각한 격차가 존재합니다. Go의 배포 모델은 재현성을 보장하기 위해 proxy.golang.org 및 index.golang.org에 의존합니다. 악성 모듈 버전이 프록시에 게시되고 캐싱되면, 원래의 소스 저장소가 삭제되거나 정지되더라도 해당 버전은 불변하며 계속 검색 및 호출이 가능합니다. 따라서 GitHub 중심의 가시성에만 의존하는 것은 침해의 전체 범위를 파악하거나 진정한 복구를 보장하는 데 실패합니다.

방법론

저자들은 호스팅 계층과 배포 계층 모두에서 캠페인의 발자취를 포착하기 위해 두 단계의 상호 보완적인 측정 접근 방식을 채택했습니다.

1단계: 수동 발견 (데이터셋 M)

• 범위: 2025년 3월부터 6월 사이에 수행된 GitHub 저장소 대상 수동 검색.
• 기법: 연구진은 알려진 악성 저장소 시드 세트에서 시작하여, 여러 악성 모듈에 협력적으로 스타(star)를 준 계정들을 식별하는 "스타게이저 기반 피보팅(stargazer-based pivoting)"을 통해 확장했습니다.
• 검증: 후보군들은 키워드 기반 프리필터(예: exec.Command, /bin/sh, .Start())를 사용하여 필터링되었으며, fetch-and-execute 명령(예: wget 또는 curl 후 실행)을 재구성하는 난독화된 문자열을 포함하고 있는지 수동으로 검증되었습니다.
• 결과: 높은 신뢰도를 가진 2,113개의 악성 저장소($|M| = 2,113$) 베이스라인 확보.

2단계: 자동화된 배포 계층 측정 (데이터셋 G)

• 범위: index.golang.org 및 proxy.golang.org를 사용한 Go 배포 인프라의 대규모 스캔.
• 도구: 저자들은 일반적인 악성코드가 아닌 특정 캠페인 시그니처를 탐지하도록 설계된 AST 기반 Go 스캐너인 GOAST(Go AST-based Scanner for Threat)를 개발했습니다.
  • GOAST는 Go 소스 파일을 추상 구문 트리(AST)로 파싱합니다.
  • 프로세스 생성 호출(exec.Command와 Start, Run, 또는 Output의 결합)을 식별합니다.
  • 경량화된 절차 내 값 전파(intra-procedural value propagation)를 수행하여 난독화된 문자열 인자를 재구성합니다.
  • 재구성된 실행 호출이 다운로드 명령(예: HTTP(S) URL로의 wget/curl)과 쌍을 이루는 경우에만 해당 모듈을 악성으로 플래그를 지정합니다.
• 데이터 수집: 팀은 2024년 7월부터 2025년 7월까지 1,230만 개의 인덱스 엔트리에 대한 연대기적 피드를 수집했습니다. 중복 제거 및 이름 공유 행위(합법적인 모듈 이름을 클로닝하는 행위)에 대한 필터링을 거친 후, 60,232개의 의심스러운 후보군을 스캔했습니다.
• 결과: 2,289개의 확인된 악성 모듈 버전($|G| = 2,289$).

주요 결과

1. 캠페인 특성 (RQ1)

이 캠페인은 두 가지 뚜렷한 파동을 가진 엄격하고 자동화된 파이프라인을 통해 운영됩니다.

• Wave 1 (2025년 3월): 슬라이스 인덱싱을 사용하여 명령을 재구성하며 Linux를 타겟팅함.
• Wave 2 (2025년 5월): 리터럴 결합과 슬라이스 인덱싱을 혼합하여 Windows로 확장함.
• 실행 벡터: 두 파동 모두 Go의 전역 변수 초기화자(global variable initializers)를 악용하여 패키지 임포트 즉시 악성 코드를 실행합니다.
• 인프라: 캠페인은 20개의 고유한 도메인이라는 좁은 발자취에 의존합니다. Linux 페이로드는 정적 ELF 스테이저를 제공하며, Windows 페이로드는 엄격한 31일 주기에 따라 고유한 PE 바이너리를 교체합니다.

2. GitHub 중심 뷰의 한계 (RQ2)

수동 GitHub 세트($M$)와 프록시 세트($G$)를 비교한 결과 두 가지 결정적인 사각지대가 드러났습니다.

• 발견 범위 격차 (Miss #1): 프록시에서 발견된 악성 모듈($G \setminus M$)의 83.0%가 GitHub 중심의 수동 워크플로우에 의해 발견되지 않았습니다. 이 모듈들은 수동 발견에 필요한 사회적 신호(스타) 없이 프록시 내에서 유통되었습니다.
• 호스팅 계층의 휘발성 (Miss #2): 분석 시점에 프록시 발자국($G$)에 있는 모듈의 69.3%가 이미 "GitHub에서 관찰 불가능한(GitHub-unobservable)" 상태(저장소 삭제 또는 정지)였습니다.
• 이중 누락 (Double Miss): 전체 프록시 발자국 중 64.3%가 수동 발견에서도 누락되었고, 동시에 호스팅 저장소도 이미 사라진 상태였습니다.

3. 테이크다운-복구 격차 (RQ3)

본 연구는 소스 제거 후 위협의 지속성을 정량화했습니다.

• 증거 A (중첩): 6월 스냅샷 당시 GitHub에서 사망(삭제/정지)한 것으로 확인된 교집합($M \cap G$)의 74개 모듈 중 **100%**가 7월에도 Go 프록시를 통해 검색 가능했습니다.
• 증거 B (규모): 8월 기준 GitHub에서 관찰 불가능한 프록시 세트($G$)의 1,586개 모듈 중 99.4%(1,577개)가 7월 로그에서 프록시를 통해 검색 가능한 것으로 확인되었습니다.
• 결론: 단순히 저장소를 GitHub에서 제거하는 것은 위협을 복구하지 못합니다. 악성 모듈 버전은 배포 계층에 지속됩니다.

기여 및 의의

본 논문은 세 가지 주요 기여를 합니다:

1. 생태계 규모의 측정: 활발한 Go 공급망 캠페인을 최초로 종합적으로 측정하여, 그 자동화, 두 파동의 진화, 그리고 난독화의 엄격한 구조를 규명했습니다.
2. 가시성 격차의 정량화: GitHub 중심의 뷰가 발견 범위의 제한과 호스팅 계층의 휘발성으로 인해 실제 위협 범위를 체계적으로 과소 산정함을 입증했습니다.
3. 복구 격차의 증거: Go 생태계에서 "테이크다운 $\neq$ 복구"임을 실증적으로 증명하며, 프록시에 캐싱된 모듈이 소스 저장소가 제거된 후에도 오랫동안 유지됨을 보여주었습니다.

의의:
저자들은 Go 생태계의 사고 대응 및 복구가 호스팅 계층의 신호에만 의존해서는 안 된다고 주장합니다. 프록시 인프라는 재현성을 보장하기 때문에 역설적으로 악성 아티팩트를 지속시킵니다. 효과적인 복구를 위해서는 호스팅 계층(GitHub)과 배포 계층(Go Proxy/Index) 모두에 걸친 협업이 필요합니다. 책임 있는 공개(responsible disclosure)를 따른 결과, GitHub는 684개의 저장소를 제거하였고, Google Go 팀은 1,377개의 모듈 버전을 복구하였으며, 이는 이러한 교차 계층 접근 방식의 필요성을 입증합니다.