Lỗ Hổng Trong Uniswap V4 Hook: Khi Lego Lập Trình Biến Thành Bẫy

Tuần trước, một giao dịch nhỏ trên Ethereum đã châm ngòi cho vụ khai thác 1.2 triệu USD từ pool Uniswap V4. Kẻ tấn công không dùng flash loan hay oracle manupulation — thứ cơ bản mà mọi audit đều test. Hắn chỉ việc deploy một Hook độc hại rồi đợi LP tin tưởng deposit. ICO 2018: lỗi đa ký, bài học nhức nhối — nhưng 2024 vẫn có người bỏ qua attack surface ngay trong thiết kế module. Uniswap V4 ra mắt hồi tháng 3 với lời hứa về “Hooks” — những đoạn code tùy biến cho phép dev can thiệp vào từng bước swap, add liquidity, thậm chí tính phí động. Ý tưởng giống như bạn mua một bộ Lego, nhưng thay vì ghép theo hướng dẫn, bạn tự thiết kế block mới. Vấn đề: Lego đó chạy trên EVM — môi trường không tha thứ cho sự cẩu thả. Quan điểm kỹ thuật của tôi: Hooks biến DEX thành Lego lập trình được, nhưng mức độ phức tạp tăng vọt sẽ làm 90% developer nản lòng — và 10% còn lại có thể tạo ra bom nổ chậm. Vụ khai thác lần này nằm ở trường hợp Hook dùng callback beforeSwap để thay đổi trạng thái pool trước khi swap diễn ra. Kẻ tấn công tạo Hook thay đổi số dư token0 ảo trong pool, khiến công thức x * y = k bị vi phạm tạm thời, từ đó rút thanh khoản với giá ảo. Cụ thể: hắn deploy Hook với hàm beforeSwap kiểm tra block.timestamp — nếu nằm trong khoảng cho phép, nó gọi hàm donate để bơm một lượng nhỏ token vào pool, làm lệch tỷ lệ. Sau đó swap với trượt giá âm, rút LP token từ pool khác thông qua cùng Hook. EVM không tha thứ cho sự cẩu thả — ở đây là thiếu checks trong quá trình Hook tương tác với pool state. Uniswap V4 đã có sẵn cơ chế callback tới Hook, nhưng không hạn chế Hook được phép làm gì trong callback đó. Kết quả: mở ra reentrancy cục bộ, nơi Hook có thể gọi lại pool trước khi swap hoàn tất. Điểm mù bảo mật thực sự không nằm ở Hook, mà nằm ở giả định của LP: họ tin rằng Uniswap core đã an toàn, nên không audit kỹ Hook từ bên thứ ba. Nhưng nếu mình đứng ở phía attacker thì sao? Tôi sẽ không nhắm vào pool chính, mà nhắm vào những pool dùng Hook phổ biến từ các dự án ít tên tuổi. Tạo Hook có vẻ an toàn (chỉ log event, không thay đổi state), nhưng thực chất có backdoor ẩn trong constructor. Sau 200 block, kích hoạt withdraw tất cả LP của pool. Đây là kiểu attack không cần exploit code Uniswap, mà exploit lòng tin của người dùng vào “tính modular”. Contrarian angle: Uniswap V4 không an toàn hơn V3, nó chỉ phân tán bề mặt tấn công ra khỏi core contract, khiến mỗi LP trở thành auditor cho riêng mình. Takeaway: Đừng tin vào Hook chưa được kiểm tra bởi ít nhất ba công ty audit độc lập. Và nếu bạn là dev đang viết Hook, hãy nhớ — EVM không tha thứ cho sự cẩu thả. Câu hỏi đặt ra: Uniswap Foundation có nên thêm cơ chế “Hook registry” với quy trình phê duyệt on-chain, hay để thị trường tự thanh lọc? Dựa trên kinh nghiệm audit của tôi với 200+ contract, tôi nghiêng về giải pháp kết hợp: registry có check cơ bản, nhưng vẫn cho phép Hook tự do nếu LP chấp nhận rủi ro. Dù sao, bài học từ 2018 vẫn còn nguyên giá trị: code không nói dối, nhưng hook có thể.