뒤로

2026/11/03

서명 하나로 Binance 핫월렛이 계속 털린 이유: 침해의 배후에 있던 EIP-7702 위임

사전 서명된 EIP-7702 승인 50건 중 1건이 일치했고, 위임은 지갑이 빈 뒤에도 남았습니다. 작동 방식과 핫월렛 운영자가 모니터링해야 할 사항을 설명합니다.

Binance 침해에 관한 첫 번째 글에서는 공격이 어떻게 시작된 것으로 알려졌는지 살펴보았습니다. 침해된 DevOps 담당자의 노트북, 그리고 민감한 작업을 승인하는 시스템까지 도달한 공격자입니다. 이후 보안 기업 Blockaid의 온체인 분석을 통해 Ethereum에서 마지막 단계가 어떻게 이루어졌는지 밝혀졌습니다. 이 공격에는 2025년 5월 Ethereum에 추가된 기능인 EIP-7702가 사용되었으며, 많은 핫월렛 운영자가 아직 대비하지 못한 위험을 보여 줍니다.

요약하면, 서명된 승인 하나가 Binance의 최대 Ethereum 핫월렛을 공격자가 제어할 수 있는 계정으로 바꾸어 놓았습니다. 그 제어권은 지갑이 비었을 때도 끝나지 않았고, 키를 교체했더라도 끝나지 않았을 것입니다.

핵심 요약

  • 공격자는 연속된 50개의 논스에 해당하는 사전 서명된 EIP-7702 승인 50건을 하나의 트랜잭션에 담았습니다. 그중 정확히 1건이 일치하면서 지갑의 실행 권한이 공격자의 컨트랙트로 넘어갔습니다.
  • EIP-7702 위임은 계정이 직접 교체하거나 해제할 때까지 유지됩니다. 첫 번째 인출 이후 들어온 입금(한때 2억 달러 이상)도 새로운 서명 없이 탈취되었습니다.
  • 위임은 주소에 귀속되므로 개인 키를 교체해도 위임은 사라지지 않습니다. 명시적인 철회만이 위임을 해제합니다.
  • 공격자가 유효한 서명 50건을 어떻게 확보했는지는 아직 밝혀지지 않았습니다. Binance는 개인 키 유출의 증거를 발견하지 못했다고 밝혔습니다.
  • 핫월렛 운영자는 위임 상태를 모니터링하고, 의도하지 않은 승인에는 서명을 거부하며, 명시적인 철회 절차를 사고 대응 런북에 포함해야 합니다.

EIP-7702 기초

EIP-7702는 일반 Ethereum 계정(외부 소유 계정, EOA)이 자신의 실행을 스마트 컨트랙트에 위임할 수 있게 해 줍니다. 계정 소유자는 컨트랙트 주소, 체인, 계정의 현재 논스를 지정한 승인에 서명합니다. 이 승인을 담은 트랜잭션이 처리되면, 해당 계정에 대한 호출은 마치 계정이 스마트 컨트랙트 지갑인 것처럼 컨트랙트의 코드를 실행합니다. 이 기능은 트랜잭션 일괄 처리나 사용자 대신 수수료를 지불하는 것과 같은 정당한 목적을 위해 존재합니다.

이번 사고에서는 사양의 다음 세 가지 사항이 중요합니다.

  • 승인은 새로운 트랜잭션 유형인 타입 4(0x04)로 전달되며, 하나의 트랜잭션에 여러 승인을 담을 수 있습니다. 이 트랜잭션은 누구나 제출할 수 있고, 승인에는 계정의 유효한 서명만 있으면 됩니다.
  • 각 승인은 그 논스가 계정의 현재 논스와 같을 때만 유효합니다. 일치하지 않으면 해당 승인만 건너뛰고 트랜잭션은 다음 승인으로 넘어갑니다.
  • 위임은 영구적입니다. 계정이 다른 곳을 가리키는 새 승인이나, 위임을 해제하는 제로 주소를 가리키는 승인에 서명할 때까지 유지됩니다.

Binance 14 지갑은 어떻게 장악되었나

