Quay lại

2026/11/03

Một chữ ký đã liên tục rút cạn ví nóng của Binance như thế nào: cơ chế ủy quyền EIP-7702 đằng sau vụ tấn công

50 ủy quyền EIP-7702 ký sẵn, một cái khớp và một ủy quyền tồn tại cả khi ví đã trống. Cơ chế hoạt động và những gì đơn vị vận hành ví nóng cần giám sát.

Trong bài viết đầu tiên của chúng tôi về vụ tấn công Binance, chúng tôi đã xem xét cách cuộc tấn công được cho là bắt đầu: một máy tính xách tay DevOps bị xâm nhập, và kẻ tấn công đã tiếp cận được các hệ thống phê duyệt những thao tác nhạy cảm. Sau đó, phân tích on-chain của công ty bảo mật Blockaid đã cho thấy giai đoạn cuối diễn ra như thế nào trên Ethereum. Nó sử dụng EIP-7702, một tính năng được bổ sung vào Ethereum vào tháng 5 năm 2025, và cho thấy một rủi ro mà nhiều đơn vị vận hành ví nóng chưa tính đến trong kế hoạch của mình.

Tóm tắt ngắn gọn: chỉ một ủy quyền đã ký đã biến ví nóng Ethereum lớn nhất của Binance thành một tài khoản mà kẻ tấn công có thể điều khiển. Quyền điều khiển đó không chấm dứt khi ví đã trống, và cũng sẽ không chấm dứt nếu xoay vòng khóa.

Những điểm chính

  • Kẻ tấn công gói 50 ủy quyền EIP-7702 ký sẵn, bao phủ 50 nonce liên tiếp, vào một giao dịch duy nhất; đúng một ủy quyền khớp và trao quyền thực thi của ví cho hợp đồng của kẻ tấn công.
  • Một ủy quyền EIP-7702 vẫn có hiệu lực cho đến khi tài khoản thay thế hoặc xóa nó. Các khoản tiền gửi đến sau lần rút đầu tiên, có thời điểm hơn 200 triệu USD, đã bị lấy đi mà không cần chữ ký mới nào.
  • Xoay vòng khóa riêng không gỡ bỏ được ủy quyền, vì ủy quyền gắn với địa chỉ. Chỉ một thao tác thu hồi tường minh mới xóa được nó.
  • Kẻ tấn công lấy được 50 chữ ký hợp lệ bằng cách nào vẫn là câu hỏi bỏ ngỏ. Binance cho biết chưa tìm thấy bằng chứng nào về việc rò rỉ khóa riêng.
  • Các đơn vị vận hành ví nóng nên giám sát trạng thái ủy quyền, từ chối ký những ủy quyền ngoài dự kiến và đưa bước thu hồi tường minh vào quy trình ứng phó sự cố.

Giới thiệu nhanh về EIP-7702

EIP-7702 cho phép một tài khoản Ethereum thông thường (tài khoản sở hữu bên ngoài, hay EOA) ủy quyền việc thực thi của nó cho một hợp đồng thông minh. Chủ tài khoản ký một ủy quyền ghi rõ địa chỉ hợp đồng, chuỗi và nonce hiện tại của tài khoản. Khi một giao dịch mang ủy quyền đó được xử lý, các lệnh gọi đến tài khoản sẽ chạy mã của hợp đồng, như thể tài khoản là một ví hợp đồng thông minh. Tính năng này tồn tại vì những lý do chính đáng, chẳng hạn gộp nhiều giao dịch hoặc trả phí thay cho người dùng.

Ba chi tiết trong đặc tả có ý nghĩa quan trọng đối với sự cố này:

  • Các ủy quyền được truyền trong một loại giao dịch mới, loại 4 (0x04), có thể mang theo một danh sách ủy quyền. Bất kỳ ai cũng có thể gửi giao dịch này; ủy quyền chỉ cần có chữ ký hợp lệ của tài khoản.
  • Mỗi ủy quyền chỉ hợp lệ khi nonce của nó bằng nonce hiện tại của tài khoản. Nếu không khớp, riêng ủy quyền đó bị bỏ qua và giao dịch tiếp tục với ủy quyền kế tiếp.
  • Ủy quyền có tính bền vững. Nó tồn tại cho đến khi tài khoản ký một ủy quyền mới trỏ đến nơi khác, hoặc một ủy quyền trỏ đến địa chỉ 0, thao tác này sẽ xóa ủy quyền.

Ví Binance 14 đã bị chiếm quyền như thế nào

