最顶级的 MEV 机器人，被盗 750 万美元：Approval 才是链上最易忽视的致命风险？

Một bot MEV chuyên săn lùng các nhà giao dịch thông thường trên Ethereum cuối cùng cũng đã rơi vào một cái bẫy "được thiết kế riêng" trị giá 7,5 triệu đô la.

Vào ngày 21 tháng 6, bot sandwich nổi tiếng Jaredfromsubway.eth trên Ethereum đã bị tấn công. Các tài sản như WETH và USDC trong địa chỉ của nó đã bị chuyển đi, với tổn thất ban đầu ước tính hơn 7,5 triệu đô la (mặc dù các con số tổn thất được công bố hiện tại vẫn có sự khác biệt).

Điều thú vị là cuộc tấn công này không phải do rò rỉ private key, cũng không khai thác các lỗ hổng hợp đồng thông minh truyền thống, mà là kẻ tấn công đã triển khai trước một số lượng lớn token giả, pool thanh khoản và hợp đồng phụ trợ, gói ghém chúng thành các đường dẫn giao dịch có tiềm năng chênh lệch giá, dụ bot cấp quyền ERC-20 (Approval) cho hợp đồng độc hại trong quá trình tự động thực thi, cuối cùng "hợp pháp" chuyển đi tài sản của bot MEV đó.

Tính đến thời điểm viết bài, Jaredfromsubway.eth đã công khai gửi thông điệp trên chuỗi tới kẻ tấn công, tuyên bố "nếu trả lại 2.150 ETH trong vòng 48 giờ, sẵn sàng trả 50% tiền thưởng white hat, nếu không sẽ thực hiện mọi biện pháp pháp lý và cưỡng chế có thể để truy cứu trách nhiệm".

Tuy nhiên, ngay cả một bot MEV vận hành bằng mã code chuyên nghiệp cao cũng có thể vấp ngã vì Approval, điều này khiến chúng ta phải xem xét lại, hành động "Approval" mà chúng ta sử dụng hàng ngày thực sự ẩn chứa mức độ nguy hiểm lớn như thế nào?

1. Một cuộc săn ngược được thiết kế riêng cho Bot MEV

Nếu xem xét kỹ lưỡng vụ tấn công này, có thể thấy đây không phải là một lỗ hổng xảy ra ngẫu nhiên, mà là một cuộc săn lùng có chủ đích kéo dài, nhắm vào logic giao dịch của Jaredfromsubway.eth.

Jaredfromsubway.eth từ lâu đã là một trong những bot sandwich nổi tiếng nhất trên Ethereum. Nói một cách đơn giản, tấn công sandwich là khi bot phát hiện một giao dịch sắp diễn ra trên chuỗi, nó sẽ mua trước người dùng để đẩy giá lên; sau khi người dùng giao dịch ở mức giá tệ hơn, bot sẽ bán ra ngay lập tức để kiếm lời từ chênh lệch giá.

Chính vì vậy, chiến lược này yêu cầu bot phải liên tục quét các giao dịch trên chuỗi, đánh giá cơ hội chênh lệch giá với tốc độ cực nhanh, và tổ chức các đường dẫn giao dịch để gọi các token và hợp đồng khác nhau. Điều này cũng có nghĩa là tốc độ càng nhanh, càng bao phủ nhiều tài sản và giao thức, thì bot càng có nhiều cơ hội để khai thác.

Nhưng chính điểm này đã trở thành tử huyệt của vụ việc.

Theo phân tích sau sự kiện, kẻ tấn công không trực tiếp tấn công hợp đồng quỹ của bot, mà dành ra vài tuần để xây dựng một môi trường giao dịch có vẻ mang lại lợi nhuận:

• Bước một, triển khai một số lượng lớn token giả và pool thanh khoản. Các token này bắt chước các tài sản phổ biến như WETH, USDC, USDT về tên gọi, giao diện và hành vi giao dịch, khiến hệ thống nhận dạng tự động của bot nhầm tưởng rằng nó đã tìm thấy một đường dẫn giao dịch bình thường;
• Bước hai, dần dần lấy được lòng tin của bot. Trong các bài kiểm tra ban đầu, quyền hạn mà bot cấp đã được sử dụng cùng với các giao dịch bình thường. Khi hệ thống của bot bắt đầu thực thi lặp lại các đường dẫn tương tự, kẻ tấn công điều chỉnh logic hợp đồng, khiến một số quyền hạn do bot tạo ra không còn bị tiêu hao thực tế, cũng không bị đặt lại về 0 sau khi giao dịch kết thúc, dẫn đến các quyền hạn này vẫn còn nguyên;
• Cuối cùng, kẻ tấn công tập trung gọi các hạn mức quyền hạn vẫn còn hiệu lực, chuyển WETH, USDC và USDT thật trong hợp đồng của bot ra ngoài;

Nói thẳng ra, toàn bộ cuộc tấn công nhắm thẳng vào đặc điểm hoạt động của bot MEV, đó là: đầu tiên tạo ra một môi trường phù hợp với các quy tắc đánh giá lợi nhuận của nó, sau đó lợi dụng cơ chế tự động thực thi đường dẫn giao dịch của bot để hệ thống tự động trao quyền gọi tài sản.

Điều này cũng giải thích tại sao ngay cả những bot MEV chuyên nghiệp cao cũng có thể mắc bẫy.

Nó biết cách tính toán chênh lệch giá, chi phí Gas và thứ tự giao dịch, nhưng không nhất thiết phải xác minh đầy đủ danh tính của từng hợp đồng mới xuất hiện. Theo góc nhìn này, vấn đề của người dùng thông thường là "không hiểu gì vẫn nhấn xác nhận", còn vấn đề của bot tự động là "không xác nhận gì vẫn tự động thực thi".

Bề ngoài, hai điều này hoàn toàn khác nhau, nhưng rủi ro tiềm ẩn bên dưới lại rất gần, bởi vì cả hai đều coi Approval là một bước bình thường trước khi hoàn tất giao dịch, mà không nhận thức rõ ràng mức độ nguy hiểm tiềm tàng của nó.

2. Tại sao Approval luôn bị đánh giá thấp?

Như chúng ta đã biết, trong tiêu chuẩn ERC-20 của Ethereum và các chain tương thích EVM, Approve (ủy quyền) là một thiết kế khá cơ bản.

Tuy nhiên, khi người dùng chuyển token trực tiếp trong ví, họ thường gọi hàm transfer, thường không liên quan đến Approve. Chỉ trong các tình huống hợp đồng thông minh như DEX, cho vay, staking hoặc thêm thanh khoản, người dùng mới cần hợp đồng thông minh đại diện cho mình để gọi token, khi đó mới liên quan đến Approval.

Ví dụ, khi chúng ta muốn đổi USDT lấy ETH trên Uniswap, hợp đồng thông minh của Uniswap không thể trực tiếp vào ví của bạn để lấy USDT. Trước tiên, bạn phải thực hiện Approve để nói với hệ thống "Tôi cho phép Uniswap chuyển đi X USDT từ ví của tôi".

Khi quá trình ủy quyền hoàn tất, hợp đồng đã được cấp quyền mới có thể gọi hàm transferFrom của người dùng trong hạn mức đã định, và giao dịch Swap tiếp theo mới có thể hoàn tất thành công.

Nói cách khác, bản thân Approval không phải là một lỗ hổng, mà là nền tảng quan trọng để DeFi hoạt động bình thường. Tuy nhiên, vấn đề nằm ở chỗ nó hơi giống với quyền tự động thanh toán của Alipay/WeChat:

Người dùng không giao mật khẩu tài khoản cho người bán, nhưng lại cho phép người bán tự động thu tiền trong phạm vi thỏa thuận. Miễn là quyền hạn vẫn còn hiệu lực, các lần thanh toán sau sẽ không yêu cầu người dùng nhập lại mật khẩu hoặc xác nhận từng giao dịch, điều này đương nhiên mang đến một số vấn đề.

Đầu tiên là vấn đề ủy quyền vô hạn, mọi người thường biến một giao dịch thành quyền hạn dài hạn. Chủ yếu là để giảm thao tác và chi phí Gas do ủy quyền lặp đi lặp lại. Nhiều DApp sẽ mặc định yêu cầu một hạn mức ủy quyền cực lớn, còn được gọi là "ủy quyền vô hạn".

