엔트리포인트 리와이어링(Entrypoint Rewiring): 악성 패키지가 바이너리 실행 흐름을 가로채는 기술적 메커니즘

최근 오픈소스 생태계를 겨냥한 공급망 공격(Supply Chain Attack)은 과거의 단순한 데이터 탈취 수준을 넘어, 소프트웨어의 실행 구조 자체를 재설계하는 '리와이어링(Rewiring)' 단계로 진화하고 있습니다. 단순히 사용자의 비밀번호를 훔치는 것을 넘어, 우리가 믿고 사용하는 도구의 동작 방식을 근본적으로 뒤바꾸는 정교한 공격이 등장한 것입니다.

최근 JFrog Security Research가 발견한 @bitwarden/cli (v2026.4.0) 사례는 이러한 위협의 심각성을 여실히 보여줍니다. 유명한 비밀번호 관리 도구인 Bitwarden의 CLI 클라이언트를 사칭한 이 패키지는, 겉보기에는 정상적인 메타데이터를 유지하고 있어 개발자가 의심 없이 설치하도록 유도합니다. 하지만 실제 내부에서는 바이너리의 엔트리포인트(Entrypoint)를 변조하여 공격자의 커스텀 로더가 실행되도록 설계되었습니다. 이는 단순한 악성 코드를 넘어, 신뢰의 연결 고리를 끊어버리는 정교한 설계입니다.

Entrypoint Rewiring: 어떻게 실행 흐름을 가로채는가?

공격의 핵심 기술은 '엔트리포인트 리와이어링(Entrypoint Rewiring)'입니다. JFrog의 분석에 따르면, 공격자는 npm 패키지의 메타데이터를 조작하여 기존의 정상적인 Bitwarden CLI 대신 bw_setup.js라는 커스텀 로더가 실행되도록 설정했습니다.

이 과정은 매우 치밀하게 이루어집니다. 공격자는 package.json 파일 내의 scripts와 bin 설정을 교묘하게 변경합니다. 예를 들어, 패키지 설치 시 자동으로 실행되는 preinstall 스크립트를 node bw_setup.js로 지정하고, 사용자가 bw 명령어를 입력했을 때 호출되는 바이너리 엔트리포인트 자체를 악성 로더인 bw_setup.js로 재설정합니다.

이 방식이 무서운 이유는 패키지의 메타데이터 자체는 정상적인 Bitwarden 정보를 유지하고 있다는 점입니다. 내부 번들링된 데이터는 여전히 Bitwarden CLI v2026.3.0을 가리키고 있어, 검증 도구를 통과할 가능성을 높입니다. 즉, 패키지의 '이름표'는 진짜지만, 그 안의 '실행 경로(Execution Path)'만 살짝 비틀어 개발자의 워크스테이션에서 공격자의 코드가 돌아가게 만드는 것입니다.

페이로드 전개: Bun 런타임 활용과 난독화된 공격 단계

bw_setup.js로 명명된 이 로더는 실행 직후 본격적인 침투를 위해 환경을 구축합니다. 먼저 시스템 내에 bun 런타임이 설치되어 있는지 확인합니다. 만약 존재하지 않는다면, GitHub(github.com/oven-sh/bun)에서 플랫폼에 맞는 Bun 릴리스 아카이브를 직접 다운로드하여 실행 환경을 구성합니다. 이는 최신 JavaScript 런타임을 활용해 공격 코드의 실행 속도를 높이고 탐지를 피하기 위한 전략입니다.

환경 구축이 완료되면, 로더는 대규모로 난독화된 JavaScript 페이로드를 구동합니다. 이 단계에서 난독화를 해제하면 개발자 워크스테이션과 CI/CD 환경을 겨냥한 광범위한 자격 증명 탈취 작업이 드러납니다. 공격 대상은 매우 포괄적입니다:

• 인증 토큰: GitHub 및 npm 개인 액세스 토큰(PAT)
• 클라우드 자격 증명: AWS, GCP, Azure의 시크릿 정보
• 개발 환경 데이터: SSH 키, 쉘 히스토리(Shell History), AI 도구 설정 파일
• CI/CD 보안: GitHub Actions의 Secret 값

