프로토콜 DNS 탈취는 공식 도메인의 이름 해석이나 registrar 계정이 공격자에게 넘어가 가짜 웹 화면으로 연결되는 사고다. 웹사이트가 변조됐다고 온체인 계약까지 자동으로 침해되는 것은 아니다. nameserver와 DNS record 변경 시각, TLS 인증서, 공식 복구 공지, 사용자의 접속·서명 기록을 대조하고, 악성 거래를 서명한 경우에만 승인·자산 이동 범위를 우선 조사한다.
주소창이 맞아도 서버가 바뀔 수 있다
DNS는 사람이 읽는 도메인을 서버 주소로 연결한다. registrar 계정이나 DNS provider가 탈취되면 공격자는 철자가 정확한 공식 도메인을 자기 인프라로 향하게 할 수 있다. 이용자가 북마크를 눌렀고 HTTPS 자물쇠가 보였다는 사실만으로 원래 화면임을 보증할 수 없다. 공격자가 도메인을 통제하면 새 TLS 인증서를 발급받는 경우도 있기 때문이다.
첫 확인 대상은 registrar 변경 기록, authoritative nameserver, A·AAAA·CNAME record, DNSSEC 상태, 인증서 발급 이력이다. 프로토콜 팀은 공격 이전과 이후 값을 시각과 함께 공개해야 한다. resolver cache와 TTL 때문에 복구 발표 뒤에도 지역·통신사별로 잘못된 목적지가 남을 수 있으므로 단 한 번의 정상 접속만으로 종료를 선언하지 않는다.
DNS 사고에서 주소창은 신원 증거의 일부일 뿐, 원래 서버에 도착했다는 완전한 증명은 아니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 주소창이 맞아도 서버가 바뀔 수 있다
DNS는 사람이 읽는 도메인을 서버 주소로 연결한다.
- Balancer 사례는 도메인과 계약을 분리해 보여 준다
Balancer의 BIP-443은 2023년 9월 DNS hack으로 프런트엔드가 침해됐고 영향을 받은 이용자에게 보상을 검토했다.
- 복구 발표 뒤에도 캐시 시간을 계산한다
팀이 DNS record를 원복해도 모든 resolver가 즉시 새 값을 쓰지는 않는다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
Balancer 사례는 도메인과 계약을 분리해 보여 준다
Balancer의 BIP-443은 2023년 9월 DNS hack으로 프런트엔드가 침해됐고 영향을 받은 이용자에게 보상을 검토했다. 후속 BIP-455는 두 이용자의 손실을 검증해 지급안을 제시했다. 이는 공식 도메인 화면을 통한 실제 피해가 있었음을 보여 주지만, 그 사실만으로 pool contract 전체가 탈취됐다는 뜻은 아니다.
Balancer 운영 업데이트는 사건 뒤 도메인을 EuroDNS에서 다른 provider로 옮겼다고 기록했다. 이 조치는 registrar 계층의 재발 방지다. 스마트계약 pause, admin 변경, pool 자산 이동 같은 온체인 조치와 섞어 쓰면 독자는 어느 계층이 망가졌는지 알 수 없다. 공지는 웹·DNS·contract 상태를 각각 한 줄로 선언해야 한다.
| 계층 | 확인 증거 | 알 수 있는 것 |
|---|---|---|
| Registrar | 계정 log·잠금·이전 이력 | 도메인 통제권 변화 |
| DNS | nameserver·record·TTL | 연결 목적지와 잔존 시간 |
| TLS | 인증서 발급·폐기 이력 | 가짜 서버의 HTTPS 가능성 |
| 웹 | 배포 hash·응답 body | 표시된 코드와 요청 |
| 온체인 | contract code·admin·event | 계약 권한과 자산 상태 |
복구 발표 뒤에도 캐시 시간을 계산한다
팀이 DNS record를 원복해도 모든 resolver가 즉시 새 값을 쓰지는 않는다. 사고 전 TTL, 변경 시각, authoritative server 반영 시각을 공개하면 지역별 잔존 가능성을 계산할 수 있다. 로컬 DNS cache, 브라우저 cache, service worker가 화면을 유지할 수도 있다. 불확실한 동안에는 문제 도메인에서 지갑을 연결하지 않는다.
정상화 확인은 팀의 소셜 게시물 하나에 의존하지 않는다. 공식 repository, 상태 페이지, 다중 서명된 공지처럼 공격자가 함께 장악하기 어려운 채널을 교차한다. DNSSEC을 켰다는 발표도 chain of trust가 올바르게 구성되고 resolver가 검증할 때 의미가 있다. 설정 이름만으로 과거 피해가 복구되지는 않는다.
접속과 서명을 분리해 이용자 조치를 정한다
가짜 화면을 열었지만 지갑을 연결하거나 서명하지 않았다면 transaction 기반 자산 탈취 증거는 없다. 브라우저 다운로드, 알림 권한, 입력한 이메일 같은 부수 노출은 별도로 확인한다. 지갑 연결만 했다면 공개 주소 노출과 사이트 연결을 점검하고 불필요한 연결을 끊는다.
approval, permit, setApprovalForAll, 직접 transfer를 서명했다면 chain·contract·spender·amount를 기록한다. 공격자 거래가 pending이면 신뢰할 수 있는 지갑에서 nonce 대응 가능성을 검토하고, 완료됐다면 남은 자산과 권한을 우선 보호한다. seed phrase를 가짜 화면에 입력했다면 승인 취소만으로는 부족하며 깨끗한 환경의 새 지갑이 필요하다.
- 사고 시간대를 한국 시간과 UTC로 함께 기록한다
- 방문한 정확한 hostname과 경로를 확인한다
- 연결·signature·transaction을 각각 분류한다
- spender와 allowance를 체인별로 조사한다
- 공지 캡처와 transaction hash를 보존한다
온체인이 정상이라는 문구도 직접 검증한다
팀이 contracts unaffected라고 발표하면 proxy implementation, admin·owner, multisig signer, pause event, 주요 pool 잔액을 이전 정상 상태와 대조한다. 공식 repository의 주소 목록과 탐색기의 verified contract를 교차하고, 공격 기간에 upgrade나 role change event가 없었는지 본다. 화면이 정상이라는 이유로 contract가 안전하다고 추론하지 않는다.
반대로 웹 침해가 확인됐다는 이유로 모든 contract를 위험하다고 표시해서도 안 된다. 온체인 변경 증거가 없고 악성 서명만 피해 경로였다면 계약 상태와 사용자별 승인 피해를 나눠 기록한다. 이러한 범위 구분은 정확한 대응과 보상 대상을 정하는 데 필요하다.
좋은 사후 보고서는 네 개의 시계를 공개한다
보고서에는 최초 무단 registrar 접근, DNS 변경, 악성 화면 제공 시작, record 원복과 cache 종료 추정 시각이 있어야 한다. 여기에 피해 transaction의 첫·마지막 block을 붙이면 이용자 행동과 인프라 로그를 대조할 수 있다. 단순히 ‘몇 시간 동안 영향’이라고 쓰면 TTL과 지역 차이를 검증하기 어렵다.
재발 방지는 registrar hardware key, registry lock, 역할 분리, nameserver 변경 다중 승인, 인증서 투명성 알림, 독립 상태 도메인을 포함한다. 보상안은 확인된 악성 거래, 환산 기준 시각, 수수료 포함 여부, 청구 기한을 공개해야 하며 복구 조치와 별도 문서로 관리하는 편이 명확하다.
자주 묻는 질문
HTTPS 자물쇠가 보였는데도 가짜 사이트일 수 있나요?
그렇다. 공격자가 도메인을 통제하면 유효한 인증서를 발급받을 수 있어 인증서 발급 이력과 DNS를 함께 봐야 한다.
사이트가 해킹되면 스마트계약도 바꿀 수 있나요?
자동으로 그렇지는 않다. contract admin·upgrade event·code와 웹 인프라 권한을 별도로 확인한다.
복구 공지 직후 접속해도 되나요?
TTL과 resolver cache가 남을 수 있다. 권위 DNS 반영과 독립 채널의 안전 확인 뒤 접속한다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
