모든 최신 브라우저에는 강력한 디버깅 인터페이스가 내장되어 있다. 개발자들은 이를 즐겨 사용한다. 공격자들도 마찬가지다.

VoidStealer라 불리는 새로 문서화된 악성코드 변종이 구글 크롬의 자격 증명 암호화를 우회하는 놀라울 만큼 정교한 방법을 보여주었다. 이 악성코드는 암호화 자체를 해독하려 시도하는 대신, 크롬의 내장 디버깅 프로토콜을 탈취하여 마스터 암호화 키를 직접 추출한다. BleepingComputer가 처음 상세히 보도한 이 기법은 전통적인 취약점을 악용하는 것이 아니다. 설계상의 가정을 악용하는 것이다.

이 차이는 겉보기보다 훨씬 중요하다.

VoidStealer는 크롬을 어떻게 역이용하는가

크롬은 모든 크로미움 기반 브라우저와 마찬가지로, 운영 체제의 네이티브 자격 증명 저장소로 보호되는 마스터 키를 사용해 저장된 자격 증명을 암호화한다. 윈도우에서는 DPAPI(Data Protection Application Programming Interface)가, macOS에서는 키체인이 이 역할을 한다. 암호화 자체는 견고하다. 외부에서 이를 뚫는 것은 대부분의 위협 행위자에게 수고 대비 효용이 없다.

VoidStealer는 이 문제를 완전히 우회한다. BleepingComputer의 분석에 따르면, 이 악성코드는 크롬 DevTools 프로토콜(CDP)을 통해 원격 디버깅이 활성화된 상태로 크롬을 실행하거나 기존 프로세스에 연결한다. 이 인터페이스를 통해 연결되면, VoidStealer는 브라우저에 복호화된 마스터 키, 저장된 쿠키, 저장된 비밀번호, 자동 완성 데이터를 넘기도록 지시한다. 무차별 대입 공격도 없다. 암호학적 공격도 없다. 브라우저는 정당한 디버깅 세션이 진행 중이라고 판단하기 때문에 그저 순응할 뿐이다.

공격 흐름은 허를 찌를 만큼 단순하다. 악성코드가 디버깅 포트를 여는 특정 명령줄 플래그와 함께 크롬을 실행한다. 해당 포트에 연결한다. 표준 CDP 명령을 실행해 민감한 데이터를 추출한다. 끝이다.

이것은 전통적 의미의 제로데이가 아니다. 크롬 DevTools 프로토콜은 설계된 대로 정확히 작동하고 있다. 그것이 바로 문제다.

디버깅 인터페이스가 공격 표면이 된 이유

크로미움 브라우저의 원격 디버깅은 정당한 이유로 존재한다. 웹 개발자들은 이를 상시적으로 사용한다. Puppeteer나 Playwright 같은 자동화 테스트 프레임워크가 이에 의존한다. 기업 IT 도구들은 브라우저 관리를 위해 이를 활용한다. 이 프로토콜은 문서화되어 있고, 공식 지원되며, 의도적으로 강력하다.

그러나 "의도적으로 강력한 것"과 "기본적으로 안전한 것"은 같은 말이 아니다.

보안 연구자들은 수년간 CDP 접근의 위험성을 경고해 왔다. 이 프로토콜은 브라우저 인스턴스에 대한 거의 완전한 제어권을 부여한다. 쿠키를 읽고, 네트워크 트래픽을 가로채고, 어떤 컨텍스트에서든 자바스크립트를 실행할 수 있으며, VoidStealer가 보여주듯 사용자 자격 증명을 보호하는 키 자체를 추출할 수도 있다.

VoidStealer가 제기하는 질문은 불편하다. 만약 당신의 컴퓨터에서 실행되는 프로세스가 디버깅이 활성화된 상태로 크롬을 실행한 뒤 해당 세션에 연결할 수 있다면, 보안 경계라는 것이 정확히 어디에 있는가?

솔직한 답: 거의 존재하지 않는다.

구글은 시간이 지나면서 몇 가지 완화 조치를 구현했다. 크롬은 기본적으로 원격 컴퓨터에서의 디버깅 연결을 허용하지 않는다. 최신 버전에서는 특정 CDP 명령에 대한 제한이 추가되었다. 그러나 악성코드가 로컬 실행 권한을 확보하면—모든 인포스틸러의 기본 전제 조건—이러한 안전장치는 대부분 무의미해진다.

모든 크로미움 브라우저가 동일한 노출을 물려받는다

여기서부터 분석은 더 넓어지고 더 우려스러워진다.