이처럼 공격자는 단순한 개인 정보를 넘어, 기업의 인프라 전체를 장악할 수 있는 '클라우드 권한'을 목표로 삼고 있습니다.

데이터 유출 경로: 이중 채널을 이용한 은밀한 정보 유출

공격자가 탈취한 데이터를 외부로 전송하는 과정 또한 매우 고도화되어 있습니다. 공격자는 탐지를 회피하기 위해 두 가지 채널(Primary & Fallback)을 운용합니다.

첫 번째 **기본 채널(Primary Channel)**은 audit.checkmarx.cx/v1/telemetry로 암호화된 텔레메트리 데이터를 전송하는 방식입니다. 공격자는 이 서버를 통해 탈취한 정보를 수집하며, 분석 결과 해당 인프라는 94.154.172.43 IP 주소와 직접 연결되어 있음이 확인되었습니다.

만약 기본 채널이 차단될 경우, 공격자는 두 번째 **대체 채널(Fallback Channel)**을 가동합니다. 이는 놀랍게도 GitHub API를 이용하는 방식입니다. 공격자는 미리 준비된 PAT와 공개된 커밋 메시지에서 얻은 라우팅 데이터를 사용하여, 피해자의 계정 내에 새로운 레포지토리를 생성한 뒤 탈취한 암호화된 데이터 블롭(Blob)을 해당 레포지토리에 업로드합니다. 정상적인 서비스인 GitHub의 인프라를 데이터 유출 통로로 활용함으로써 보안 솔루션의 눈을 속이는 것입니다.

특히 이번 공격 코드에서는 Shai-Hulud 테마의 명칭(예: sardaukar, fremen, atreides)이 발견되었습니다. 이는 과거 진행되었던 특정 캠페인과의 연관성을 시사하며, 공격자가 단순한 일회성 해커가 아닌 체계적인 테마를 가진 집단일 가능성을 보여줍니다.

결론: 공급망 보안 강화를 위한 개발자의 대응 전략

이번 사례는 우리가 사용하는 오픈소스 패키지의 '메타데이터'와 '실제 실행 파일(Binary)' 간의 불일치가 얼마나 치명적인 결과를 초래할 수 있는지 보여줍니다. 패키지 이름과 버전이 신뢰할 수 있더라도, 내부 스크립트나 바이너리 경로가 변조되었을 가능성을 항상 염두에 두어야 합니다.

개발자와 보안 운영자를 위한 실질적인 대응 방안은 다음과 같습니다:

1. 설치 스크립트(Lifecycle Scripts) 제어: npm install 시 실행되는 preinstall, postinstall 스크립트를 주의 깊게 모니터링해야 합니다. 가급적 --ignore-scripts 옵션을 사용하여 의도치 않은 스크립트 실행을 방지하는 습관이 필요합니다.
2. CI/CD 권한 최소화(Principle of Least Privilege): CI/CD 환경의 워커 노드에는 작업에 꼭 필요한 최소한의 권한만 부여해야 합니다. 특히 AWS, Azure 등의 클라우드 자격 증명이 포함된 환경에서는 네트워크 아웃바운드 규칙을 엄격히 제한하여, 허용되지 않은 도메인(예: audit.checkmarx.cx)으로의 데이터 전송을 차단해야 합니다.
3. 패키지 무결성 검증: 패키지의 메타데이터뿐만 아니라, 실제 실행되는 바이너리의 해시값이나 엔트리포인트 구성을 정기적으로 점검하는 자동화된 보안 스캔 프로세스를 도입해야 합니다.

공급망 공격은 점점 더 지능적인 '리와이어링' 형태로 진화하고 있습니다. 신뢰를 기반으로 하는 오픈소스 생태계에서, 이제는 '무조건적인 믿음' 대신 '지속적인 검증'이 개발자의 핵심 역량이 되어야 할 때입니다.