返回

2026/11/03

一個簽章為何能持續掏空 Binance 熱錢包：攻擊背後的 EIP-7702 委派

50 份預先簽署的 EIP-7702 授權、一份命中，委派在錢包清空後依然有效。本文解析其原理，以及熱錢包營運方應監控哪些項目。

在我們關於 Binance 入侵事件的第一篇文章中，我們探討了攻擊據報導是如何開始的：一台遭入侵的 DevOps 筆記型電腦，以及攻擊者隨後進入了負責核准敏感操作的系統。此後，資安公司 Blockaid 的鏈上分析揭露了攻擊在 Ethereum 上最後階段的運作方式。它利用了 EIP-7702——2025 年 5 月加入 Ethereum 的一項功能——並凸顯出許多熱錢包營運方尚未納入規劃的風險。

簡單來說：一份簽署的授權，就讓 Binance 最大的 Ethereum 熱錢包變成攻擊者可以控制的帳戶。這種控制並未在錢包被清空時結束，即使輪換金鑰也不會結束。

重點摘要

  • 攻擊者將涵蓋 50 個連續 nonce 的 50 份預先簽署 EIP-7702 授權打包進一筆交易；其中恰好一份相符，錢包的執行權因此交給了攻擊者的合約。
  • EIP-7702 委派會持續有效，直到帳戶取代或清除它。首次轉移之後入帳的存款（某一時刻超過 2 億美元）在沒有任何新簽章的情況下被轉走。
  • 輪換私鑰無法解除委派，因為委派屬於位址本身。只有明確的撤銷操作才能清除它。
  • 攻擊者如何取得 50 個有效簽章仍是未解之謎。Binance 表示尚未發現私鑰外洩的證據。
  • 熱錢包營運方應監控委派狀態，拒絕簽署非預期的授權，並將明確的撤銷步驟納入事件應變手冊。

EIP-7702 快速入門

EIP-7702 讓一般的 Ethereum 帳戶（外部擁有帳戶，即 EOA）可以將其執行委派給智慧合約。帳戶擁有者簽署一份授權，其中指定合約位址、鏈以及帳戶目前的 nonce。攜帶該授權的交易被處理後，對該帳戶的呼叫就會執行該合約的程式碼，就像這個帳戶是智慧合約錢包一樣。這項功能有其正當用途，例如批次處理交易，以及代替使用者支付手續費。

規格中有三個細節與本次事件密切相關：

  • 授權透過一種新的交易類型——類型 4（0x04）——傳遞，一筆交易可以攜帶一份授權清單。任何人都可以提交這筆交易；授權只需要帶有該帳戶的有效簽章。
  • 每份授權只有在其 nonce 等於帳戶目前的 nonce 時才有效。若不相符，只會略過這一份授權，交易會繼續處理下一份。
  • 委派是持久的。它會一直存在，直到帳戶簽署一份指向其他位址的新授權，或一份指向零位址的授權（後者會清除委派）。

Binance 14 錢包是如何被接管的

繁忙的交易所熱錢包會不斷送出交易，因此它的 nonce 一直在變動。事先準備簽署授權的攻擊者無法得知交易上鏈時哪個 nonce 才是目前的值。根據 Blockaid 的分析，攻擊者的解法是簽署一個範圍，而不是單一數值。

時間（UTC，10 月 29 日）事件經過
15:59攻擊者部署了一個「清掃」（sweeper）合約。該合約未經驗證，只有攻擊者的操作位址可以呼叫。
20:20:59一筆類型 4 交易攜帶了 50 份 EIP-7702 授權，全部以 Binance 14 熱錢包的金鑰簽署，對應 50 個連續的 nonce。其中恰好一份與錢包的即時 nonce 相符，錢包隨即被委派給清掃合約。
20:24:23對清掃合約的一次呼叫，就從錢包轉走約 167,464 ETH、16.15 億 USDT 以及數十種其他代幣，只留下 1 ETH 支付手續費。
20:41在仍處於委派狀態下，該錢包被用來從 Binance 14 控制的另一個智慧帳戶轉走約 8.23 億 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、合約位址與 nonce，再取其雜湊值。簽章服務與 HSM 政策可以辨識這種格式。如果您不使用委派，請完全封鎖這類資料；如果有使用，只允許已知的合約位址。另請注意，鏈 ID 為 0 的授權在所有鏈上都有效。

5. 將明確的撤銷步驟納入事件應變手冊

為每個錢包寫明如何撤銷委派：由誰簽署零位址授權、從哪個系統簽署，以及如何確認撤銷已生效（位址的程式碼重新變為 0x）。其中也應包括停止對受影響位址的入帳轉帳，並在真正需要之前演練這套程序。

提示： 同樣的觀念也適用於加密貨幣以外的領域。任何比建立它的憑證存續更久的授權，例如 OAuth 更新權杖、委派的雲端角色或長期有效的 CI/CD 權杖，都需要在事件應變中有獨立且明確的撤銷步驟。

LOGIQ 能提供哪些協助

LOGIQ 協助企業檢視在其 Linux 伺服器、雲端帳戶與流水線中，哪些人員與系統能以何種權限執行操作，並建立涵蓋委派存取（而不只是密碼和金鑰）的監控與事件應變流程。如果您希望有人再幫忙檢視自己的控管措施，歡迎閱讀上文提到的我們關於此次入侵的第一篇文章，或透過我們的網站與我們聯絡。

參考資料