AUR 패키지 400여 개에서 인포스틸러와 루트킷 발견 — 커뮤니티 저장소의 신뢰 모델을 다시 묻다

아치 리눅스(Arch Linux) 사용자라면 잠깐 하던 일을 멈추고 읽어보셔야 할 소식이에요. 커뮤니티 패키지 저장소인 AUR에서 약 400개의 패키지가 악성코드에 감염된 채 배포된 사실이 확인됐거든요. 그것도 그냥 악성코드가 아니라, 비밀번호와 키를 훔쳐가는 인포스틸러와 시스템 깊숙이 숨어버리는 루트킷 조합이에요.

AUR이 뭐고, 왜 이런 일이 가능했나

AUR(Arch User Repository)이 뭐냐면, 아치 리눅스의 공식 저장소에 없는 프로그램을 사용자들이 직접 올려서 공유하는 커뮤니티 저장소예요. 공식 저장소는 검증된 관리자들이 패키지를 관리하지만, AUR은 계정만 만들면 누구나 패키지를 올릴 수 있어요. 올라가는 건 완성된 프로그램이 아니라 PKGBUILD라는 빌드 스크립트인데, 이 스크립트가 소스를 어디서 받아서 어떻게 빌드하고 설치할지를 정의해요. 문제는 이 스크립트가 설치 과정에서 사실상 임의의 명령을 실행할 수 있다는 거예요. 즉, AUR에서 패키지를 설치한다는 건 '인터넷에서 받은 셸 스크립트를 내 컴퓨터에서 실행한다'는 것과 본질적으로 같은 행위거든요.

yay나 paru 같은 AUR 헬퍼 도구가 보편화되면서 이 위험은 더 가려졌어요. 명령어 한 줄로 설치가 끝나니까, PKGBUILD 내용을 읽어보는 단계를 건너뛰는 사람이 대부분이 된 거죠. 이번 공격은 정확히 그 틈을 노렸어요.

인포스틸러 + 루트킷, 최악의 조합

이번에 발견된 악성코드 구성이 특히 고약한데요. 인포스틸러가 뭐냐면, 감염된 컴퓨터에서 브라우저에 저장된 비밀번호, 쿠키(로그인 세션), SSH 키, 암호화폐 지갑 파일 같은 민감 정보를 긁어서 공격자 서버로 전송하는 악성코드예요. 개발자 컴퓨터에는 이런 게 유난히 많죠. 깃허브 토큰, 클라우드 자격증명, 회사 VPN 설정까지요.

루트킷은 한술 더 떠요. 이게 뭐냐면, 운영체제의 깊은 곳(커널 수준)에 자리 잡고 자기 자신의 흔적을 숨기는 악성코드예요. 프로세스 목록에도 안 보이고 파일 목록에도 안 보이게 만들 수 있어요. 그래서 감염됐다는 사실 자체를 알아채기가 굉장히 어렵고, 일반적인 검사 도구로도 잡기 힘들어요. 보안 업계에서 루트킷에 감염된 시스템의 정석 대응이 '치료'가 아니라 '포맷 후 재설치'인 이유가 이거예요. 뭐가 더 숨어 있는지 확신할 수 없으니까요.

처음 있는 일이 아니라는 게 더 문제

AUR에서 악성 패키지가 발견된 건 이번이 처음이 아니에요. 2025년에도 파이어폭스 관련 패키지로 위장한 AUR 패키지에서 원격 제어 악성코드(RAT)가 발견된 적이 있고요. 시야를 넓히면 npm의 event-stream 사건, PyPI의 타이포스쿼팅(유명 패키지와 비슷한 이름으로 등록해서 오타 설치를 노리는 수법), 2024년 전 세계를 긴장시킨 xz 백도어까지, '커뮤니티가 올리고 커뮤니티가 검증하는' 저장소들은 전부 같은 구조적 약점을 공유하고 있어요. 신뢰가 시스템이 아니라 관행에 기대고 있다는 거죠. 이번 사건은 규모가 400개에 달한다는 점에서, 패키지 한두 개를 탈취하던 수준을 넘어 자동화된 대량 공격으로 패러다임이 넘어가고 있다는 신호이기도 해요.

지금 당장 확인할 것들

아치 사용자라면 최근 AUR에서 설치한 패키지 목록부터 점검해 보세요. 의심스러운 패키지를 설치한 적이 있다면, 그 컴퓨터에서 쓰던 비밀번호와 토큰(깃허브, 클라우드, SSH 키)을 다른 깨끗한 기기에서 전부 교체하는 게 우선이에요. 루트킷 감염이 의심되면 미련 없이 재설치를 권해요. 그리고 앞으로는 AUR 헬퍼가 보여주는 PKGBUILD diff를 귀찮아도 꼭 읽는 습관, 투표 수와 관리자 이력이 검증된 패키지를 고르는 습관이 필요하고요.

아치를 안 쓰는 분들도 남의 일이 아니에요. npm install, pip install 한 줄도 결국 똑같은 신뢰 모델 위에 서 있거든요. lockfile로 의존성을 고정하고, 새 의존성을 추가할 때 다운로드 수와 저장소 활동을 한 번이라도 확인하고, CI와 개발 머신에서 자격증명을 최소 권한으로 관리하는 것. 지루하지만 이런 기본기가 공급망 공격 시대의 생존 기술이에요.

정리하면, 편리함의 대가로 우리는 매일 낯선 사람의 코드를 관리자 권한으로 실행하고 있다는 사실을 이번 사건이 다시 일깨워줬어요. 여러분은 패키지를 설치하기 전에 빌드 스크립트나 의존성을 확인하는 편인가요? 팀 차원에서 쓰고 있는 공급망 보안 장치가 있다면 댓글로 공유해 주세요.