Ngày 15/7, một kẻ tấn công đã rút sạch gần 500.000 USD từ pool thanh khoản của BlueMove – một sàn DEX trên hệ sinh thái SUI. Chưa đầy 24 giờ sau, cáo buộc nội gián (insider job) bắt đầu lan tràn trên mạng xã hội, đặc biệt từ nhân vật có tiếng là Tyler Simpson. Nhưng sau khi mổ xẻ hợp đồng thông minh và lịch sử nâng cấp, tôi – một DeFi Security Auditor với 5 năm kinh nghiệm – nhận ra câu chuyện phức tạp hơn nhiều so với một vụ hack đơn thuần.
Hãy bắt đầu từ mã nguồn. BlueMove là một AMM (Automated Market Maker) được xây dựng bằng ngôn ngữ Move trên SUI. Cũng giống như Uniswap, nó cho phép người dùng trao đổi token thông qua các pool thanh khoản. Nhưng khác với Ethereum, hợp đồng trên SUI có cơ chế UpgradeCap – một đối tượng đặc quyền cho phép nâng cấp mã sau khi triển khai. Ngày 31/5, BlueMove đã thực hiện một bản nâng cấp, thêm các hàm như add_liquidity_returns và thay đổi logic tính toán phí. Vấn đề là bản nâng cấp này không sửa một lỗi tràn số (arithmetic overflow) đã tồn tại ít nhất từ năm 2023. Theo tuyên bố của đội ngũ, lỗi này “đã được biết đến từ lâu”, nhưng họ chọn cách không fix.
Lỗi tràn số trong AMM thường xuất hiện ở các phép tính nhân/chia liên quan đến số dư pool. Ví dụ, nếu một hàm tính amount_in * reserve_out / reserve_in và amount_in quá lớn, kết quả có thể vượt quá giới hạn số nguyên (u64), dẫn đến kết quả sai lệch. Kẻ tấn công có thể lợi dụng điều này để rút nhiều token hơn từ pool. Trong trường hợp của BlueMove, hacker đã gọi một hàm từ phiên bản cũ của hợp đồng – phiên bản trước khi nâng cấp – nhưng vẫn có thể tương tác với pool thanh khoản mới. Đây là điểm mấu chốt: dù đã nâng cấp, BlueMove không vô hiệu hóa các hàm cũ, tạo ra bề mặt tấn công kép.
Ngày 3/6, chỉ vài ngày sau bản nâng cấp, BlueMove đã đốt UpgradeCap. Hành động này khiến hợp đồng trở nên bất biến – không thể sửa lỗi, không thể rollback. Đây là một quyết định quen thuộc trong cộng đồng DeFi: loại bỏ quyền nâng cấp để tăng tính phi tập trung, giảm rủi ro admin key. Nhưng khi một lỗi đã biết vẫn chưa được vá, việc đốt UpgradeCap là một sai lầm chiến lược. Nó giống như khóa chặt cánh cửa sau khi người trong nhà đã chết – không thể cứu chữa.
Vậy kẻ tấn công đã làm gì? Anh ta chờ đợi. Từ ngày 3/6 đến 15/7, pool thanh khoản vận hành bình thường. Hacker có thể đã thử nghiệm giao dịch nhỏ, xác nhận lỗi còn tồn tại. Khi thời điểm chín muồi, anh ta thực hiện một loạt giao dịch với số lượng token cực lớn, kích hoạt lỗi tràn số, và rút sạch ~500.000 USD khỏi pool. Điều đáng nói: hacker không cần dùng đến các kỹ thuật phức tạp như flash loan – chỉ đơn giản là gửi lệnh swap với tham số bất thường. Vụ việc chỉ mất chưa đầy 1 block.
Tyler Simpson cáo buộc rằng đây là một “rug pull chậm” (delayed rug pull) do chính đội BlueMove sắp đặt. Lý do: họ biết lỗi từ lâu, không sửa, lại đốt UpgradeCap, tạo điều kiện cho kẻ nội bộ (hoặc chính họ) rút tiền. Nhưng tôi cho rằng điều này khó xảy ra. Nếu là rug pull, sao họ không rút toàn bộ số tiền lớn hơn? Và tại sao họ lại công bố kế hoạch bồi thường? Còn một chi tiết khác: hacker sau đó đã gửi tin nhắn đòi tiền chuộc 15% (khoảng 15 ETH) để trả lại số tiền còn lại. BlueMove từ chối và tuyên bố sẽ theo đuổi các biện pháp pháp lý. Hành vi này giống với một white-hat hacker nổi loạn hơn là kẻ nội gián.
Tôi từng tham gia audit nhiều dự án DeFi trên SUI và Aptos. Lỗi tràn số là một trong những lỗi phổ biến nhất, nhưng thường được phát hiện trong giai đoạn testnet. Việc một lỗi tồn tại hơn một năm mà không được sửa cho thấy quy trình quản lý mã nguồn của BlueMove rất yếu. Có thể họ thiếu nhân lực, hoặc ưu tiên sai. Nhưng dù lý do gì, trách nhiệm thuộc về đội ngũ.
Về mặt thị trường, vụ việc đã gây ra làn sóng FUD trong hệ sinh thái SUI. Các DEX khác như Cetus, Turbos hứng chịu áp lực rút thanh khoản tạm thời, nhưng nhanh chóng phục hồi. BlueMove thông báo đóng cửa hoàn toàn, cam kết bồi thường cho người dùng bị ảnh hưởng. SUI Foundation từ chối bình luận, nhưng cho thấy họ không muốn can thiệp vào các dự án độc lập.
Điều trớ trêu là BlueMove đã cố gắng làm điều đúng đắn khi loại bỏ UpgradeCap để chống lại rủi ro tập trung. Nhưng họ quên rằng: phi tập trung không đồng nghĩa với an toàn. Một hợp đồng bất biến với lỗi bên trong còn nguy hiểm hơn một hợp đồng có admin key còn hoạt động. Bài học rút ra: không bao giờ đốt UpgradeCap trước khi chắc chắn mã không còn lỗi. Và nếu phải đốt, hãy giữ lại một cơ chế khẩn cấp, ví dụ như một multisig có quyền tạm dừng.
Kết luận: Đây là một vụ hack do quản lý yếu kém, không phải nội gián. Kẻ tấn công có thể chỉ là một hacker chuyên nghiệp tận dụng cơ hội. BlueMove đã mất $500K và sự sống của dự án. Nhưng câu hỏi thực sự đặt ra cho toàn bộ ngành DeFi: bạn có dám chắc rằng hợp đồng của mình không có lỗi tràn số đang ngủ quên từ năm 2023 không?