1P by neo 9달전 | favorite | 댓글 1개

GitHub에서 100,000개 이상의 감염된 저장소 발견

  • 보안 연구 및 데이터 과학 팀이 지난해 중반에 시작된 악의적인 저장소 혼동 캠페인이 대규모로 재등장함을 탐지함.
  • 이 공격은 개발자들이 알려진 신뢰할 수 있는 저장소와 유사해 보이지만 실제로는 악성 코드가 포함된 저장소를 사용할 때 100,000개 이상의 GitHub 저장소(그리고 추정컨대 수백만 개)에 영향을 미침.

저장소 혼동 공격이 어떻게 발생하는가?

  • 저장소 혼동 공격은 의존성 혼동 공격과 유사하게, 악의적인 행위자들이 대상이 진짜 버전 대신 악성 버전을 다운로드하도록 함.
  • 의존성 혼동 공격은 패키지 관리자의 작동 방식을 이용하는 반면, 저장소 혼동 공격은 사람들이 실수로 진짜 버전 대신 악성 버전을 선택하게 하는 것에 의존하며, 때로는 사회 공학 기법도 사용함.

악성 저장소가 사용될 때 발생하는 일

  • 의심 없이 개발자들이 악성 저장소를 사용하면, 숨겨진 페이로드가 7단계의 난독화를 풀고, 악성 파이썬 코드와 이후에 바이너리 실행 파일을 가져옴.
  • 악성 코드는 다양한 앱의 로그인 자격 증명, 브라우저 비밀번호 및 쿠키, 그리고 기타 기밀 데이터를 수집하여 악의적인 행위자의 C&C 서버로 전송하고 추가적인 악성 활동을 수행함.

GitHub에서의 자동화 영향

  • 대부분의 포크된 저장소는 GitHub에 의해 빠르게 제거되지만, 자동화 탐지는 많은 저장소를 놓치고 수동으로 업로드된 저장소는 생존함.
  • 전체 공격 체인이 대규모로 대부분 자동화되어 있기 때문에, 생존하는 1%는 여전히 수천 개의 악성 저장소를 의미함.

캠페인이 시작된 시기

  • 2023년 5월: Phylum이 처음 보고한 바에 따르면, 현재 페이로드의 초기 부분을 포함한 여러 악성 패키지가 PyPI에 업로드됨.
  • 2023년 7월 - 8월: PyPI가 악성 패키지를 제거하고 보안 커뮤니티가 그곳에 더 많은 관심을 기울이자, 이번에는 PyPI 패키지를 가져오는 대신 직접 페이로드를 전달하는 여러 악성 저장소가 GitHub에 업로드됨.
  • 2023년 11월 - 현재: 유사한 악성 페이로드를 포함하는 100,000개 이상의 저장소가 탐지되었으며, 그 수는 계속 증가하고 있음.

패키지 관리자에서 소스 코드 관리(SCM)로의 악성 소프트웨어 전환

  • 패키지 관리자와 SCM 플랫폼에서 관찰된 많은 사건들을 통해, 이 캠페인이 PyPI의 악성 패키지에서 GitHub의 악성 저장소로 전환된 것은 일반적인 추세를 반영하는 것으로 보임.

저장소 혼동에 대한 자신을 보호하는 방법

  • GitHub에 통보되어 대부분의 악성 저장소가 삭제되었지만, 캠페인은 계속되고 있으며, 공급망에 악성 코드를 주입하려는 공격이 점점 더 흔해지고 있음.
  • Apiiro에서는 연결된 코드베이스를 모니터링하는 악성 코드 탐지 시스템을 구축함.
  • 다양한 고급 기술을 사용하여 공격을 탐지하는데, 이는 LLM 기반 코드 분석, 코드를 완전한 실행 흐름 그래프로 분해, 정교한 휴리스틱 엔진, 동적 디코딩, 복호화 및 난독화 해제 등을 포함함.

