바이낸스 해킹 사고로 바로 알아보는 EIP-7702

최근 발생한 바이낸스 이더리움 출금 계정(핫월렛) 해킹 사고와 관련해 추가 견해를 정리합니다. 이번 사건을 계기로 EIP-7702를 마치 위험한 스펙인 것처럼 다루는 글이 많아, 이 스펙과 사고 구조를 좀 더 정확하게 이해해 보고자 이 글을 씁니다.

EIP-7702의 위험은 본질적으로 ERC-20 approve와 같은 ‘서명 승인’의 문제다

EIP-7702는 잘못 승인하면 돌이킬 수 없을 만큼 위험합니다. 하지만 ERC-20의 approve 함수도 마찬가지입니다. 스마트 컨트랙트의 특성상 서명과 승인에 대한 책임은 해당 계정과 서명자에게 있습니다. 즉, 잘못 실행된 ERC-20 approve와 잘못 서명된 EIP-7702 위임은 본질적으로 같은 종류의 위험입니다.

EIP-7702가 조금 더 위험하다고 볼 수 있는 차이는 범위에 있습니다. approve는 승인한 토큰과 수량으로 권한이 한정됩니다. 반면 악성 컨트랙트에 EIP-7702로 위임하면, 그 컨트랙트는 토큰 단위가 아니라 계정 전체에 대한 권한을 갖게 됩니다. 그래서 계정이 현재 보유한 ETH와 모든 ERC-20 토큰뿐 아니라, 위임을 해제하기 전까지 새로 들어오는 자산까지 마음대로 인출할 수 있습니다.

이 부분은 EIP-7702가 처음 등장했을 때 저 역시 우려했던 지점입니다. 하지만 다시 생각해 보면, 이 또한 근본 원인은 잘못된 서명 승인이므로 납득할 수 있는 설계라고 봅니다.

흔한 오해

• “EIP-7702를 사용하는 시스템은 위험하다?”→ 그렇지 않습니다. 현재 메타마스크의 Smart Account 기능도 EIP-7702를 사용합니다. EIP-7702를 쓴다는 사실만으로 위험하다고 본다면, 이미 이 기능을 쓰는 수많은 메타마스크 지갑도 지금 모두 위험하다는 말이 되어 버립니다.
• “바이낸스가 EIP-7702를 사용하고 있었기 때문에 해킹당했다?”→ 아닙니다. 바이낸스 EOA 출금 계정(Binance 14)을 보면 사고 이전에는 7702 위임을 한 이력이 없습니다(참고). 바이낸스의 11월 3일 초기 조사 보고서에 따르면 이 계정은 MPC(Multi-Party Computation) 지갑이었고, 공격자는 개인키가 아니라 내부 지갑 서명 서비스에 대한 무단 접근을 이용했습니다. 또한 MPC 구조상 위임 해제에 바로 서명할 단일 개인키가 없었기 때문에, 바이낸스는 0x0 주소를 지정해 위임을 해제하는 authorization을 만들기 위해 별도의 절차를 개발해 실행해야 했습니다. 그 결과 위임은 적용된 지 약 4시간이 지난 10월 30일 00:10(UTC)에야 해제되었습니다. 즉, 바이낸스에는 EIP-7702 위임을 즉시 해제할 절차가 마련되어 있지 않았습니다.

스프레이(spray) 공격

스프레이 공격이란?

‘스프레이’라는 이름 때문에 공개키 암호에 대한 공격이나 무차별 대입 공격처럼, 여러 번 시도하다가 그중 하나가 성공한 것으로 이해하기 쉽습니다.

하지만 이번 공격은 키를 맞히려는 시도가 아니었습니다. 공격자가 MPC 지갑의 서명 서비스에 임의로 서명을 요청할 수 있게 된 순간, 지갑은 이미 사실상 탈취된 상태입니다. MPC 키 자체가 깨진 것이 아니라, 그 키로 서명하는 시스템이 장악된 것입니다. 공격자는 내부 지갑 서명 서비스를 무단으로 이용해 위임 서명을 받아냈습니다.