Một ví nóng của sàn giao dịch bận rộn gửi giao dịch liên tục, nên nonce của nó luôn thay đổi. Kẻ tấn công chuẩn bị trước một ủy quyền đã ký không thể biết nonce nào sẽ là nonce hiện tại khi giao dịch được ghi nhận. Theo phân tích của Blockaid, kẻ tấn công đã giải quyết vấn đề này bằng cách ký cho cả một khoảng giá trị thay vì một giá trị duy nhất.

Thời gian (UTC, ngày 29 tháng 10)Diễn biến
15:59Kẻ tấn công triển khai một hợp đồng “sweeper” (hút tiền). Hợp đồng này chưa được xác minh và chỉ địa chỉ vận hành của kẻ tấn công mới được gọi nó.
20:20:59Một giao dịch loại 4 mang 50 ủy quyền EIP-7702, tất cả đều được ký bằng khóa của ví nóng Binance 14, cho 50 nonce liên tiếp. Đúng một ủy quyền khớp với nonce thực tế của ví, và ví lúc này được ủy quyền cho hợp đồng sweeper.
20:24:23Một lệnh gọi duy nhất đến hợp đồng sweeper chuyển khoảng 167.464 ETH, 1,615 tỷ USDT và hàng chục loại token khác ra khỏi ví, chỉ để lại 1 ETH để trả phí.
20:41Vẫn trong trạng thái được ủy quyền, ví bị dùng để chuyển khoảng 823 triệu USDC từ một tài khoản thông minh riêng biệt do Binance 14 kiểm soát.
21:04 đến 23:56Ví bị rút thêm bốn lần nữa khi có tiền mới gửi đến. Chỉ riêng lúc 21:44, hơn 200 triệu USD tiền gửi mới đã bị lấy đi mà không cần chữ ký mới nào.
00:10 (ngày 30 tháng 10)Ủy quyền bị thu hồi, theo dòng thời gian của Hypernative.

Bước liên quan đến USDC cho thấy một tác động thứ hai. Một tài khoản được ủy quyền vẫn giữ mọi vai trò của nó trong các hợp đồng khác: chủ sở hữu, bên thực thi, bên được phép chi tiêu. Ai kiểm soát việc thực thi của tài khoản thì có thể sử dụng tất cả các vai trò đó.

Vì sao một ví trống vẫn nguy hiểm

Sau một vụ trộm, người ta thường mặc nhiên cho rằng ví trống thì không còn gì để mất, và một khóa mới sẽ chấm dứt quyền truy cập của kẻ tấn công. Với EIP-7702, cả hai giả định đó đều sai. Ủy quyền gắn với địa chỉ, chứ không gắn với số dư hay một bản sao cụ thể của khóa. Chừng nào ủy quyền còn tồn tại, mọi khoản tiền gửi đến địa chỉ đều có thể bị hợp đồng được ủy quyền rút đi, và kẻ tấn công không cần thêm chữ ký nào.

Đó chính là điều đã xảy ra ở đây. Tiền vẫn tiếp tục được gửi đến Binance 14 sau lần rút đầu tiên, và chúng lại bị rút đi. Xoay vòng khóa cũng không giúp được gì: như Blockaid chỉ ra, để xóa ủy quyền cần một ủy quyền mới từ chính tài khoản đó, trỏ đến địa chỉ 0. Cho đến khi thao tác thu hồi đó được xử lý, địa chỉ cần được coi là đang bị kẻ tấn công kiểm soát.

Mẹo: Khi xảy ra sự cố, hãy thu hồi trước, sau đó mới xoay vòng khóa và nạp lại tiền. Dừng mọi quy trình tự động gửi tiền đến địa chỉ bị ảnh hưởng cho đến khi bạn xác nhận ủy quyền đã bị gỡ bỏ.

Những gì vẫn chưa được làm rõ

Cả 50 ủy quyền đều mang chữ ký hợp lệ từ khóa của Binance 14. Có hai cách giải thích chính, và bằng chứng công khai hiện chưa đủ để kết luận cách nào đúng:

  • Khóa đã bị rò rỉ, và kẻ tấn công ký trực tiếp các ủy quyền.
  • Hạ tầng ký đã bị lạm dụng: kẻ tấn công khiến chính các hệ thống ký của Binance ký những dữ liệu do kẻ tấn công lựa chọn mà không cần lấy khóa ra.