VoidStealer는 크롬을 표적으로 삼지만, 크롬 DevTools 프로토콜은 크롬에만 한정되지 않는다. 모든 크로미움 기반 브라우저가 이를 지원한다: 마이크로소프트 엣지, 브레이브, 오페라, 비발디, Arc. StatCounter 데이터에 따르면 크로미움 기반 브라우저의 전 세계 합산 시장 점유율은 75%를 넘는다. 크로미움을 기반으로 구축된 모든 브라우저는 동일한 디버깅 인터페이스를, 그리고 잠재적으로 동일한 노출을 물려받는다.

엣지에는 자체적인 자격 증명 보호 계층이 있다. 브레이브는 프라이버시를 강조한다. 그러나 기저의 디버깅 프로토콜은 이들 모두에서 근본적으로 동일하다. 크롬에서 CDP를 악용할 수 있는 악성코드 제작자는 최소한의 수정만으로 어떤 크로미움 파생 브라우저도 표적으로 삼을 수 있다.

이는 보안 커뮤니티가 다른 맥락에서 논의해 왔지만 브라우저 디버깅에는 좀처럼 적용하지 않았던 단일 문화 문제를 야기한다. 전 세계 브라우저의 4분의 3이 심층 접근을 위한 동일한 내부 프로토콜을 공유할 때, 단 하나의 기법이 마스터키가 된다.

VoidStealer, 혼잡하고 진화하는 인포스틸러 시장에 합류하다

VoidStealer는 이미 자격 증명 탈취 악성코드로 붐비는 시장—그리고 이것은 실제로 하나의 시장이다—에 등장했다. Raccoon, RedLine, Vidar, Lumma. 이 도구들은 수년간 지하 포럼에서 판매되고 거래되어 왔다. 대부분은 잘 알려진 기법을 사용해 브라우저에 저장된 자격 증명을 노린다: 로컬 SQLite 데이터베이스 복호화, OS 수준 자격 증명 API 악용, 메모리 덤프 등이다.

구글은 2024년 중반 윈도우에 앱 바운드 암호화(App-Bound Encryption)를 도입하여 가장 흔한 공격 벡터를 차단하려 했다. 이 기능은 크롬의 암호화 키를 특정 애플리케이션 신원에 연결하여, 외부 프로세스가 디스크에서 키를 단순히 읽어가기 어렵게 만들었다. 이는 의미 있는 진전이었다. 여러 구형 인포스틸러가 이에 무력화되었다.

VoidStealer는 그에 대한 역공을 대표한다. 외부에서 앱 바운드 암호화를 무력화하려 시도하는 대신, 내부에서 작동한다. 크롬 자체의 디버깅 인터페이스를 통해 작동함으로써, VoidStealer는 사실상 크롬에게 자체 데이터를 복호화하라고 요청한다. 브라우저 자체가 복호화를 수행하는 상황에서 앱 바운드 암호화는 도움이 되지 않는다.

BleepingComputer가 보도한 바와 같이, 이 접근법은 개념적으로 완전히 새로운 것은 아니다. 이전 악성코드 계열들도 CDP 기반 기법을 실험한 바 있다. 그러나 VoidStealer의 구현은 더 세련되고 대규모 자격 증명 탈취에 특화되어 최적화된 것으로 보이며, 이는 위협 행위자 커뮤니티 내에서 이 기법이 성숙하고 있음을 시사한다.

구글의 방어 옵션은 진정으로 제한적이다

대응책은 까다롭다—그렇지 않다고 말하는 사람은 무언가를 팔려는 것이다.

CDP를 완전히 비활성화하면 정당한 개발자 워크플로, 자동화 테스트 파이프라인, 기업 관리 도구가 작동하지 않게 된다. 수백만 명의 개발자와 QA 엔지니어가 매일 이에 의존하고 있다. 현실적이지 않다.

어떤 프로세스가 디버깅을 활성화할 수 있는지 제한하는 것이 더 실현 가능하지만, 그 자체의 복잡성을 수반한다. 브라우저가 디버깅 플래그로 크롬을 실행하는 개발자와 같은 일을 하는 악성코드 프로세스를 어떻게 구별할 수 있는가? 둘 다 동일한 시스템 권한을 가진 로컬 프로세스다. 코드 서명 검증이 도움이 될 수 있지만, 악성코드 제작자들은 도난당했거나 부정하게 취득한 인증서로 자신들의 페이로드에 일상적으로 서명한다.