그리고 받아낸 서명은 바이낸스 계정이 아니라 공격자가 통제하는 외부 계정에서 트랜잭션에 담아 제출했습니다. EIP-7702의 authorization은 누가 제출하든, 서명이 유효하고 chain ID와 nonce 조건만 맞으면 체인에 반영되기 때문입니다. 따라서 여기서 중요한 것은 누가 트랜잭션을 보냈느냐가 아니라, 바이낸스의 서명 시스템이 공격자에게 유효한 서명을 만들어 주었다는 사실입니다.

왜 이렇게 했을까?

거래소의 출금 계정은 실시간으로 유저 요청을 받아 외부 출금을 계속 처리합니다. 그래서 공격자가 위임 서명을 받는 시점과 그 위임이 실제로 체인에 반영되는 시점 사이에도 계정의 nonce는 계속 증가합니다. 하나의 nonce 값으로만 서명을 받으면, 그 사이 정상 출금이 해당 nonce를 먼저 써 버려 위임이 무효가 될 수 있습니다.

그래서 공격자는 앞으로 올 수 있는 여러 nonce 값에 대한 위임 서명을 한꺼번에 받아 ‘뿌린’ 것으로 볼 수 있습니다. 실행 시점의 nonce가 서명해 둔 범위 안에만 있으면 그중 하나가 적용되도록 한 것입니다. EIP-7702 트랜잭션은 하나의 트랜잭션 안에 여러 개의 authorization을 담을 수 있고, nonce가 맞지 않는 authorization은 트랜잭션 전체를 실패시키지 않고 건너뛰기만 하기 때문에 이런 방식이 가능합니다.

실제 위임 트랜잭션에는 nonce 18914775부터 18914824까지 50개의 authorization이 내림차순(18914824 → 18914775)으로 담겨 있었고, 50개 모두 Binance 14의 유효한 서명이었습니다. 그중 당시 계정 nonce와 일치한 18914809 하나만 적용되었습니다. 적용 후 계정 nonce는 18914810으로 증가했지만, 그보다 큰 nonce를 가진 항목은 이미 앞에서 건너뛰었으므로 다시 검사되지 않았습니다(상세 분석).

공격자는 왜 EIP-7702를 이용했을까?

• EIP-7702는 비교적 최근에 도입된 스펙입니다.
• 바이낸스의 이상 탐지 시스템이 대응하기 더 어려운 경로를 노렸을 가능성이 있습니다.
• 서명만 받아내면 트랜잭션은 외부 계정에서 제출할 수 있으므로, 바이낸스 계정에서 트랜잭션을 보낼 필요가 없습니다.
• EOA가 다시 서명해 위임을 변경하기 전까지는 위임된 컨트랙트 수준에서 계속 동작할 수 있습니다. 즉, 추가 서명 없이도 승인된 악성 컨트랙트를 통해 계정 권한을 계속 행사할 수 있습니다.
• 한 번의 트랜잭션으로 여러 동작을 묶어 실행할 수 있습니다.

EIP-7702 책임론

이번 사고에 대해서는 4Pillars의 최근 글 바이낸스 해킹 사고를 바라보며가 잘 정리하고 있습니다. 그중 EIP-7702 프로토콜 책임론에 해당하는 주장에는 동의하기 어려워 반박을 덧붙입니다.

주장 1: 위임 덕분에 단 한 번의 호출로 자산을 옮길 수 있었다

위임이 없었다면 공격자는 60종이 넘는 자산을 옮기기 위해 토큰마다 트랜잭션을 보내야 했고, 그 트랜잭션들은 바이낸스의 정상 출금과 논스를 두고 경쟁하다 상당수가 실패했을 것이다. 위임 덕분에 공격자는 단 한 번의 호출로 $2.53B을 옮길 수 있었다.

반박: 핵심은 탈취가 성공할 수 있었느냐입니다. 서명 체계가 이미 장악된 상태라면, 공격자는 EIP-7702 없이도 nonce를 연속으로 지정한 여러 트랜잭션에 서명을 받아 한 블록 안에 제출해서, 탐지 시스템이 반응하기 전에 자산을 옮길 수 있습니다. EIP-7702가 공격의 성공 확률과 규모를 높인 것은 맞지만, 위임 기능이 탈취의 원인은 아닙니다.

4Pillars 글에 함께 정리된 반대 측 입장도 같은 점을 짚고 있습니다.

