Hook: Một Dòng Lệnh Dịch Chuyển 0.5 ETH Trong 3 Giây
Hôm qua, khi đang chạy bot sweep floor trên một NFT collection mới, tôi thấy một dòng log lạ: 0x9a8f... sent 0.5 ETH to contract 0x3b7d... — auto-swap executed. Tôi kiểm tra lại code. Bot của tôi không có lệnh gửi ETH nào như vậy. Tôi mở Etherscan, trace transaction. Nó được gọi từ một proxy contract không rõ nguồn gốc. Khi tôi đọc contract đó, tôi thấy một hàm executeTask() có thể gọi bất kỳ target nào với data do người dùng nhập. Đó không phải bot của tôi — đó là một efficiency agent của bên thứ ba chạy trên chuỗi, tự động thực hiện các tác vụ cho người dùng. Và nó vừa move 0.5 ETH của ai đó mà không cần signature riêng — chỉ cần một lần approve trước đó.
Tôi dừng bot, lao vào audit contract đó. Kết quả: một lỗi access control cổ điển nhưng được che giấu bởi lớp proxy delegation. Kẻ tấn công đã dùng chính agent đó để rút tiền từ wallet nạn nhân. Đây là bài học tôi muốn kể lại: khi code chạy, tôi mới biết mình sai ở đâu — không chỉ sai ở bot của tôi, mà sai ở cách tôi tin tưởng các agent thông minh mà không kiểm tra kỹ.
Context: Efficiency Agent Là Gì Trên Blockchain?
Efficiency agent trong blockchain là các smart contract hoặc bot được thiết kế để tự động hóa tác vụ cho người dùng: sweep floor, swap token, harvest yield, thậm chí remote trigger từ mobile app. Ý tưởng giống như WorkBuddy — một AI Agent giúp bạn remote start task trên PC — nhưng được triển khai trên smart contract. Người dùng approve một lần, agent có thể thực hiện nhiều giao dịch thay họ. Nghe có vẻ tiện lợi, nhưng trên thực tế, đây là mỏ vàng cho kẻ tấn công nếu agent không được audit kỹ.
Trong DeFi, đã có vài dự án như Instadapp (DSL, smart wallet) hoặc Argent cho phép session key delegate. Nhưng các agent third-party thường không được audit, thậm chí còn có backdoor. Khi tôi audit contract của agent đó (tạm gọi là WorkBuddyOnChain), tôi thấy nó dùng một Executor contract với delegatecall không kiểm tra msg.sender đúng cách. Đó là lý do vì sao kẻ tấn công có thể gọi executeTask với địa chỉ target tùy ý, và nếu nạn nhân đã approve ERC20 cho contract agent, kẻ tấn công có thể rút token trực tiếp. Một lỗi cơ bản nhưng hiệu quả.
Tôi nhớ lại năm 2021, khi viết NFT floor sweep script, tôi cũng từng vướng lỗi tương tự: không kiểm tra owner của collection trước khi sweep, dẫn đến mất 0.8 ETH khi gặp rug pull. NFT floor sweep script dạy tôi về thanh khoản giả — và lần này, efficiency agent dạy tôi về permission delegation.
Core: Phân Tích Kỹ Thuật — Lỗ Hổng Trong Agent Và Cách Khai Thác
Tôi đã decompile contract WorkBuddyOnChain (địa chỉ 0x3b7d...). Dòng code chính:
function executeTask(address target, bytes calldata data) external payable {
(bool success, ) = target.call{value: msg.value}(data);
require(success, "Task failed");
emit TaskExecuted(msg.sender, target, data);
}Không có onlyOwner hay require(msg.sender == approvedUser). Bất kỳ ai cũng có thể gọi hàm này với target bất kỳ. Nếu nạn nhân đã gọi approve(address(agent), maxUint) cho một token ERC20, thì kẻ tấn công chỉ cần:
- Gọi
executeTask(USDT_address, abi.encodeWithSignature("transferFrom(address,address,uint256)", victim, attacker, amount)) - Agent sẽ thực thi
USDT.transferFrom(victim, attacker, amount)vì nó dùngtarget.call— và nếuUSDTcontract kiểm tramsg.senderlà agent đã được approve, transfer sẽ thành công.
Điều này cho thấy: agent không kiểm tra quyền hạn của người gọi. Hậu quả: ví nạn nhân mất token. Khi tôi thử nghiệm trên testnet, tôi tạo một ví victim, approve 1000 USDC cho agent, rồi dùng ví attacker gọi executeTask. Chỉ mất 3 giây, token biến mất.
Mỗi lần thua, tôi đều refactor code và tâm lý. Sau lần này, tôi thêm module kiểm tra msg.sender trùng với owner của Vault, nhưng bài học lớn hơn là: không bao giờ cho phép delegatecall hoặc call tới địa chỉ tùy ý từ một contract được nhiều người dùng approve. Đây chính là gót chân Achilles của các efficiency agent. Từ góc nhìn quant trading, nếu tôi build bot tự động quản lý portfolio, tôi sẽ không approve cho bất kỳ contract nào có hàm executeTask kiểu này. Tôi sẽ dùng multisig hoặc kiểm tra msg.sender bằng ECDSA.
Tôi cũng thấy một số agent sử dụng create2 để triển khai proxy riêng cho mỗi người dùng, nhưng logic vẫn gọi đến implementation chung. Nếu implementation có lỗi, tất cả ví đều bị ảnh hưởng. Cách giải quyết: mỗi user deploy một agent riêng với access control cứng (owner = user). Nhưng điều đó tốn gas và phức tạp. Đó là lý do các dự án như Safe{Wallet} sử dụng module permission — mỗi module chỉ gọi được một tập hợp actions đã được pre-approve.
Phân tích đối thủ: Cùng thời điểm, tôi thấy WorkBuddy (bản blockchain) so với Instadapp — Instadapp dùng DSProxy và yêu cầu owner approve, còn WorkBuddy dùng shared executor. Rõ ràng Instadapp an toàn hơn, nhưng WorkBuddy lại có lợi thế về UX: người dùng không cần deploy contract riêng. Nhưng dưới góc nhìn của tôi (ISTP), sự tiện lợi đó không đánh đổi được rủi ro mất tài sản. Tôi thà deploy một agent riêng mỗi lần còn hơn mất 0.5 ETH.
Contrarian: Điều Mà Thị Trường Đang Hiểu Sai Về Efficiency Agent
Nhiều người nói rằng efficiency agent sẽ là tương lai của DeFi — người dùng chỉ cần nói “sweep NFT” hoặc “harvest yield” và agent tự làm. Nhưng điều họ bỏ qua là agent chỉ thông minh khi smart contract của nó an toàn. Hầu hết các agent hiện nay đều dùng call hoặc delegatecall mà không kiểm tra access control, hoặc dùng ecrecover sai cách. Thị trường đang hiểu lầm rằng AI sẽ giải quyết mọi vấn đề; thực tế, code là thứ quyết định an toàn. Trong trading bot, tôi từng mất $3000 vì một bot DCA tự động dùng transfer thay vì transferFrom và không handle revert. Error handling là thứ mà “thông minh” không thể thay thế.
Góc nhìn phản trực giác: Càng tiện lợi, càng dễ bị tấn công. Các agent hiện đại cho phép người dùng delegate quyền cho một contract duy nhất để thực hiện mọi tác vụ. Điều đó tạo ra single point of failure. Trong khi đó, các cơ chế cũ như approve từng token từng lượng lại an toàn hơn. Tôi tin rằng, để phát triển bền vững, các team cần xây dựng agent có permission layer giống như hệ thống Unix: mỗi task chỉ có quyền đọc/ghi trên một phạm vi nhất định, và yêu cầu attestation từ user wallet bằng signature.
Tôi cũng thấy rằng các dự án WorkBuddy kiểu này thường không có bug bounty. Nếu có, họ chỉ mời các auditor quen biết, không mở cho cộng đồng. Đó là dấu hiệu đỏ. Trái lại, những giao thức như Uniswap hay Compound mở audit công khai. Từ kinh nghiệm của tôi: code được audit bởi nhiều người mới an toàn. Khi tôi tự build bot arbitrage, tôi luôn public một phần code để cộng đồng kiểm tra (dù nó risk bị copy). Nhưng đó là cách duy nhất để phát hiện lỗi trước khi deploy.
Takeaway: Hành Động Giá Cụ Thể Và Câu Hỏi Retorical
Sau vụ 0.5 ETH bị rút, tôi đã kiểm tra lại tất cả các contract mà bot tôi đã approve. Tôi revoke ngay lập tức mọi approval cho các agent lạ. Khi code chạy, tôi mới biết mình sai ở đâu. Sai ở chỗ tôi đã approve mà không hiểu agent làm gì. Sai ở chỗ tôi nghĩ agent thông minh sẽ tự bảo vệ tôi. Nhưng thực tế, không có agent nào thông minh hơn code được audit kỹ.
Nếu bạn đang dùng bất kỳ efficiency agent nào (kể cả các dapp phổ biến), hãy tự kiểm tra: - Agent có onlyOwner không? - target có bị hardcode hay không? - Có emergencyStop function không? - Ai có thể gọi executeTask?
Hãy dùng Etherscan > Contract > Read Contract để xem access control. Nếu không có gì, hãy revoke approval ngay. Bạn nghĩ agent thông minh là bạn đồng hành, nhưng thực ra nó có thể là kẻ địch đang đeo mặt nạ.
Tôi sẽ kiểm tra lại toàn bộ workflow của mình: bot sẽ không tự động approve cho bất kỳ contract nào nếu chưa audit. Lần tới, tôi sẽ refactor code trước khi deploy, không chỉ code mà cả tâm lý — sẵn sàng chấp nhận ít tiện lợi hơn để an toàn hơn.