구글은 디버깅 활성화에 명시적인 사용자 상호작용을 요구할 수 있다. 안드로이드에서 의도적인 탭 시퀀스를 통해 개발자 옵션을 활성화하도록 요구하는 것과 유사한 방식이다. 이렇게 하면 개발자 워크플로를 완전히 망가뜨리지 않으면서 자동화된 악용을 더 어렵게 만들 수 있다. 그러나 모든 개발자의 일상에 마찰을 추가하게 되며, 크롬 제품팀은 역사적으로 개발자 경험을 저해하는 변경에 저항해 왔다.

또 다른 접근법은 모니터링이다. 엔드포인트 탐지 도구가 디버깅 플래그와 함께 실행된 예기치 않은 크롬 프로세스를 감지할 수 있다. 일부 EDR 솔루션은 이미 이를 수행한다. 그러나 탐지는 예방이 아니며, 그 둘 사이의 간극이 바로 자격 증명이 탈취되는 지점이다.

가장 솔직한 평가: 이것은 깔끔한 해결책이 없는 설계상의 긴장이다. 크롬의 디버깅 인터페이스는 핵심적인 개발 도구이자 강력한 공격 표면이다. 한쪽을 보호하면 다른 쪽이 약화된다.

진짜 병인: 로컬 접근에 대한 신뢰

VoidStealer는 증상이다. 병인은 강력한 내부 인터페이스가 로컬 접근을 필요로 하기 때문에 안전하다는 가정이다.

이 가정은 10년 전에는 더 타당했다. 오늘날 초기 접근은 저렴하다. 피싱 키트는 스트리밍 구독료보다 싸다. 서비스형 악성코드(Malware-as-a-Service) 운영자들은 고객 지원까지 제공한다. "인터넷 상의 공격자"와 "당신의 컴퓨터 안의 공격자" 사이의 장벽은 그 어느 때보다 낮아졌다.

로컬 접근을 얻기 어려웠을 때, 강력한 로컬 인터페이스를 노출하는 것은 합리적인 절충이었다. 로컬 접근이 범용화된 지금, 동일한 인터페이스는 부채가 된다.

이는 브라우저만의 문제가 아니다. 도커의 로컬 소켓, SSH 에이전트 포워딩, IDE 플러그인 시스템—소프트웨어는 신뢰할 수 있는 로컬 환경을 가정하는 내부 인터페이스로 가득하다. VoidStealer가 이 논의에 기여하는 바는, 지구상에서 가장 널리 배포된 애플리케이션 중 하나에서 그 가정이 가시적으로, 측정 가능하게 잘못되었음을 보여주는 것이다.

기업 보안 팀에게 당장의 조치 항목은 구현이 그렇지 않더라도 명확하다. 비개발 환경에서 디버깅 플래그와 함께 생성된 크롬 프로세스를 모니터링하라. 엔드포인트 보호 솔루션이 CDP 기반 자격 증명 접근을 탐지할 수 있는지 확인하라. 브라우저에 저장된 자격 증명에 관한 정책 전반을 재평가하고, 자체 암호화 경계를 가진 전용 비밀번호 관리자가 배포 비용을 정당화하는지 검토하라.

개인 사용자에게 계산은 더 단순하다. 견고한 엔드포인트 보호 없이 크롬에 비밀번호를 저장하고 있다면, VoidStealer가 매우 생산적인 하루를 보내는 것은 피싱 이메일 한 통이면 충분하다.

처음부터 열려 있던 문

보안 커뮤니티는 앞으로 수개월간 CDP 접근이 취약점인지 의도대로 작동하는 기능인지를 놓고 논쟁을 벌일 것이다. 구글은 아마 그 중간 어딘가에 착지하여, 프로토콜을 근본적으로 재설계하지 않으면서 추가적인 제한을 구현할 것이다.

그러나 더 중요한 시사점은 구조적인 것이다. 우리의 자격 증명, 세션, 디지털 신원을 담고 있는 브라우저는 개발자 경험을 최우선 가치로 두고 설계되었다. 보안은 시간이 지나면서 패치 위에 패치를 더하며 겹겹이 추가되었다. VoidStealer는 이 보안 계층을 뚫지 않았다. 처음부터 열려 있던 문을 찾아낸 것이다.

이제 문제는 업계가 이를 단일 악성코드 사건으로 다룰 것인지, 아니면 크로미움 생태계 전반에 걸쳐 디버깅 접근과 보안의 관계를 재고해야 한다는 신호로 받아들일 것인지다.

그간의 전례를 보면, 후자를 기대하지는 마라.