디파이 프런트엔드 침해, 접속만 한 경우와 서명한 경우의 차이

디파이 프런트엔드 침해는 웹 화면이나 브라우저에 전달된 script가 변조된 사고이며 원인은 DNS, 배포 계정, CDN, dependency, analytics tag 등 여러 갈래다. 사이트를 열었다는 사실만으로 자산 이동이 발생하지는 않는다. 지갑 연결, signature request 승인, transaction 전송, seed 입력 여부를 순서대로 확인하고, 악성 build가 제공된 정확한 hostname·page·시간·cache 범위와 맞춰 개인별 노출을 판정해야 한다.

프런트엔드는 하나의 파일이 아니라 전달 경로다

사용자가 보는 디파이 화면은 repository source, CI build, hosting bucket, CDN, DNS, tag manager와 외부 package를 거쳐 완성된다. 화면이 변조됐다는 말만으로 어느 계정이 침해됐는지 알 수 없다. 팀은 최초 오염 지점, 악성 artifact hash, 영향을 받은 hostname과 route, 제공 시작·종료 시각을 공개해야 한다.

같은 도메인에서도 swap page만 악성 script를 불렀고 docs나 status page는 무관할 수 있다. 반대로 공통 layout이나 analytics tag가 오염되면 여러 route가 영향을 받을 수 있다. ‘웹사이트 전체’라는 표현 대신 어떤 response와 script가 사용자 브라우저에 도착했는지 기준으로 범위를 적는다.

프런트엔드 사고의 단위는 브랜드가 아니라 브라우저에 전달된 코드와 그 코드가 요청한 행동이다.

JOBCOIN 해설

VISUAL GUIDE키 보관과 거래 서명

1. 01
   프런트엔드는 하나의 파일이 아니라 전달 경로다

   사용자가 보는 디파이 화면은 repository source, CI build, hosting bucket, CDN, DNS, tag manager와 외부 package를 거쳐 완성된다.

2. 02
   접속만 한 경우와 서명한 경우를 구분한다

   페이지 접속만으로 일반적인 온체인 transfer가 승인되지는 않는다.

3. 03
   Ledger 사건은 제3자 package 경로를 보여 준다

   Ledger의 Connect Kit 사고 보고서는 악성 package 1.

AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

접속만 한 경우와 서명한 경우를 구분한다

페이지 접속만으로 일반적인 온체인 transfer가 승인되지는 않는다. 다만 악성 다운로드, 브라우저 취약점, 입력 정보 수집이 공지됐다면 별도 조사가 필요하다. 지갑 connect는 공개 주소와 network 정보를 사이트에 보여 줄 수 있지만 자산 이동 권한 그 자체는 아니다.

서명은 내용에 따라 결과가 달라진다. 로그인용 message, token approval, permit·Permit2, NFT setApprovalForAll, swap transaction, native asset transfer를 구분한다. hardware wallet에서 확인한 destination과 amount도 기록한다. seed phrase나 private key를 입력했다면 단일 approval 문제가 아니라 주소 통제권 문제로 다룬다.

Ledger 사건은 제3자 package 경로를 보여 준다

Ledger의 Connect Kit 사고 보고서는 악성 package 1.1.5·1.1.6·1.1.7이 게시되고 이를 동적으로 불러온 DApp 프런트에 drain 화면이 주입됐다고 설명한다. Ledger는 악성 파일 접근 가능 시간이 약 5시간이었지만 실제 drain 창은 2시간 미만으로 추정했고 CDN cache 때문에 제거 뒤에도 일부 잔존 가능성을 밝혔다.

이때 영향을 판단하는 질문은 ‘Ledger를 쓰는가’가 아니라 ‘영향 version을 동적으로 로드한 DApp을 그 시간에 열어 악성 요청을 서명했는가’다. hardware device와 Ledger Live는 영향받지 않았다고 보고됐다. 제품 이름을 사고 범위로 쓰면 무관한 이용자까지 동일 대응을 하게 된다.

DNS 사고와 배포물 사고의 증거는 다르다

DNS 탈취라면 nameserver·record·TLS 인증서와 resolver cache가 핵심이다. 배포 계정이나 hosting bucket 침해라면 artifact hash, deployment audit log, 접근 token이 중요하다. dependency 오염은 lockfile·package version·runtime loader를 보고, tag manager 사고는 container version과 publish log를 확인한다.

Balancer의 DNS 피해 보상 논의는 공식 도메인의 프런트엔드를 통해 발생한 피해 transaction을 검증했다. 후속 운영 기록은 도메인 provider 이전을 밝혔다. 이 사례를 모든 프런트 사고의 원인으로 일반화하지 않고 DNS 계층의 증거로만 쓴다. 다른 원인이라면 원인에 맞는 로그가 필요하다.

• 영향 hostname과 route를 기록한다
• 악성 artifact·script hash를 확보한다
• 배포·CDN·tag manager log를 시간순으로 맞춘다
• 사용자별 signature·transaction을 분류한다
• 캐시 종료 시각과 안전 build 검증값을 공개한다

악성 요청의 결과를 transaction 단위로 해석한다

지갑 activity에서 사고 시간대의 hash를 찾고 explorer에서 chain, to, method, token, amount를 확인한다. approval이면 spender와 allowance, permit이면 signed domain·nonce·deadline, swap이면 실제 recipient와 최소 수령량을 본다. 승인했지만 아직 사용되지 않은 권한과 이미 전송된 자산은 대응이 다르다.

팀이 피해 주소 목록을 공개하더라도 내 주소가 없다는 이유만으로 안전을 단정하지 않는다. 탐지 규칙, 지원 chain, 수집 종료 block에 따라 누락될 수 있다. 반대로 주소가 사이트를 방문했다는 분석만으로 악성 서명을 단정하지 않는다. 최종 판정은 wallet record와 chain transaction을 결합한다.

안전 배포는 재현 가능한 증거로 확인한다

복구 뒤에는 clean commit, CI run, artifact hash, CDN purge 완료, service worker version을 연결해 공개한다. 사용자는 열린 탭을 닫고 신뢰할 수 있는 채널에서 복구 공지를 확인한 뒤 새 session으로 접속한다. 단순 새로고침은 memory cache나 service worker가 옛 script를 계속 제공할 수 있어 충분하지 않을 수 있다.

CSP와 Subresource Integrity는 허용되지 않은 script나 변조된 고정 resource를 막는 데 도움이 되지만 모든 동적 코드와 정상 권한 계정의 악성 배포를 차단하지는 못한다. 배포 다중 승인, 짧은 수명의 credential, dependency pinning, 독립 모니터링을 함께 운영한다. 보호 장치의 이름보다 사건 뒤 실제 차단 증거를 본다.

피해 접수에는 최소 증거와 개인정보 경계가 필요하다

접수 양식에는 주소, chain, transaction hash, 방문 hostname·시간, 서명 당시 화면을 받되 seed·private key를 요구해서는 안 된다. 브라우저 history나 HAR에는 token과 개인정보가 들어갈 수 있으므로 필요한 필드만 가리고 제출한다. 공식 case number와 접수 기한을 확인한다.

보상 발표는 적격 transaction 판정식, 환산 시각, 수수료, 중복 지급 방지와 이의 제기 창구를 밝혀야 한다. 보상 약속과 기술 복구를 같은 문장으로 끝내지 않는다. 이용자는 증거를 보존하면서 남은 권한을 먼저 보호하고, 기술팀은 원인 계층과 사용자 영향 계층을 별도 표로 갱신한다.

자주 묻는 질문