Binance cho biết chưa tìm thấy bằng chứng về việc rò rỉ khóa riêng của ví, và cuộc điều tra vẫn đang tiếp diễn. CEO của Blockaid nói với Cointelegraph rằng hoạt động này trông giống việc hạ tầng ký bị xâm phạm hơn là khóa bị rò rỉ, nhưng đó là đánh giá sơ bộ từ bên ngoài. Cho đến khi Binance công bố báo cáo phân tích sau sự cố, chúng tôi coi câu hỏi này vẫn còn bỏ ngỏ.

Cần làm gì nếu bạn vận hành ví nóng

1. Giám sát trạng thái ủy quyền

Một tài khoản được ủy quyền thì có mã. Theo EIP-7702, mã của nó là chỉ báo ủy quyền 0xef0100 theo sau là địa chỉ 20 byte của hợp đồng được ủy quyền. Một EOA thông thường hoàn toàn không có mã. Bạn có thể kiểm tra bất kỳ địa chỉ nào bằng một lệnh gọi JSON-RPC tiêu chuẩn:

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

Kết quả 0x nghĩa là không có ủy quyền. Kết quả bắt đầu bằng 0xef0100 nghĩa là địa chỉ đã được ủy quyền. Hãy kiểm tra điều này cho mọi ví nóng ở mỗi khối hoặc theo chu kỳ ngắn, và cảnh báo ngay khi có bất kỳ thay đổi nào ngoài kế hoạch.

2. Theo dõi các giao dịch loại 4 liên quan đến địa chỉ của bạn

Giao dịch ủy quyền ví của bạn không nhất thiết phải đến từ ví của bạn. Bất kỳ ai cũng có thể gửi nó, miễn là nó mang một ủy quyền hợp lệ được ký bằng khóa của bạn. Hãy giám sát các giao dịch loại 4 có danh sách ủy quyền chứa chữ ký từ một trong các địa chỉ của bạn, chứ không chỉ các giao dịch được gửi từ những địa chỉ đó.

3. Duy trì danh mục các ủy quyền

Với mỗi địa chỉ bạn vận hành, hãy ghi lại liệu nó có nên được ủy quyền hay không và, nếu có, cho hợp đồng đã được kiểm toán nào. Bất kỳ ủy quyền nào nằm ngoài danh mục đó đều là một sự cố. Nếu bạn không dùng EIP-7702, trạng thái mong đợi của mọi ví nóng rất đơn giản: không có mã.

4. Từ chối các ủy quyền ngoài dự kiến ngay tại bộ ký

Ủy quyền EIP-7702 có định dạng ký riêng: giá trị băm của byte 0x05 theo sau là chain ID, địa chỉ hợp đồng và nonce đã được mã hóa. Các dịch vụ ký và chính sách HSM có thể nhận diện định dạng này. Nếu bạn không dùng ủy quyền, hãy chặn hoàn toàn các dữ liệu này; nếu có dùng, chỉ cho phép các địa chỉ hợp đồng đã biết. Cũng lưu ý rằng một ủy quyền có chain ID bằng 0 hợp lệ trên mọi chuỗi.

5. Đưa bước thu hồi tường minh vào quy trình ứng phó sự cố

Hãy ghi rõ cách thu hồi ủy quyền cho từng ví: ai ký ủy quyền trỏ đến địa chỉ 0, từ hệ thống nào, và cách xác nhận việc thu hồi đã có hiệu lực (mã của địa chỉ trở lại 0x). Bao gồm cả việc dừng các khoản chuyển đến địa chỉ bị ảnh hưởng, và diễn tập quy trình trước khi bạn thực sự cần đến nó.

Mẹo: Nguyên tắc này cũng áp dụng ngoài lĩnh vực tiền mã hóa. Bất kỳ quyền nào tồn tại lâu hơn thông tin xác thực đã tạo ra nó, chẳng hạn refresh token OAuth, một vai trò đám mây được ủy quyền hay một token CI/CD dài hạn, đều cần có bước thu hồi tường minh riêng trong quy trình ứng phó sự cố.

LOGIQ có thể hỗ trợ như thế nào

LOGIQ giúp các tổ chức rà soát xem ai và cái gì có thể hành động với thẩm quyền trên các máy chủ Linux, tài khoản đám mây và pipeline của họ, đồng thời xây dựng các bước giám sát và ứng phó sự cố bao quát cả quyền truy cập được ủy quyền, chứ không chỉ mật khẩu và khóa. Nếu bạn muốn có thêm một góc nhìn về các biện pháp kiểm soát của mình, hãy đọc bài viết đầu tiên của chúng tôi về vụ tấn công ở trên hoặc liên hệ với chúng tôi qua website.

Nguồn tham khảo