구글 패스키 마스터키, 유출되면 영구 노출…패스-타-키 공격

구글 패스워드 매니저에 저장된 패스키(비밀번호 없이 지문·PIN 등으로 로그인하는 인증 방식)가 악성코드 앞에서는 완전히 안전하지 않다는 연구 결과가 나왔다. 팔로알토 네트웍스(Palo Alto Networks) 산하 유닛42(Unit 42) 연구팀은 크롬(Chrome) 브라우저의 구글 패스워드 매니저 동기화 패스키를 노리는 세 가지 공격 기법을 발견했다고 밝혔다. 연구팀은 이를 통칭해 “패스-타-키(Pass-ta-key)”라 이름 붙였다.

세 기법 모두 패스키의 암호화 자체를 깨는 것은 아니다. 대신 기기 신뢰 확인, 기기 등록(온보딩), 계정 복구 과정에 있는 허점을 파고든다. 다만 전제 조건이 있다. 트러스티드 플랫폼 모듈(TPM, 기기 내 하드웨어 보안칩)이 탑재된 윈도우 PC에 악성코드가 이미 설치돼 있어야 공격이 성립한다. 즉 구글 계정을 원격에서 뚫는 방식이 아니라, 이미 감염된 PC에서 공격자가 얼마나 더 깊이 침투할 수 있는지를 보여주는 연구다.

3단계 공격, 마지막 단계는 마스터키까지 노린다

첫 번째 기법인 패스-타-키는 크롬이 TPM에 저장해 둔 기기 식별 키를 악성코드가 이용해 구글의 클라우드 인증 서버에 인증 요청을 보내는 방식이다. 관리자 권한이나 생체인증, PIN 입력, 기기 잠금 해제 없이도 구글 서버로부터 정상적인 인증 응답(어서션)을 받아낼 수 있다. 다만 이 응답에는 사용자 인증이 실제로 이뤄졌는지를 나타내는 ‘UV(User Verified)’ 플래그가 꺼진 상태로 표시된다. 유닛42가 실험한 결과 깃허브(GitHub)는 이 플래그를 제대로 검증해 공격을 막았지만, 이베이(eBay)는 사용자 인증을 요구한다고 밝혔음에도 플래그 검증이 부실해 공격을 그대로 받아들였다. 이베이는 연구팀의 신고 이후 해당 결함을 수정했다.

두 번째 기법 ‘실버 패스-타-키’는 한 단계 더 나간다. 악성코드가 크롬에 기기 재등록을 강제로 유도한 뒤, 그 과정에서 공격자가 직접 만든 사용자 인증 키를 등록시킨다. 구글의 클라우드 인증 서버가 새로 등록되는 키가 실제로 신뢰할 수 있는 하드웨어에서 나온 것인지 검증하지 않는다는 점을 이용한 것이다. 이 키가 한 번 등록되면 공격자는 피해자의 PC에 다시 접근하지 않고도 다른 컴퓨터에서 로그인할 수 있게 된다.

가장 심각한 것은 세 번째 기법 ‘골든 패스-타-키’다. 이는 사용자 계정에 동기화된 모든 패스키를 암호화하는 마스터키, 이른바 보안 도메인 시크릿(Security Domain Secret, SDS)을 노린다. 유닛42는 처음에 이 SDS가 크롬 내부 FIDO 로그에 평문(암호화되지 않은 문자열)으로 그대로 노출된다는 사실을 발견했다. 구글은 신고를 받은 뒤 로그에서 이 값을 제거했지만, 연구팀에 따르면 SDS는 여전히 기기 재등록 시 크롬으로 전송되며 브라우저의 프로세스 메모리에 일시적으로 남는다. 악성코드가 이 메모리를 읽어내면 SDS를 추출해 동기화된 패스키의 개인 키를 전부 복호화할 수 있고, 이를 다른 시스템으로 옮겨 피해자를 사칭해 로그인하는 것도 가능하다는 설명이다.

CVE 없는 ‘사후 침투’ 기법…감염이 먼저다

