해커들이 신뢰받는 Rust 크레이트를 악성코드 전달 시스템으로 전환하다

널리 사용되는 Rust 패키지가 증가하는 소프트웨어 공급망 공격 추세의 최신 희생양이 되었습니다. The Register의 보도에 따르면, 해커들이 널리 사용되는 Rust 크레이트인 arrayref 뒤에 있는 관리자 계정을 손상시키고 개발자들의 자격 증명을 탈취하도록 설계된 악성 업데이트를 배포했습니다. 약 2억 4,500만 번 다운로드된 이 크레이트는 이러한 유형의 공격을 매우 효과적으로 만드는 기반적이고 간과하기 쉬운 의존성의 전형입니다.

공격자들은 개별 개발자를 직접 표적으로 삼는 대신 소프트웨어 공급망 자체를 노렸습니다. 관리자 계정을 장악함으로써 그들은 일상적인 업데이트처럼 보이는 것에 인포스틸러(information-stealing) 악성코드를 몰래 넣을 수 있었습니다. 손상된 버전을 빌드에 포함시킨 모든 개발자는 자신도 모르는 사이에 자신의 개발 환경을 자격 증명 탈취 코드의 전달 지점으로 바꿔버렸습니다.

이 공격이 왜 그렇게 효과적이었나

Rust 생태계는 대부분의 현대 프로그래밍 환경과 마찬가지로 크레이트라고 불리는 공유 코드 라이브러리에 크게 의존합니다. 개발자들은 모든 의존성을 줄 단위로 감사하는 경우가 거의 없습니다. 대신 수백만 번 다운로드되고 기존 관리자가 있는 패키지는 이미 커뮤니티에 의해 검증되었다고 신뢰합니다. 바로 그 신뢰를 공격자들이 이용하는 것입니다.

이 사건은 공격자들이 더 약한 연결고리, 즉 단일 관리자 계정을 표적으로 삼아 하류에 있는 훨씬 더 많은 피해자 풀에 도달하는 공급망 공격으로 알려진 패턴에 해당합니다. arrayref가 수많은 다른 프로젝트에 내장되어 있기 때문에 단 한 번의 손상된 업데이트가 누군가 문제를 알아차리기 전에 수많은 코드베이스에 파문을 일으킬 잠재력이 있었습니다.

이 사례가 주목할 만한 점은 특정 페이로드입니다. 단순히 백도어나 암호화폐 채굴 스크립트를 삽입하는 대신, 악성 업데이트는 감염된 시스템에서 개발자 자격 증명을 직접 수확하도록 만들어졌습니다. 이것은 의미 있는 확대입니다. 도난당한 개발자 자격 증명은 소스 코드 저장소, 클라우드 인프라, 패키지 레지스트리 및 기타 고가치 시스템에 접근하는 데 사용될 수 있으며, 원래 피해자를 훨씬 넘어 추가 공격을 가능하게 할 수 있습니다.

개발자를 위한 개인정보 보호의 중요성

소프트웨어 공급망 공격에 대한 대부분의 논의는 기술적 영향, 즉 빌드 손상, 프로덕션 시스템 침해, 긴급 패치에 초점을 맞춥니다. 그러나 여기에는 더 많은 주목을 받을 가치가 있는 개인정보 보호 측면이 있습니다.

개발자들은 자신의 머신에 API 키, SSH 키, 클라우드 서비스 토큰, 내부 도구용 로그인 자격 증명 등 엄청난 양의 민감한 정보를 저장합니다. 일상적인 빌드 프로세스 중에 실행되도록 설계된 인포스틸러는 정확히 이런 종류의 데이터에 직접 접근할 수 있습니다. 신중한 개발자가 알아차릴 수 있는 피싱 이메일과 달리, 악성 의존성은 정상적이고 예상되는 동작의 일부로 조용히 실행됩니다. 클릭할 의심스러운 링크도 없고 명백한 위험 신호도 없으며, 다른 업데이트와 똑같이 보이는 패키지 업데이트일 뿐입니다.

그것이 바로 크레이트 및 패키지 오염 공격이 개인정보 보호 관점에서 특히 우려되는 이유입니다. 피해자들은 도난당한 데이터가 다른 곳에서 사용될 때까지, 즉 회사의 클라우드 환경에 대한 무단 접근이든 개발자가 관리하는 다른 오픈소스 프로젝트의 추가 침해든, 자신의 자격 증명이 노출되었다는 사실을 종종 알지 못합니다.

이것이 당신에게 의미하는 바

Rust 개발자이거나 오픈소스 패키지 생태계에 의존하는 다른 언어로 작업한다면, 이 사건은 패키지의 인기에 대한 신뢰가 현재 보안에 대한 신뢰와 동일하지 않다는 사실을 상기시켜 줍니다. 2억 4,500만 번 다운로드된 크레이트도 단일 관리자 계정이 탈취되면 손상될 수 있습니다.

고려해 볼 만한 실질적인 조치로는 최신 릴리스를 자동으로 가져오는 대신 의존성 버전을 고정하고, 중요 패키지를 업그레이드하기 전에 변경 로그를 검토하며, 알려진 악성 동작이 있는지 의존성을 스캔하는 도구를 사용하는 것이 포함됩니다. 패키지 게시와 관련된 모든 계정에 다중 인증(MFA)을 활성화하고 정기적으로 자격 증명을 교체하는 것도 계정이 손상된 경우 피해 범위를 줄입니다.

오픈소스 의존성에 크게 의존하는 조직은 사용 중인 패키지의 내부 인벤토리를 유지하고 특히 여러 프로젝트에 걸쳐 큰 영향력을 가진 패키지의 비정상적인 업데이트 활동을 모니터링하는 것도 고려해야 합니다.

공급망 위협에 선제적으로 대응하기

arrayref에 대한 이번 공격이 해커들이 개발자 자격 증명을 탈취하기 위해 오픈소스 생태계를 표적으로 삼는 마지막 사례가 될 가능성은 낮습니다. 소프트웨어 공급망이 더욱 상호 연결됨에 따라 단일 손상된 관리자 계정이 한 프로젝트를 훨씬 넘어서는 결과를 초래할 수 있습니다.

개발자에게 주는 교훈은 오픈소스 도구를 포기하는 것이 아니라 다른 보안에 민감한 시스템에 적용하는 것과 동일한 주의를 기울여 의존성 관리를 대우하는 것입니다. 병합하기 전에 업데이트를 검토하고, 빌드 환경에 부여된 권한을 제한하며, 신뢰할 수 있고 다운로드 수가 많은 패키지도 공격 벡터가 될 수 있다고 가정하십시오. 이와 같은 사건에 대한 정보를 지속적으로 파악하는 것은 초기 경고 신호를 인식하고 자신의 자격 증명과 구축에 참여하는 시스템을 보호하는 가장 간단한 방법 중 하나입니다.