지갑 확장 프로그램 침해 공지를 읽을 때는 제품 이름만 보지 말고 공식 스토어의 확장 ID, publisher, 설치된 version, 자동 업데이트 시각을 먼저 대조한다. 이어서 사고가 확장 자체의 악성 업데이트인지, DApp이 불러온 연결 library 문제인지 분리한다. 단순 설치·페이지 접속·지갑 연결·거래 서명·비밀문구 입력은 노출 수준이 다르므로 각 행동의 증거에 맞춰 업데이트, 승인 점검, 자산 이동을 선택해야 한다.
같은 이름보다 확장 ID와 게시자를 확인한다
검색 광고나 유사한 아이콘으로 만든 가짜 확장은 정식 제품과 이름이 같을 수 있다. 공지에 적힌 Chrome Web Store·브라우저별 공식 링크에서 확장 ID와 publisher를 확인하고, 브라우저의 확장 관리 화면에 표시된 값을 대조한다. Trust Wallet은 공식 다운로드 경로를 자사 browser extension 페이지와 앱 스토어 링크로 연결하고, 가짜 앱을 피하려면 공식 웹사이트가 안내하는 링크를 사용하라고 설명한다.
설치 파일을 임의 사이트에서 다시 받으면 확인 과정이 무너진다. 제거 후 재설치가 필요한 상황이라도 복구 문구가 준비됐는지 먼저 확인하고 공식 스토어 경로만 쓴다. 공지에 확장 ID가 없으면 제품명만으로 내가 쓰는 항목이 대상이라고 단정하지 말고 지원 채널에 식별 정보를 요구한다.
제품 이름은 표지이고, 확장 ID와 게시자는 사고 범위를 가르는 식별자다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 같은 이름보다 확장 ID와 게시자를 확인한다
검색 광고나 유사한 아이콘으로 만든 가짜 확장은 정식 제품과 이름이 같을 수 있다.
- 영향 버전과 자동 업데이트 시각을 맞춘다
영향 버전이 발표되면 현재 version만 보지 않는다.
- 확장 침해와 연결 library 사고는 범위가 다르다
지갑 화면에 문제가 나타났다고 확장 프로그램 자체가 침해된 것은 아니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
영향 버전과 자동 업데이트 시각을 맞춘다
영향 버전이 발표되면 현재 version만 보지 않는다. 브라우저가 백그라운드에서 자동 업데이트했을 수 있으므로 설치·업데이트 이력, 브라우저 종료 여부, 사고 시간대에 확장을 사용했는지를 함께 확인한다. 공지가 시작과 종료 시각을 UTC로 제시했다면 한국 시간으로 바꾸고 지갑 활동 기록과 나란히 놓는다.
안전 버전으로 바뀌었다는 사실은 과거 노출을 지우지 않는다. 영향 창에 DApp을 열고 요청을 서명했다면 transaction hash와 typed data 내용을 확인한다. 반대로 설치만 했고 공지가 seed나 local storage 탈취를 말하지 않는다면 즉시 모든 자산을 옮기라는 결론부터 내리지 않는다.
| 관찰된 행동 | 확인할 증거 | 우선 대응 |
|---|---|---|
| 설치만 함 | version·업데이트 시각 | 공식 안전 버전 적용 |
| 페이지를 열음 | 방문 기록·공지 영향 창 | 세션과 요청 내역 확인 |
| 지갑을 연결함 | 연결 사이트·권한 | 불필요한 연결 해제 |
| 거래·permit 서명 | hash·spender·금액 | 승인 취소와 자산 점검 |
| 비밀문구 입력 | 입력 화면·시각 | 새 지갑으로 안전 이전 |
확장 침해와 연결 library 사고는 범위가 다르다
지갑 화면에 문제가 나타났다고 확장 프로그램 자체가 침해된 것은 아니다. Ledger는 2023년 Connect Kit 사고에서 악성 npm package가 이를 동적으로 불러온 DApp에 drain 화면을 주입했다고 밝혔고, Ledger hardware와 Ledger Live의 무결성은 영향받지 않았다고 구분했다. 이 사례는 연결 경로 사고를 확장 전체 침해로 확대 해석하지 말아야 한다는 기준을 준다.
확장 자체 악성 업데이트라면 설치된 확장이 열리는 여러 사이트와 local data 접근 범위를 검토한다. DApp library 문제라면 해당 library를 로드한 페이지와 시간대가 중심이다. 공지는 affected component, version, browser, 배포 채널과 함께 이 경계를 명시해야 이용자가 불필요한 자산 이동을 피할 수 있다.
키 노출과 악성 서명을 같은 사건으로 묶지 않는다
비밀문구나 private key가 공격자에게 전달됐다면 기존 주소의 통제권 자체가 흔들린다. 깨끗한 기기에서 새 seed로 만든 지갑으로 자산을 옮기고, 토큰뿐 아니라 NFT·스테이킹·브리지 대기 자산까지 확인해야 한다. 복구 문구를 채팅·폼·확장 팝업에 입력하라는 안내는 공식 지원을 사칭한 2차 피싱일 가능성이 크다.
악성 approval이나 permit을 서명했지만 키 유출 증거가 없다면 위험은 승인 대상과 체인에 한정될 수 있다. transaction input, spender, allowance, nonce를 확인하고 공식 탐색기나 검증된 권한 관리 도구에서 취소한다. 단순 connect는 보통 공개 주소를 보여 주지만, 그 뒤 나타난 signature request를 승인했는지는 별도 질문이다.
- 공식 링크에서 확장 ID·publisher를 확인한다
- 영향 version과 자동 업데이트 시각을 맞춘다
- 접속·연결·서명·비밀문구 입력을 분리한다
- 거래 hash와 spender를 저장한다
- 지원 사칭 메시지에 복구 문구를 입력하지 않는다
업데이트 공지는 원인과 재발 방지까지 보여야 한다
안전 버전 번호만 적은 공지는 검증이 부족하다. 게시 계정 탈취인지, dependency 오염인지, build pipeline 문제인지 밝히고 악성 version 제거 시각과 store 검토 상태를 제시해야 한다. extension permission이 바뀌었다면 왜 필요한지와 기존 local key가 어떻게 보호되는지도 설명해야 한다.
Trust Wallet의 보안 개요는 browser extension이 private key를 이용자 기기에 local로 저장하고 보안 감사·버그바운티·책임 있는 취약점 신고 절차를 운영한다고 설명한다. 이는 평상시 설계 자료이며 특정 사고가 없었다는 보증은 아니다. 사고 공지에서는 실제 로그·영향 version·완화 조치를 별도로 요구해야 한다.
확인 기록을 남기고 과잉 대응을 줄인다
브라우저 종류, 확장 ID, 사고 당시와 현재 version, 마지막 사용 시각, 방문 DApp, 서명 hash를 한 표에 남긴다. 화면 캡처에는 seed나 private key가 들어가지 않게 하고 확장 진단 파일을 공개 채널에 올리지 않는다. 지원 문의 번호와 답변 원문도 보존하면 보상·분쟁 절차에서 도움이 된다.
연결된 웹앱 문제를 조사할 때는 공급망 경로 해설도 함께 읽되, 기본적인 확장 설치 확인을 반복하지 않는다. 증거가 부족하면 ‘영향 가능’, 서명이 확인되면 ‘권한 노출’, 키 전송이 확인되면 ‘키 통제 상실’처럼 판정 수준을 분리해 기록한다.
자주 묻는 질문
안전 버전으로 자동 업데이트됐으면 끝인가요?
현재 실행 위험은 줄지만 과거 영향 창에 악성 요청을 서명했는지는 거래 기록으로 확인해야 한다.
지갑을 연결만 해도 seed가 유출되나요?
일반적인 연결은 공개 주소를 제공한다. 다만 확장 자체가 침해됐다는 공지라면 local data 접근 범위를 추가 확인한다.
확장을 지우기 전에 무엇을 준비해야 하나요?
공식 복구 절차와 안전하게 보관한 복구 수단을 확인하고 확장 ID·version·활동 증거를 비밀정보 없이 기록한다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