이번 연구에서 눈에 띄는 점은 세 기법 모두 이미 악성코드에 감염된 기기를 전제로 한다는 것이다. 깨끗한 PC에서 패스키를 쓸 때는 이번에 밝혀진 취약점이 통하지 않는다. 연구 대상도 TPM이 탑재된 윈도우 PC의 크롬 브라우저, 그중에서도 구글 패스워드 매니저에 동기화된 패스키로 한정돼 있다.

공개된 정보만 보면 이번 공격들은 CVE(공통 취약점 식별 번호) 발급 대상으로 등록되지 않았다. 8월 3일(현지시각) 기준 국가취약점데이터베이스(NVD)를 검색한 결과 세 기법에 해당하는 CVE는 확인되지 않았다는 보도도 나왔다. 실제 공격에 악용된 사례(in the wild)가 있었다는 언급도 없다. 다만 크롬은 %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB 경로에 동기화된 인증 정보를 저장하는데, 권한이 없는 프로세스도 이 메타데이터를 읽어 어떤 서비스의 패스키인지, 사용자명이 무엇인지까지 식별할 수 있는 것으로 나타났다.

이베이는 고쳤지만, 마스터키는 여전히 풀리지 않은 문제

유닛42는 연구 결과를 공개하기 전 구글과 이베이 등 영향을 받는 서비스에 먼저 알렸다. 이베이는 UV 플래그 검증 결함을 수정했고, 깃허브는 애초부터 검증 절차가 제대로 작동해 공격을 막아낸 것으로 확인됐다.

문제는 구글 쪽 대응이다. 구글은 SDS가 크롬 로그에 노출되던 부분은 제거했지만, 이는 근본적인 노출 경로를 닫은 것은 아니라는 게 유닛42의 지적이다. SDS는 여전히 클라이언트로 전송되고 브라우저 메모리에 남는다. 더 큰 문제는 이 마스터키를 회전(rotate)하거나 폐기(revoke)할 방법이 현재로선 없다는 점이다. 한 번 SDS가 유출되면 그 계정에 동기화된 기존 패스키뿐 아니라 앞으로 새로 만들어질 패스키까지 같은 비밀값으로 보호되기 때문에 계속 위험에 노출될 수 있다는 뜻이다. 구글은 패스워드 매니저 PIN 변경이나 저장된 데이터 전체 삭제 기능을 지원 문서에 안내하고 있지만, SDS만 별도로 회전시키는 기능은 명시돼 있지 않다.

유닛42는 서비스들이 UV 플래그를 제대로 검증하고, 자격증명 관리자가 새로 등록되는 기기 키의 출처를 검증하며, 복구·재등록 절차를 강화하고, 마스터키가 브라우저 메모리에서 노출되지 않도록 해야 한다고 권고했다. 블리핑컴퓨터(BleepingComputer)와 The Hacker News는 이번 공격이 완전히 해소됐는지를 구글에 문의했으나 보도 시점까지 즉답을 받지 못했다고 전했다.

패스키는 여전히 패스워드보다 안전하다는 결론

연구팀은 이번 발견이 “패스키가 깨졌다”는 의미는 아니라고 강조했다. 연구 과정 내내 패스키의 암호화 자체는 뚫리지 않았고, 문제는 기기 신뢰·온보딩·복구 과정에서 사용자가 기대하는 보안 수준과 실제 구현 사이에 존재하는 간극이었다는 것이다. 패스키는 여전히 피싱, 비밀번호 재사용, 유출 사고에서 전통적인 비밀번호보다 훨씬 안전한 수단으로 남아 있다.

다만 이번 사례는 오래된 교훈을 다시 확인시켜준다. 신뢰하는 기기가 악성코드에 감염되면 어떤 인증 방식도 완전히 안전할 수 없다는 점이다. 유닛42는 구글 이외에도 다른 패스키 제공업체들이 유사한 클라우드 인증 모델을 쓰고 있다고 지목하며, 이번 발견이 구글 한 곳만의 문제로 끝나지 않을 가능성도 시사했다. 결국 패스키 시대에도 엔드포인트 보안, 즉 악성코드에 감염되지 않도록 PC 자체를 지키는 일이 여전히 가장 중요한 방어선이라는 사실을 보여준다.