Axios NPM 패키지가 해킹당했습니다 — 원격 접속 트로이목마가 심어진 악성 버전 주의

무슨 일이 벌어진 건가요?

프론트엔드·백엔드 가리지 않고 거의 모든 자바스크립트 프로젝트에서 쓰이는 HTTP 클라이언트 라이브러리 Axios가 NPM에서 해킹당한 사실이 확인됐어요. 공격자가 Axios의 공식 NPM 패키지에 원격 접속 트로이목마(RAT)를 심은 악성 버전을 배포한 거예요.

RAT가 뭐냐면, 쉽게 말해서 해커가 여러분의 컴퓨터나 서버에 원격으로 들어와서 마음대로 조작할 수 있게 해주는 악성 프로그램이에요. 파일을 훔치거나, 키보드 입력을 엿보거나, 다른 악성코드를 추가로 설치하는 것도 가능하죠. 이런 게 우리가 매일 npm install로 설치하는 패키지에 들어있었다니, 정말 소름 끼치는 일이에요.

어떤 버전이 위험한가요?

StepSecurity의 분석에 따르면, 공격자는 Axios 패키지의 특정 버전에 악성 코드를 삽입했어요. 이 악성 코드는 설치 시점에 실행되는 postinstall 스크립트를 통해 동작하는데요. postinstall 스크립트라는 건 npm install을 실행할 때 패키지 설치가 끝난 직후 자동으로 실행되는 스크립트예요. 즉, 여러분이 아무것도 모른 채 패키지를 설치하기만 해도 악성 코드가 자동으로 실행되는 구조인 거예요.

악성 버전이 설치되면 외부 서버와 통신을 시작하면서 RAT를 다운로드하고 실행해요. 이 RAT는 시스템에 지속적으로 상주하면서 공격자의 명령을 기다리는 백도어 역할을 하게 돼요. 특히 CI/CD 파이프라인이나 프로덕션 서버에서 이 버전이 설치됐다면, 배포 키나 환경 변수에 저장된 시크릿 정보가 모두 노출됐을 가능성이 있어요.

현재 NPM 측에서 해당 악성 버전을 제거하는 조치를 취했지만, 이미 설치한 프로젝트에서는 수동으로 확인하고 조치를 취해야 해요. package-lock.json이나 node_modules를 반드시 확인해보세요.

공급망 공격, 이제 남의 일이 아니에요

이번 사건은 전형적인 소프트웨어 공급망 공격(Supply Chain Attack)이에요. 공급망 공격이 뭐냐면, 소프트웨어를 직접 공격하는 게 아니라 그 소프트웨어가 의존하는 라이브러리나 도구를 먼저 감염시켜서 간접적으로 침투하는 방식이에요. 마치 식당 음식에 직접 독을 넣는 게 아니라, 식재료 납품 업체를 통해 오염된 재료를 보내는 것과 비슷하달까요.

사실 NPM 생태계에서 이런 일은 이번이 처음이 아니에요. 2021년에는 ua-parser-js 패키지가 해킹당해서 암호화폐 채굴기가 심어졌고, event-stream 사건에서는 유지보수 권한을 넘겨받은 공격자가 특정 비트코인 지갑을 노리는 코드를 삽입했어요. 하지만 Axios는 주간 다운로드 수가 수천만 건에 달하는 초대형 패키지라는 점에서 이번 사건의 파급력은 이전 사례들과 차원이 달라요.

비슷한 맥락에서 Python의 PyPI에서도 타이포스쿼팅(이름이 비슷한 가짜 패키지 등록) 공격이 끊이지 않고, GitHub Actions의 서드파티 액션에서도 악성 코드가 발견된 적이 있어요. 오픈소스 생태계의 신뢰 모델 자체가 근본적인 도전을 받고 있는 시대인 거죠.

당장 무엇을 확인해야 할까요?

한국 개발자분들이 지금 바로 해야 할 일을 정리해볼게요.

첫째, 프로젝트의 Axios 버전을 즉시 확인하세요. package-lock.json에서 axios 항목을 찾아서 설치된 정확한 버전을 확인하고, 공식적으로 안전하다고 확인된 버전으로 업데이트하세요.

둘째, lockfile 기반의 의존성 관리를 철저히 하세요. package-lock.json이나 yarn.lock 없이 배포하고 있었다면, 이번 기회에 반드시 lockfile을 커밋에 포함시키세요. lockfile이 없으면 매번 설치할 때마다 최신 버전을 받아오기 때문에 악성 버전에 노출될 확률이 훨씬 높아져요.

셋째, npm audit이나 Socket.dev 같은 보안 도구를 CI 파이프라인에 넣는 것을 고려해보세요. StepSecurity에서 제공하는 도구처럼 설치 시점의 네트워크 통신이나 파일시스템 접근을 모니터링하는 솔루션도 있어요.

넷째, postinstall 스크립트 실행을 제한하는 것도 방법이에요. .npmrc에 ignore-scripts=true를 설정하면 설치 스크립트가 자동 실행되지 않거든요. 다만 일부 패키지는 postinstall에 의존하므로 프로젝트 상황에 맞게 판단해야 해요.

정리하면

우리가 매일 쓰는 npm 패키지도 언제든 공급망 공격의 대상이 될 수 있다는 걸 다시 한번 보여준 사건이에요. "유명한 패키지니까 안전하겠지"라는 생각은 이제 통하지 않아요. 여러분의 프로젝트에서 의존성 보안은 어떻게 관리하고 계신가요? lockfile 관리, 보안 감사 도구 사용, 아니면 다른 방법이 있다면 공유해주세요.