거래소의 바쁜 핫월렛은 끊임없이 트랜잭션을 보내므로 논스가 계속 바뀝니다. 서명된 승인을 미리 준비하는 공격자는 트랜잭션이 처리되는 시점에 어떤 논스가 유효할지 알 수 없습니다. Blockaid의 분석에 따르면, 공격자는 단일 값 대신 일정 범위에 서명하는 방식으로 이 문제를 해결했습니다.

시각(UTC, 10월 29일)발생한 일
15:59공격자가 ‘스위퍼(sweeper)’ 컨트랙트를 배포합니다. 이 컨트랙트는 검증되지 않았으며 공격자의 운영자 주소만 호출할 수 있습니다.
20:20:59하나의 타입 4 트랜잭션에 연속된 50개 논스에 대한 EIP-7702 승인 50건이 담겨 있었고, 모두 Binance 14 핫월렛의 키로 서명되어 있었습니다. 그중 정확히 1건이 지갑의 현재 논스와 일치했고, 지갑은 스위퍼에 위임되었습니다.
20:24:23스위퍼를 한 번 호출하여 약 167,464 ETH, 16억 1,500만 USDT, 그리고 수십 종의 다른 토큰을 지갑에서 빼내고, 수수료용으로 1 ETH만 남겼습니다.
20:41여전히 위임된 상태의 지갑을 이용해 Binance 14가 제어하던 별도의 스마트 계정에서 약 8억 2,300만 USDC를 옮겼습니다.
21:04~23:56새 자금이 들어올 때마다 지갑에서 네 차례 더 인출이 이루어졌습니다. 21:44 한 번에만 2억 달러가 넘는 신규 입금이 새로운 서명 없이 탈취되었습니다.
00:10(10월 30일)Hypernative의 타임라인에 따르면 위임이 철회되었습니다.

USDC 사례는 또 다른 영향을 보여 줍니다. 위임된 계정은 다른 컨트랙트에서 가진 모든 역할(소유자, 실행자, 승인된 지출자)을 그대로 유지합니다. 그 계정의 실행을 제어하는 자는 이 모든 역할을 사용할 수 있습니다.

빈 지갑이 여전히 위험했던 이유

도난 이후에는 빈 지갑은 더 잃을 것이 없고, 새 키로 바꾸면 공격자의 접근이 끝난다고 생각하기 쉽습니다. 하지만 EIP-7702에서는 둘 다 틀린 생각입니다. 위임은 잔액이나 특정 키 사본이 아니라 주소에 귀속됩니다. 위임이 유지되는 한, 그 주소로 보내진 모든 것은 위임된 컨트랙트가 인출할 수 있으며 공격자는 추가 서명이 필요 없습니다.

이번에 실제로 그런 일이 벌어졌습니다. 첫 인출 이후에도 Binance 14로 자금이 계속 들어왔고, 그 자금도 다시 인출되었습니다. 키를 교체해도 소용이 없었을 것입니다. Blockaid가 지적하듯, 위임을 해제하려면 같은 계정에서 제로 주소를 가리키는 새 승인이 필요합니다. 그 철회가 처리될 때까지 해당 주소는 공격자가 제어하는 것으로 간주해야 합니다.

팁: 사고가 발생하면 먼저 위임을 철회한 다음 키를 교체하고 자금을 다시 채우십시오. 위임이 해제된 것을 확인할 때까지 영향을 받은 주소로 자금을 보내는 모든 자동화 프로세스를 중지하십시오.

아직 밝혀지지 않은 점

50건의 승인 모두 Binance 14 키의 유효한 서명을 가지고 있었습니다. 크게 두 가지 설명이 가능하지만, 공개된 증거만으로는 아직 어느 쪽인지 판단할 수 없습니다.

  • 키가 유출되었다: 공격자가 승인에 직접 서명했습니다.
  • 서명 인프라가 악용되었다: 공격자가 키를 빼내지 않고도 Binance 자체 서명 시스템이 공격자가 고른 페이로드에 서명하도록 만들었습니다.

