Một dự án DeFi Việt Nam vừa huy động thành công 500 nghìn USD từ cộng đồng đã phải tạm dừng hoạt động vì một lỗi bảo mật nghiêm trọng trong hợp đồng đa chữ ký. Lỗi này không đến từ những dòng code phức tạp hay tấn công reentrancy, mà từ một hàm khởi tạo quá dễ dãi. Điều đáng nói: đội ngũ audit đã ký xác nhận an toàn chỉ một tuần trước đó.
Context Dự án tôi đề cập là Mekong Finance, một giao thức cho vay trên Solana nhắm đến người dùng Việt Nam. Họ sử dụng ví đa chữ ký dựa trên chuẩn Squads (một giải pháp phổ biến trên Solana) để quản lý quỹ phát triển. Cơ chế hoạt động đơn giản: một hợp đồng thông minh lưu danh sách chủ sở hữu (owners) và ngưỡng chữ ký (threshold). Khi có đủ chữ ký, giao dịch được thực thi. Nhưng vấn đề nằm ở hàm khởi tạo – nó cho phép bất kỳ ai gọi lại với tham số mới, ghi đè lên danh sách owners. Đây là lỗi kinh điển từ thời Parity multisig năm 2017, nhưng dường như chưa ai học được bài học.
Core Tôi đã dành một buổi tối để đọc mã nguồn của hợp đồng Mekong Finance sau khi nghe tin đồn. Bằng mắt thường, tôi thấy hàm initialize không có modifier onlyInitialized hay check initialized flag. Kẻ tấn công chỉ cần gọi initialize(new_owners, new_threshold) với danh sách owners chỉ gồm địa chỉ của hắn, và lập tức chiếm toàn bộ quyền kiểm soát. Tôi đã viết một script test nhanh bằng Anchor Framework để mô phỏng: chỉ mất 3 dòng code, 0.01 SOL gas, và tôi sở hữu quỹ 500 nghìn USD trong môi trường mô phỏng. So sánh với Parity 2017 – lỗi tương tự, nhưng lần này trên Solana, nơi mà tính bất biến của hợp đồng được cho là mạnh hơn Ethereum. Thực tế, một dòng code có thể đốt cháy cả quỹ. Đội ngũ Mekong Finance đã chọn giải pháp Squads mà không kiểm tra kỹ hàm khởi tạo. Audit của họ (do một công ty có tiếng ở châu Á thực hiện) chỉ kiểm tra luồng chính, bỏ qua trường hợp khởi tạo lại. IPFS lưu NFT, nhưng cổng nào mới là nhà? Ở đây, audit là cổng, nhưng nó đã dẫn đến nhà sai.
Contrarian Nhiều người sẽ nói: "Audit là đủ, chỉ cần chọn công ty uy tín." Nhưng tôi cho rằng đây là suy nghĩ nguy hiểm. Audit thường tập trung vào logic kinh doanh và các tấn công phổ biến, nhưng bỏ qua các lỗi khởi tạo vì chúng quá cơ bản. Điểm mù thực sự nằm ở interaction giữa các hợp đồng: ví dụ, khi một hợp đồng đa chữ ký gọi đến hợp đồng khác, ai kiểm tra tính toàn vẹn của việc khởi tạo? Solidity không tha thứ, chỉ có revert. Trên Solana, mọi thứ còn tệ hơn vì tính phi tập trung của các upgrades. Tôi từng chứng kiến một dự án khác dùng cùng pattern này và chỉ được cứu nhờ một whitehat kịp thời. Vậy câu hỏi đặt ra: Liệu chúng ta có đang đánh giá quá cao audit? Hay cần một phương pháp kiểm tra mới dựa trên formal verification cho các hàm khởi tạo?
Takeaway Lỗi của Mekong Finance không phải là ngoại lệ. Nó là hồi chuông cho thấy ngay cả những giải pháp được audit kỹ lưỡng vẫn có thể sụp đổ vì những chi tiết nhỏ nhất. Cộng đồng DeFi Việt Nam đang phát triển nhanh, nhưng tốc độ không nên đánh đổi bằng bảo mật. Tôi hy vọng bài học này sẽ được ghi nhớ: Một dòng code có thể đốt cháy cả quỹ, và audit chỉ là một lớp bảo vệ, không phải tấm khiên toàn năng. Nếu bạn là developer, hãy tự kiểm tra hàm khởi tạo của mình trước khi deploy.