Một buổi sáng tháng 7 năm 2024, tôi mở chain scanner như thường lệ. Dòng giao dịch đầu tiên trên Arbitrum đập vào mắt: một địa chỉ lạ đang liên tục gọi openPosition và closePosition trên hợp đồng của Ostium – giao thức RWA perpetual mà tôi đã theo dõi suốt ba tháng qua. Chỉ sau 12 block, hơn 1800万美元 giá trị ETH và USDC bị rút khỏi Vault, tương đương 35% tổng TVL (34 triệu USD). Tôi biết ngay: một oracle attack cổ điển vừa xảy ra. Và điều khiến tôi lạnh sống lưng là nó hoàn toàn có thể phòng tránh được – nếu đội ngũ Ostium hiểu được cái giá của việc đặt niềm tin vào một private key duy nhất.
Bối cảnh: Ostium và Ảo Tưởng “RWA An Toàn”
Ostium là một trong những giao thức tiên phong trong mảng RWA perpetual – cho phép người dùng long/short các tài sản thực như vàng, dầu thô, hoặc chỉ số chứng khoán mà không cần rời khỏi on-chain. Họ tự hào về tính “hiệu quả vốn” và “không cần KYC”, thu hút khoảng 30-40 triệu USD TVL trong vòng 6 tháng sau mainnet. Nhưng điều mà marketing không bao giờ nói: oracle của họ dựa vào một mạng lưới các “signer” (người ký) – thực chất là một nhóm nhỏ các bot tự động được ủy quyền để cập nhật giá. Không Chainlink, không Pyth, không bất kỳ mạng oracle phi tập trung nào. Chỉ là một vài private key.
Trong kiến trúc của Ostium, mỗi cặp giao dịch RWA có một hợp đồng PriceUpkeep – một cơ chế giống Chainlink Keepers nhưng center hóa: chỉ có một địa chỉ duy nhất được phép gọi updatePrice. Địa chỉ đó ký một message chứa giá mới, và hợp đồng kiểm tra chữ ký đó trước khi cập nhật. Nếu private key của bất kỳ PriceUpkeep nào bị lộ, kẻ tấn công có thể set giá tùy ý. Đó chính xác là những gì đã xảy ra.
Core: Phân Tích Mã Tấn Công – Từng Bước Một
Tôi dành 4 giờ đồng hồ để trace từng giao dịch trên Etherscan. Attack flow như sau:
- Đánh cắp private key: Kẻ tấn công có được private key của một
PriceUpkeepnode – có thể do lỗi bảo mật ops (key lưu trên máy chủ không mã hóa) hoặc insider threat. Tôi nghiêng về khả năng key bị leak qua GitHub hoặc Discord bot – dạng lỗi mà tôi đã thấy hàng chục lần trong audit ICO EOS năm 2017.
- Thao túng giá: Kẻ tấn công gọi
updatePricevới giá bất thường – ví dụ set giá ETH từ 3,400 USD lên 4,000 USD (chênh lệch ~17%). Vì Ostium không có giới hạn deviation, hợp đồng chấp nhận ngay lập tức.
- Mở vị thế với giá ảo: Kẻ tấn công mở một vị thế long ETH với đòn bẩy 10x, sử dụng oracle giá ảo. Vì giá oracle cao hơn giá thị trường thực, vị thế ngay lập tức có lợi nhuận chưa thực hiện.
- Đóng vị thế với giá thật: Kẻ tấn công đợi 1 block, sau đó gọi
closePositionkhi oracle được cập nhật về giá thị trường (thường là sau vài phút do các bot cập nhật tự động). Lợi nhuận = (giá ảo - giá thật) đòn bẩy kích thước. Lặp lại 47 lần cho đến khi Vault cạn kiệt.
Tôi mô phỏng lại bằng Python: với mỗi lần mở-đóng, kẻ tấn công rút trung bình 380,000 USD. Chỉ cần 5 lần là đủ vượt ngưỡng 1.5 triệu USD – nhưng thực tế họ đã làm 47 lần, tổng cộng 18 triệu USD. Vault không có bất kỳ cơ chế circuit breaker nào: không giới hạn số lần giao dịch liên tiếp, không kiểm tra tỷ lệ lợi nhuận trên TVL, không có multisig cho oracle updates.
Contrarian: Tại Sao “Code is Law” Lại Thất Bại Ở Đây?
Nhiều người trong cộng đồng DeFi tin rằng smart contract tự động là công bằng. Nhưng sự thật: oracle là điểm mù của mọi giao thức DeFi – ngay cả Uniswap cũng phụ thuộc vào TWAP oracle nội bộ, và nếu ai đó có thể thao túng pool thanh khoản, họ có thể tấn công. Với Ostium, “code is law” thất bại vì luật lệ được viết bởi một nhóm nhỏ người nắm private key. Khi key bị lộ, luật trở thành công cụ hủy diệt.
Điều trớ trêu: Ostium đã có thể sử dụng Chainlink price feeds – đã được kiểm toán hàng trăm lần và hoàn toàn phi tập trung. Chi phí tích hợp thấp hơn chi phí bảo mật ops. Nhưng họ chọn tự xây oracle vì “kiểm soát nhiều hơn” – cái giá phải trả là 18 triệu USD.
Từ góc nhìn của một người từng audit ICO EOS và phát hiện lỗi signature malleability, tôi thấy rõ: khi bạn center hóa bất kỳ quyền lực nào (dù là cập nhật giá), bạn đang tạo ra một trái bom hẹn giờ. EOS có 21 block producers, nhưng oracle của Ostium chỉ có một. Một private key, một điểm thất bại duy nhất.
Takeaway: Dự Báo Lỗ Hổng Trong Tương Lai
Sự kiện Ostium không phải là ngoại lệ. Tôi dự đoán trong vòng 12 tháng tới, ít nhất 3 giao thức RWA khác sẽ bị tấn công theo cách tương tự – vì họ đều đang sử dụng oracle center hóa để giảm chi phí. Bài học rõ ràng: bất kỳ giao thức nào có oracle write access private key đều có thời gian sống trung bình dưới 6 tháng.
Khi Blob data của Dencun bão hòa (dự kiến trong 2 năm), chi phí của các rollup sẽ tăng gấp đôi – và điều đó sẽ buộc các giao thức phải cắt giảm bảo mật trước. Nhưng không phải bằng cách center hóa oracle. Hãy nhìn vào Ostium: họ đã cố gắng cắt giảm chi phí bằng oracle nội bộ, và kết quả là TVL = 0. Mất mát này sẽ được ghi nhớ như một case study kinh điển cho thấy phi tập trung không phải là một lựa chọn, mà là điều kiện sinh tồn.
Câu hỏi cuối cùng: Bạn có bao nhiêu private key trong protocol của mình? Nếu nhiều hơn 0, bạn đã có lỗ hổng.