Binance는 지갑 개인 키 유출의 증거를 발견하지 못했으며 조사가 진행 중이라고 밝혔습니다. Blockaid의 CEO는 Cointelegraph에 이번 활동이 키 유출보다는 서명 인프라 침해로 보인다고 말했지만, 이는 외부의 예비적인 평가입니다. Binance가 사후 분석 보고서를 공개할 때까지 저희는 이 문제를 미해결로 봅니다.

핫월렛을 운영한다면 해야 할 일

1. 위임 상태 모니터링

위임된 계정에는 코드가 있습니다. EIP-7702에서 그 코드는 위임 표시자 0xef0100 뒤에 위임 대상 컨트랙트의 20바이트 주소가 이어진 형태입니다. 일반 EOA에는 코드가 전혀 없습니다. 어떤 주소든 표준 JSON-RPC 호출로 확인할 수 있습니다.

curl -s -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0xYOUR_HOT_WALLET","latest"]}' \
  https://YOUR_RPC_ENDPOINT

결과가 0x이면 위임이 없다는 뜻입니다. 결과가 0xef0100으로 시작하면 해당 주소는 위임된 상태입니다. 모든 핫월렛에 대해 블록마다 또는 짧은 간격으로 이를 확인하고, 계획하지 않은 변경이 있으면 즉시 경보를 울리십시오.

2. 자사 주소가 관련된 타입 4 트랜잭션 감시

지갑을 위임시키는 트랜잭션이 반드시 그 지갑에서 보내질 필요는 없습니다. 자사 키로 서명된 유효한 승인을 담고 있다면 누구나 제출할 수 있습니다. 자사 주소에서 보낸 트랜잭션뿐 아니라, 승인 목록에 자사 주소의 서명이 포함된 타입 4 트랜잭션도 모니터링하십시오.

3. 위임 목록 관리

운영하는 각 주소에 대해 애초에 위임되어야 하는지, 그렇다면 어떤 감사 완료 컨트랙트에 위임되어야 하는지 기록하십시오. 그 목록에 없는 위임은 모두 사고입니다. EIP-7702를 사용하지 않는다면 모든 핫월렛의 기대 상태는 간단합니다. 바로 ‘코드 없음’입니다.

4. 서명 단계에서 예상치 못한 승인 거부

EIP-7702 승인에는 고유한 서명 형식이 있습니다. 바이트 0x05 뒤에 인코딩된 체인 ID, 컨트랙트 주소, 논스를 붙인 값의 해시입니다. 서명 서비스와 HSM 정책은 이 형식을 식별할 수 있습니다. 위임을 사용하지 않는다면 이러한 페이로드를 완전히 차단하고, 사용한다면 알려진 컨트랙트 주소만 허용하십시오. 또한 체인 ID가 0인 승인은 모든 체인에서 유효하다는 점에 유의하십시오.

5. 명시적 철회를 사고 대응 런북에 포함

지갑별로 위임을 철회하는 방법을 문서화하십시오. 누가 제로 주소 승인에 서명하는지, 어느 시스템에서 하는지, 그리고 적용되었는지를 어떻게 확인하는지(주소의 코드가 다시 0x가 되었는지)입니다. 영향을 받은 주소로의 입금 중단도 포함하고, 필요해지기 전에 절차를 연습해 두십시오.

팁: 같은 원칙은 암호화폐 외의 영역에도 적용됩니다. OAuth 리프레시 토큰, 위임된 클라우드 역할, 장기 CI/CD 토큰처럼 이를 만든 자격 증명보다 오래 유지되는 권한 부여에는 사고 대응 시 별도의 명시적 철회 단계가 필요합니다.

LOGIQ가 도울 수 있는 일

LOGIQ는 Linux 서버, 클라우드 계정, 파이프라인 전반에서 누가, 그리고 무엇이 권한을 가지고 작업할 수 있는지 점검하고, 비밀번호와 키뿐 아니라 위임된 접근까지 다루는 모니터링 및 사고 대응 절차를 구축하도록 돕습니다. 귀사의 통제 체계를 다시 한번 점검하고 싶으시다면 위의 침해 관련 첫 번째 글을 읽어 보시거나 웹사이트를 통해 문의해 주십시오.

출처