GN⁺의 의견

  • 이 기사는 개발자들에게 GitHub 저장소를 사용할 때 주의해야 할 보안 위협을 알리는 중요한 정보를 제공함.
  • 악성 코드가 소프트웨어 공급망에 침투하는 방식을 이해함으로써, 개발자들과 보안 전문가들은 더 강력한 방어 메커니즘을 구축할 수 있음.
  • 이러한 공격은 개발자들이 신뢰할 수 있는 저장소를 선택하는 능력뿐만 아니라, CI/CD 구성의 정확성과 제3자 코드의 보안성에 대한 의존도를 강조함.
  • 비판적인 시각에서 볼 때, 이러한 공격은 GitHub와 같은 플랫폼의 자동화된 시스템과 대규모 저장소의 존재가 양날의 검이 될 수 있음을 보여줌.
  • 유사한 기능을 제공하는 보안 도구로는 SonarQube, Snyk, WhiteSource 등이 있으며, 이들은 코드의 취약점을 탐지하고 보안을 강화하는 데 도움을 줄 수 있음.
  • 이 기술을 도입하기 전에는 조직의 보안 정책과 호환성, 구현 비용, 그리고 팀원들의 기술적 역량을 고려해야 함.
  • 이 기술을 선택함으로써 얻을 수 있는 이점은 보안 강화와 위험 감소이지만, 잠재적인 단점으로는 새로운 시스템에 대한 학습 곡선과 관리의 복잡성이 있음.
Hacker News 의견
  • 공개 저장소에서 코드를 가져올 때 주의해야 하며, 의존성 트리를 검증하는 것이 중요함. 이는 공개 저장소의 맬웨어가 언어 모델(Large Language Models, LLMs)과 같은 자동화 도구에 어떤 영향을 미칠지에 대한 질문을 제기함. 예를 들어, GitHub Copilot과 같은 도구가 코딩 질문에 대한 응답으로 실수로 맬웨어를 포함할 가능성이 있음.
  • GitHub가 Usenet이 실패한 것과 같은 방식으로 실패하고 있음을 지적함. 누구나 GitHub에 저장소를 만들 수 있으며, 공식 저장소와 스패머의 저장소를 구별할 방법이 없음. Amazon이 "모든 것을 파는 상점"을 목표로 할 때, 대부분의 상품이 쓰레기라는 문제에 직면함. GitHub은 "모두를 위한 저장소"인지, 아니면 "이 코드를 신뢰할 수 있는가"에 대한 정체성을 확립해야 함.
  • 공급망 문제가 심각함을 토로함. npm 릴리스를 대상으로 하지 않지만, 프로젝트 모니터링을 위해 socket.dev를 사용하고 있음. BrowserBox 프로젝트는 약 800개의 의존성을 사용하며, 이 중 19개가 최상위 의존성임. 모든 의존성을 npm의 @browserbox 네임스페이스로 스냅샷하여 취약점을 추적하고 패치하는 방법을 고려 중임.
  • 개발자는 작업, 취미, 개인용으로 최소 세 개의 환경을 분리해야 함을 강조함. 신뢰할 수 있는 저장소와 소유자라도 샌드박스 가상 머신에서 코드를 실행하는 것이 현명함.
  • 작은 팀에서 많은 주간 다운로드를 받는 SDK를 개발하는 경우, snyk, aikido.dev, renovate 기반 솔루션 등을 평가 중임. 이러한 도구들이 문제를 해결하는 데 도움이 될지 명확하지 않으며, snyk에서 경험한 것처럼 많은 거짓 긍정을 처리하는 것은 어려움.
  • curl과 sudo를 사용한 쉘 스크립트 설치 방식이 곧 끝날지 궁금함을 표현함. 이 방식은 기사에서 언급된 감염된 소프트웨어와 밀접한 관련이 있음.
  • npm에서 --ignore-scripts 옵션을 사용하여 맬웨어 실행을 방지할 수 있음.
  • 1년 미만의 시간에 트로이 목마 바이러스가 포함된 저장소가 있었음을 언급함.
  • 보안 문제에 대한 최신 게시물이 LLM 스타트업에 자금을 제공하라는 광고로 이어짐을 비판함. 이러한 스타트업들이 보안 격차의 일부만을 해결할 수 있으며, 다수의 스타트업과 계약을 맺는 것이 비용과 통합 문제를 야기할 수 있음.
  • 지속적인 보안 보고에 따라 개발 환경의 보안을 점진적으로 개선하고 있음. VSCode 개발 컨테이너, GitHub Codespaces, OWASP 지침 읽기, socket.dev를 사용한 npm/파이썬 패키지 리뷰 등을 시도 중임.