Một giao thức cầu nối cross-chain mất 12.000 ETH trong 48 giờ. Không phải lỗi oracle, không phải rug pull. Là lỗi trong logic xác thực tin nhắn – mà tôi đã thấy ít nhất hai lần rồi. Lần này, đám mây khói vẫn phủ kín Twitter, nhưng dữ liệu on-chain nói thẳng: có một tay chơi đã rút tiền một cách có hệ thống.
Context Trong chu kỳ thị trường giảm, những vụ tấn công vào cầu nối cross-chain không còn là tin sốc. Nhưng vụ này khác: nó nhắm vào một giao thức từng được bảo chứng bởi các quỹ đầu tư hàng đầu, có TVL hơn 2 tỷ USD trước khi sập. Họ tự hào về kiến trúc “cầu nối phi tập trung thế hệ mới”. Thực tế: smart contract của họ cho phép admin ký lại message mà không cần kiểm tra nonce. Một lỗi cơ bản – nhưng được ngụy trang dưới lớp mã nguồn rối rắm. Tôi dành ba ngày để trace từng giao dịch, và phát hiện một pattern: tất cả đều từ một địa chỉ deploy được tạo từ tháng 8 năm ngoái.
Core: Tháo gỡ có hệ thống Bước một: kiểm tra smart contract bridge. Tôi thấy hàm processMessage không có cơ chế kiểm tra tính duy nhất của message ID. Kẻ tấn công có thể gửi cùng một tin nhắn nhiều lần. Bước hai: trace dòng tiền. Tôi dùng Etherscan và Dune để lọc tất cả giao dịch từ địa chỉ tấn công. Kết quả: họ rút 4.000 ETH từ pool thanh khoản, sau đó chuyển qua Tornado Cash và các cầu nối khác. Nhưng điểm mấu chốt là họ đã để lại một dấu vết: một địa chỉ ví nhận 2.000 ETH và không hề di chuyển. Đây có thể là một lỗi sơ suất, hoặc có chủ đích. Bước ba: kiểm tra lịch sử admin. Tôi tìm thấy một bài blog cũ của đội ngũ, nơi họ thừa nhận đã “tạm thời tắt” tính năng kiểm tra nonce để tiết kiệm gas. Một quyết định kỹ thuật tưởng chừng vô hại, nhưng đã mở ra cánh cửa tử.
Contrarian: Phần phe bò đúng Có một lập luận: “Lỗi đã được fix, giao thức vẫn sống.” Đúng, họ đã vá lỗi trong vòng 6 giờ. Họ cũng đền bù 80% thiệt hại từ quỹ bảo hiểm. Nhưng câu hỏi là: tại sao một giao thức với 2 tỷ TVL lại không có audit đầy đủ từ ba công ty khác nhau? Audit chỉ phát hiện lỗi nếu audit được thiết kế để kiểm tra logic tổng thể, chứ không chỉ từng hàm riêng lẻ. Trong trường hợp này, smart contract đã được audit bởi một công ty danh tiếng, nhưng họ bỏ sót lỗi nonce vì họ không mô phỏng kịch bản replay attack. Điều này cho thấy ngay cả audit chuyên nghiệp cũng có blind spot. Và phe bò đúng ở chỗ: họ nhanh chóng huy động quỹ bảo hiểm, nhưng điều đó chỉ che giấu vấn đề cốt lõi – mô hình bảo mật của họ dựa trên niềm tin vào admin, không phải code.
Takeaway Cây cầu sập, ai gánh? Lập trình viên? Admin? Người dùng? Tôi nghĩ cả ba. Nhưng người dùng là người cuối cùng mất tiền. Và họ sẽ không bao giờ lấy lại được niềm tin. Câu hỏi đặt ra: nếu một giao thức được audit, được đầu tư, vẫn có lỗi cơ bản, thì niềm tin vào on-chain còn lại gì? Câu trả lời: chỉ có dữ liệu và việc tự kiểm tra.
Chi tiết kỹ thuật từ tôi Dựa trên kinh nghiệm audit của tôi với các bridge cross-chain, hầu hết các lỗi đều đến từ việc tối ưu hóa gas sớm. Các đội ngũ thường chọn rẻ hơn thay vì an toàn hơn. Và điều này lặp lại trong ít nhất 5 dự án tôi từng phân tích. Một lần, tôi thậm chí phát hiện một bridge có hàm verify chỉ kiểm tra chữ ký của một validator duy nhất. Khi tôi hỏi, họ nói “đó là trade-off”. Trade-off giữa chi phí và an ninh – và họ chọn chi phí.
Kết Khi thị trường giảm, mọi người đổ xô vào yield farming, vào bridge để kiếm lợi nhuận. Nhưng chính những lúc đó, lỗ hổng mới lộ ra. Tôi không nói hãy bỏ tất cả. Tôi nói: hãy kiểm tra mã nguồn trước khi ký gửi. Và nếu bạn thấy một dự án hứa hẹn lợi nhuận cao bất thường, hãy hỏi: “Liquidity pool ấy? Tôi thấy cửa sau.”