50개의 위임 승인에 서명할 수 있었던 공격자라면 일반 송금에도 얼마든지 서명할 수 있었다. 실제로 같은 시각 바이낸스 16과 다른 아홉 개 체인의 지갑들은 EIP-7702 없이 평범한 서명만으로 털렸다.

주장 2: 위임은 탐지·대응할 시간을 없앤다

서명 시스템이 뚫리더라도 과거에는 공격자가 트랜잭션마다 새로 서명을 받아야 했고, 접근을 끊으면 유출도 멈췄다. 위임은 단번에 계정 전체를 넘기기 때문에 탐지하고 대응할 시간을 없앤다.

실제로 공격자는 첫 스윕 이후 바이낸스 14의 서명 없이도 두 시간 넘게 새 입금을 가져갔다.

출금 한도나 속도 제한이 보안의 기본인 이유는 대응할 시간을 벌어주기 때문인데, 위임 기능은 그 시간을 제거해버린다.

반박: 출금 한도나 속도 제한은 피해를 줄일 수는 있어도, 이번 사고의 근본 해결책은 아닙니다. 대응 속도 문제 역시 앞서 말한 것처럼 여러 트랜잭션을 한 블록에 미리 제출하는 방식으로 상당 부분 우회할 수 있습니다. 위임이 포함된 블록을 감지하는 즉시 위임을 해제하는 시스템이 있었다면 조금 더 안전했을 수는 있겠지만, 이 또한 근본적인 해결책은 아닙니다.

위임이 해제되기 전까지 공격자가 계정 권한을 계속 행사할 수 있다는 점은 앞서 짚은 것처럼 공격자에게 분명한 이점이었습니다. 하지만 그것은 이미 탈취된 권한을 더 오래 쓰게 해 준 것일 뿐, 탈취의 원인은 아닙니다.

EIP-7702 덕분에 ERC-20 토큰의 approve와 transfer를 한 번에 실행할 수 있게 되었지만, 같은 기능이 이번처럼 해킹에 악용되기도 합니다. 문제는 기능 자체가 아니라 서명 권한이 탈취되었다는 데 있습니다.

EIP-7702를 폐기해야 하는가?

• 이 스펙이 무조건 좋다는 뜻은 아닙니다. 다만 이미 프로토콜에 자리 잡았고, 이 스펙 덕분에 가능해진 장점도 많습니다.
• 현실적으로 지금 와서 폐기하기도 어렵습니다. EIP-7702는 Pectra 하드포크로 이미 메인넷에 활성화되어 있습니다. 폐기하려면 별도의 하드포크가 필요하고, 이미 위임을 사용 중인 계정들도 영향을 받습니다.
• ERC-4337(paymaster)이나 ERC-2771(메타 트랜잭션)처럼 별도 인프라가 필요한 방식보다 간단하게 수수료 대납을 구현할 수 있고, ERC-4337 인프라와 함께 쓸 수도 있습니다.

마치며

이번 사고는 보이스피싱에 쓰이는 원격제어 앱을 떠올리면 이해하기 쉽습니다. 피해자의 OTP나 보안카드가 털린 것이 아닙니다. 공격자는 이미 인증된 피해자의 휴대폰을 원격으로 조종해 이체 버튼을 누르게 했습니다. 정상 기기에서 정상 인증을 거친 요청이므로, 인증 수단을 지키는 것만으로는 막기 어렵습니다.

EIP-7702는 강력한 만큼 잘못 서명했을 때의 피해도 큰 스펙입니다. 하지만 이번 사고의 본질은 스펙의 결함이 아니라 서명 권한을 가진 시스템이 장악되었다는 데 있습니다. 논의의 초점도 스펙 폐기보다는 서명 시스템의 보안과 위임 승인에 대한 탐지·대응 체계에 맞춰져야 한다고 생각합니다.

참고 자료

• Binance, 29 October Binance Security Incident: Initial Findings and Response Update
• Four Pillars, 바이낸스 해킹 사고를 바라보며
• Halborn, Binance Hack Report: The Signing Service Answered, Four Days On
• Hypernative, Inside the Largest Crypto Theft of All Time
• 바이낸스 Ethereum 지갑 유출과 EIP-7702 nonce-range spray 분석
• EIP-7702: Set Code for EOAs