Người ta thấy token, tôi thấy đường dẫn gọi hàm. Trong 7 ngày qua, một giao thức DeFi mới nổi với câu chuyện “giải quyết vấn đề thanh khoản chéo” đã mất 40% LP. Họ kêu gọi cộng đồng, họ đổ lỗi cho “thị trường giảm”. Nhưng khi tôi mở source code của họ trên Etherscan, tôi không thấy một vấn đề thị trường nào cả. Tôi thấy một lỗi reentrancy cổ điển trong hàm withdraw(), giống hệt như lỗi tôi đã phát hiện trong hợp đồng ICO của Aragon năm 2017. Và đó mới là câu chuyện thực sự.
Context: Câu Chuyện và Sự Thật
Dự án này, tạm gọi là “Project X”, tự quảng bá là một “Layer-2 thanh khoản đa chuỗi thế hệ mới”. Họ có một website đẹp, một đội ngũ cố vấn với những cái tên quen thuộc, và một câu chuyện về “tương lai của DeFi”. Nhưng hãy nhìn vào mã nguồn. Họ sử dụng một biến thể của mô hình AMM, nhưng với một cơ chế “hook” tùy chỉnh để cho phép người dùng kiếm thêm phí. Uniswap V4 đã làm cho hook trở nên phổ biến, nhưng như tôi đã từng nói: Hooks của Uniswap V4 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à Project X, than ôi, nằm trong 90% đó.
Hàm withdraw() của họ trông có vẻ an toàn. Nó kiểm tra số dư, nó cập nhật trạng thái. Nhưng nó quên mất một điều cơ bản: checks-effects-interactions. Họ thực hiện cuộc gọi bên ngoài (gửi ETH) trước khi cập nhật số dư nội bộ. Đây là lỗi mà tôi đã thấy hàng trăm lần, từ những ngày đầu của Solidity cho đến bây giờ.
Core: Phân Tích Cấp Code – Tại Sao Lỗi Reentrancy Lại Vẫn Còn?
Tôi sẽ không lý thuyết suông. Dựa trên kinh nghiệm audit của tôi, đây là cách lỗi này hoạt động:
- Hook: Một hợp đồng tấn công được triển khai.
- Cuộc gọi đầu tiên: Hợp đồng tấn công gọi
withdraw()của Project X. - Trong
withdraw(): Hợp đồng Project X kiểm tra số dư của kẻ tấn công (đủ), gửi token cho hợp đồng tấn công, và sau đó mới cập nhật số dư của kẻ tấn công về 0. - Reentrancy: Trong quá trình gửi token, hàm
fallback()của hợp đồng tấn công được gọi. Hàmfallback()này, thay vì chỉ im lặng, lại gọi lạiwithdraw()của Project X. - Lặp lại: Vì số dư của kẻ tấn công chưa được cập nhật, Project X lại kiểm tra và thấy nó vẫn còn token. Nó lại gửi token một lần nữa.
- Kết quả: Kẻ tấn công rút được số token gấp nhiều lần số dư thực tế của mình.
Tôi đã thử nghiệm điều này trên môi trường testnet local. Tôi viết một hợp đồng tấn công đơn giản, chỉ với 50 dòng code. Kết quả benchmark: một cuộc tấn công reentrancy thành công có thể rút toàn bộ pool thanh khoản chỉ trong một block. Đây không phải là một lỗ hổng phức tạp. Đây là lỗi mà bất kỳ lập trình viên Solidity nào cũng nên biết cách tránh.
Điều thú vị là, Project X đã sử dụng OpenZeppelin, một thư viện an toàn nổi tiếng. Nhưng họ đã tự viết lại hàm withdraw() để thêm “tính năng hook” của riêng mình, và trong quá trình đó, họ đã vô tình loại bỏ cơ chế bảo vệ reentrancy. Họ đã “tối ưu hóa” một thứ đã an toàn, và biến nó thành một quả bom hẹn giờ.
Contrarian: Điểm Mù Bảo Mật – Câu Chuyện Che Giấu Mã Nguồn
Phần lớn cộng đồng và các nhà phân tích tập trung vào “câu chuyện” của dự án. Họ hỏi: “Dự án này có giải quyết được vấn đề thanh khoản không?”, “Đội ngũ có uy tín không?”, “Tokenomics có hợp lý không?”. Nhưng họ quên mất câu hỏi quan trọng nhất: “Mã nguồn có an toàn không?”
Góc nhìn phản trực giác ở đây là: Một dự án với công nghệ “đột phá” và đội ngũ “huyền thoại” thường có nhiều lỗ hổng bảo mật hơn một dự án tầm thường. Tại sao? Bởi vì sự phức tạp là kẻ thù của bảo mật. Những dự án “đột phá” thường cố gắng làm quá nhiều thứ mới, tạo ra những tương tác phức tạp giữa các hợp đồng, và do đó, tạo ra nhiều vector tấn công hơn.
Trong trường hợp của Project X, họ đã cố gắng tạo ra một “hook” để thưởng cho người dùng. Nhưng chính cái “hook” đó đã phá vỡ tính toàn vẹn của hàm withdraw(). Họ đã không nhìn thấy sự tương tác giữa hook và cơ chế rút tiền. Họ đã không thử nghiệm tất cả các kịch bản biên.
Đây là điểm mù mà tôi, với tư cách là một người audit, luôn cảnh giác. Tôi không bao giờ tin vào câu chuyện. Tôi chỉ tin vào mã nguồn và các đường dẫn gọi hàm. “Người ta thấy token, tôi thấy đường dẫn gọi hàm.”
Takeaway: Dự Báo Lỗ Hổng – Bài Học Cho Thị Trường Gấu
Trong thị trường gấu này, sự sống còn quan trọng hơn lợi nhuận. Câu hỏi không phải là “Làm thế nào để tôi kiếm được nhiều tiền nhất?”, mà là “Làm thế nào để tài sản của tôi an toàn?”.
Dựa trên phân tích này, tôi có một dự báo: Trong 6 tháng tới, chúng ta sẽ chứng kiến một làn sóng các dự án DeFi bị hack, không phải vì kẻ tấn công tinh vi, mà vì những lỗi lập trình cơ bản. Các đội ngũ phát triển, đang chịu áp lực từ thị trường giảm, sẽ cắt giảm chi phí audit và thời gian kiểm thử. Họ sẽ vội vàng phát hành những tính năng mới để thu hút người dùng, mà không hiểu rõ những rủi ro bảo mật.
Và tôi sẽ ở đây, mổ xẻ từng dòng code, để chỉ ra cho bạn thấy rằng, đằng sau mỗi câu chuyện đẹp đẽ, thường là một hàm withdraw() không được bảo vệ.
Hãy nhớ: Khi ai đó nói với bạn về một “cơ hội đầu tư không thể bỏ lỡ”, hãy hỏi họ: “Cho tôi xem mã nguồn của bạn.” Nếu họ không thể đưa ra một câu trả lời rõ ràng, hoặc nếu mã nguồn của họ có vẻ quá phức tạp mà không có lý do chính đáng, hãy tránh xa. Trong thế giới blockchain, lòng tin không được xây dựng bằng lời nói. Nó được xây dựng bằng những dòng code đã được kiểm chứng.