Tôi mất ba ngày để đọc lại contract của Ostium sau vụ tấn công. Không phải lỗi re-entrancy, không phải overflow, không phải flash loan. Thứ tôi thấy còn tệ hơn: một lỗi trong thiết kế tin tưởng. Họ tin rằng chữ ký hợp lệ đồng nghĩa với dữ liệu đúng. Sai lầm đó đã khiến OLP Vault mất 24 triệu đô la. Và điều đáng sợ nhất? Bất kỳ ai viết smart contract cũng có thể mắc lỗi này nếu không hiểu sâu về oracle security.
Bối cảnh: Ostium và bài toán oracle
Ostium là một nền tảng hợp đồng tương lai vĩnh viễn (perpetual futures) trên chain. Giống như GMX hay dYdX, nó cho phép trader long/short với đòn bẩy, và thanh toán dựa trên giá token từ oracle. Oracle – cầu nối đưa dữ liệu off-chain (giá) lên on-chain – là xương sống của bất kỳ sàn phái sinh nào. Một sai sót trong cơ chế oracle có thể khiến toàn bộ giao thức sụp đổ.
Ostium sử dụng một hệ thống oracle nội bộ: có một danh sách các 'signer' được ủy quyền ký các báo cáo giá, và các 'keeper' (gọi là PriceUpKeep) có nhiệm vụ gửi các báo cáo đã ký lên contract. Hợp đồng OstiumVerifier kiểm tra xem chữ ký có đến từ một signer được phép hay không. Nghe có vẻ an toàn? Sai.
Core: Điều gì thực sự xảy ra?
Tôi phân tích dòng 47 của OstiumVerifier.verify(). Hàm này nhận một struct PriceReport bao gồm timestamp, giá, và chữ ký. Nó xác thực chữ ký bằng ECDSA, kiểm tra signer có trong whitelist, và trả về true. Đó là tất cả.
Hãy nhìn vào thiếu sót: không có kiểm tra tính hợp lệ của timestamp. Một signer có thể ký một báo cáo giá với timestamp ở tương lai, và keeper có thể gửi nó lên contract ngay lập tức. Contract vẫn chấp nhận vì chữ ký hợp lệ. Kẻ tấn công – có thể là keeper hoặc signer bị corrupt – đã làm đúng điều đó: họ lấy một báo cáo giá của tương lai (ví dụ giá ETH giảm 50% vào ngày mai), gửi lên, và mở một vị thế short. Họ biết chắc chắn giá sẽ giảm (vì họ đã thấy báo cáo), nên lệnh của họ là 'không thể thua'. Khi giá thực sự giảm, họ đóng vị thế và rút tiền từ OLP Vault.
Đây không phải hack, mà là một 'design flaw' có chủ đích: chữ ký ủy quyền không đồng nghĩa với dữ liệu đúng đắn. Ostium đã giao phó toàn bộ quyền lực cho các signer, mà không có bất kỳ lớp xác thực nào về mặt thời gian hay độ lệch giá.
Tôi nhớ lại năm 2020 mình build bot yield farming. Tôi cũng từng nghĩ 'nếu signer đã được audit thì cứ tin'. Nhưng rồi tôi mất 30 ETH vì impermanent loss. Bài học: không bao giờ tin tưởng mù quáng vào bất kỳ đầu vào nào, dù nó có chữ ký của CEO. Trong smart contract, bạn phải verify mọi thứ: timestamp phải gần với block time, giá không được chênh lệch quá X% so với giá hiện tại, và lý tưởng nhất là dùng nhiều nguồn oracle độc lập.
Ostium thiếu tất cả những điều đó. OstiumVerifier chỉ kiểm tra 'ai ký', không kiểm tra 'ký cái gì'. Đây là một sai lầm cơ bản của người mới, nhưng được thực hiện bởi một đội ngũ có vẻ kỳ cựu. Điều này cho thấy audit truyền thống (chỉ check code) có thể bỏ sót các lỗ hổng kinh tế - security này.
Contrarian: Chữ ký ủy quyền có thực sự an toàn?
Nhiều người nghĩ 'nếu signer là người đáng tin, và chữ ký đúng, thì dữ liệu là an toàn'. Nhưng trong thực tế, signer có thể bị hack, hoặc chính signer cũng có thể là kẻ tấn công. LayerZero cũng dựa trên giả định tin tưởng vào oracle và relayer – đó là lý do tôi luôn hoài nghi về cross-chain thực sự phi tập trung.
Ở Ostium, kịch bản tệ nhất đã xảy ra: signer (hoặc keeper) đã lạm dụng quyền hạn. Và contract không có cơ chế nào để ngăn chặn. Một giải pháp đơn giản: thêm kiểm tra timestamp phải nhỏ hơn block.timestamp và lớn hơn block.timestamp - 1 hour. Thêm kiểm tra giá mới không được chênh lệch quá 5% so với giá trước đó. Nhưng những dòng code đó không tồn tại.
Takeaway: DeFi cần 'độ sâu có chọn lọc'
Sự cố Ostium không phải là duy nhất. Năm 2021, tôi từng audit một contract NFT marketplace và phát hiện họ mint token mà không kiểm tra supply cap. Họ cũng dùng chữ ký ủy quyền và nghĩ nó đủ an toàn. Kết quả: unlimited mint.
Đối với các builder: đừng lười. Kiểm tra timestamp, kiểm tra độ lệch giá, dùng Chainlink hoặc Pyth làm nguồn phụ, và luôn đặt câu hỏi 'nếu signer bị corrupt thì chuyện gì xảy ra?'. Đối với trader: hãy nghi ngờ bất kỳ giao thức nào dùng oracle nội bộ mà không có cơ chế phòng vệ. Và nhớ: audit không phải bảo hiểm.
Câu chuyện Ostium sẽ còn được nhắc đến nhiều. Nó là bài học đắt giá cho thấy, trong thế giới smart contract, 'xây cầu trên lửa' không chỉ là ẩn dụ. Nó là thực tế.
Smart contract architect: người xây cầu trên lửa. Smart contract architect: người xây cầu trên lửa. Smart contract architect: người xây cầu trên lửa.