Người dùng ban đầu chỉ muốn dùng 100 USDC cho một giao dịch, nhưng lại cho phép hợp đồng sử dụng toàn bộ USDC trong địa chỉ của họ trong tương lai. Miễn là quyền hạn đó không bị thu hồi, ngay cả khi ví của người dùng lúc đó chỉ có một lượng nhỏ tài sản, thì USDC được nạp vào sau này cũng có thể tiếp tục bị ảnh hưởng.

Thứ hai, ủy quyền mặc nhiên sẽ không biến mất khi rời khỏi DApp. Nhiều người dùng nhầm lẫn giữa "ngắt kết nối ví" và "thu hồi ủy quyền". Thực tế, ngắt kết nối chỉ khiến trang web tạm thời không thể đọc hoặc yêu cầu ví hiện tại, chứ không thay đổi Approval đã được ghi vào blockchain.

Đóng trang web, xóa DApp, xóa bộ nhớ cache của trình duyệt, thậm chí thay đổi ứng dụng ví, đều không làm cho nó tự động hết hiệu lực.

Cuối cùng, ngay cả một hợp đồng bình thường cũng có thể trở nên nguy hiểm trong tương lai. Bởi vì nhiều rủi ro ủy quyền không chỉ đến từ các trang web lừa đảo độc hại ngay từ đầu, như cuộc săn lùng lần này, người dùng có thể đã cấp quyền cho một giao thức bình thường vào thời điểm đó, nhưng sau đó hợp đồng của giao thức bị tấn công, khóa quản trị bị rò rỉ, logic nâng cấp bị thay thế, hoặc hợp đồng định tuyến mà nó gọi gặp vấn đề.

Đối với người dùng, tài sản vẫn nằm trong địa chỉ của họ, nhưng từ góc độ quyền hạn, một hợp đồng khác luôn có khả năng gọi các tài sản này. Do đó, rủi ro Approval không chỉ là "Tôi có ủy quyền cho kẻ xấu không?" mà còn bao gồm "Đối tượng tôi ủy quyền sau này có gặp vấn đề không?"

3. Làm thế nào để kiểm soát rủi ro Approval?

Đối mặt với rủi ro Approval, lời khuyên đơn giản nhất là "đừng ủy quyền vô hạn".

Nhưng trong môi trường sử dụng DeFi thực tế, hoàn toàn từ chối ủy quyền là không thực tế. Như đã đề cập ở trên, bản thân ủy quyền không phải là lỗ hổng, mà là cách cơ bản để các ứng dụng trên chuỗi gọi tài sản.

Điều thực sự cần thay đổi là biến Approval từ một hành động xác nhận một lần thành một cơ chế quản lý quyền hạn liên tục.

Đối với người dùng thông thường, trước tiên cần xây dựng một vài thói quen cơ bản:

• Thứ nhất, tuân thủ nguyên tắc "đặc quyền tối thiểu". Khi ví hiển thị lời nhắc ủy quyền, hãy cố gắng đặt hạn mức dựa trên nhu cầu thực tế của tương tác lần này. Ví dụ, nếu chỉ định sử dụng 100 USDT, hãy chỉ ủy quyền hạn mức gần 100 USDT, thay vì mở quyền vô hạn;
• Thứ hai, phân biệt ví lưu trữ và ví tương tác. Địa chỉ lưu trữ số lượng lớn tài sản dài hạn không nên thường xuyên kết nối với các DApp lạ; khi tham gia airdrop, Mint, dự án mới và tương tác DeFi rủi ro cao, hãy sử dụng một địa chỉ riêng để giới hạn tổn thất tiềm ẩn trong phạm vi nhỏ;
• Thứ ba, thường xuyên kiểm tra và thu hồi các quyền hạn không còn cần thiết. Người dùng có thể sử dụng các công cụ như Revoke.cash, hoặc trong imToken, vào trang token tương ứng, nhấp vào "Token Function" ở góc dưới bên trái, sau đó chọn "Authorization Management" để xem đối tượng ủy quyền, token và hạn mức của địa chỉ đó, đồng thời thu hồi các quyền hạn không còn sử dụng hoặc không rõ nguồn gốc (Bài viết mở rộng:
  cái ví
  Sự an toàn
  hợp đồng thông minh
  MEV