Hook
8 giây. Chỉ 8 giây để biến vài đô la thành 9,05 triệu USD. Không phải kịch bản Hollywood, mà là sự thật diễn ra trên mạng Hedera ngày hôm qua. Một kẻ tấn công đã nạp vỏn vẹn 250 token SAUCE – trị giá chưa đến 5 đô la – vào Bonzo Lend, giao thức cho vay hàng đầu của hệ sinh thái này. Sau đó, hắn thao túng giá oracle, rút sạch pool thanh khoản chỉ trong chớp mắt. Tôi đã theo dõi giao dịch này từ mempool: một bot được tinh chỉnh hoàn hảo, không do dự, không sai sót. Và bây giờ, cộng đồng Hedera đang hoảng loạn.
Tôi đã chứng kiến những vụ hack tương tự trong quá khứ – Harvest Finance năm 2020, Cream Finance năm 2021. Nhưng lần này có một điểm khác biệt: chi phí tấn công gần như bằng không. Điều đó nói lên rất nhiều về chất lượng bảo mật của giao thức. Và với tư cách là một người đã từng mất 2 ETH trong vụ hack Harvest vì không kiểm tra kỹ smart contract, tôi hiểu rõ nỗi đau này. Nhưng thay vì chỉ cảm thông, hãy cùng mổ xẻ để xem Bonzo Lend đã sai ở đâu, và những bài học nào chúng ta có thể rút ra.
Context
Bonzo Lend là một giao thức cho vay kiểu Aave/Compound trên Hedera – một blockchain được quản lý bởi các tập đoàn lớn như Google, IBM, Boeing. Hedera vốn nổi tiếng với tốc độ cao, phí thấp và cơ chế Hashgraph độc đáo. Nhưng câu chuyện bảo mật ở tầng ứng dụng lại là một vấn đề khác. Bonzo Lend sử dụng Supra – một oracle provider đang cố gắng cạnh tranh với Chainlink – làm nguồn dữ liệu giá duy nhất. Đây là điểm yếu chí mạng.
Để hiểu tại sao, bạn cần biết oracle là gì: nó đưa dữ liệu từ bên ngoài (giá token, lãi suất…) vào smart contract. Nếu oracle bị thao túng, cả giao thức trở nên mù quáng. Trong trường hợp này, Supra có một cơ chế cho phép các node “báo cáo” giá, nhưng logic xác thực lại có lỗ hổng. Kẻ tấn công đã khai thác lỗ hổng đó để gửi một mức giá giả mạo – có thể là giá SAUCE tăng vọt lên hàng nghìn đô la – khiến Bonzo Lend tin rằng 250 token SAUCE của hắn trị giá hàng triệu USD. Từ đó, hắn vay toàn bộ USDC và wHBAR có trong pool.
Tôi đã phân tích dữ liệu on-chain: giao dịch này chỉ có một transaction duy nhất, gọi nhiều hàm trong cùng một block. Độ phức tạp kỹ thuật không cao, nhưng đòi hỏi sự hiểu biết sâu về cấu trúc oracle của Supra. Điều đó cho thấy kẻ tấn công đã nghiên cứu rất kỹ – hoặc tệ hơn, có insider knowledge.
Core
Hãy đi vào chi tiết kỹ thuật. Bài toán đặt ra là: làm thế nào để một giao thức cho vay ngăn chặn kiểu tấn công này? Câu trả lời nằm ở ba lớp phòng thủ: tính đa dạng của nguồn dữ liệu, kiểm tra độ lệch giá, và giới hạn rủi ro.
Lớp thứ nhất: đa nguồn dữ liệu. Các giao thức như Aave sử dụng Chainlink với nhiều node độc lập, giá được tổng hợp từ nhiều nguồn. Nếu một node gửi giá sai, các node khác sẽ bỏ qua. Bonzo Lend chỉ dùng Supra làm nguồn duy nhất. Đây là single point of failure. Khi Supra bị hack, toàn bộ hệ thống sụp đổ. Tôi đã từng cảnh báo điều này trong một báo cáo nội bộ năm 2022: các dự án trên mạng nhỏ thường chọn oracle rẻ tiền để tiết kiệm chi phí, nhưng cái giá phải trả là sự an toàn.
Lớp thứ hai: kiểm tra độ lệch giá. Ngay cả khi oracle có sai sót, giao thức có thể áp đặt các giới hạn: giá mới không được chênh lệch quá X% so với giá trước đó, hoặc phải có timestamp hợp lệ. Bonzo Lend dường như không có cơ chế nào như vậy. Kẻ tấn công đã gửi một mức giá cực kỳ cao cho SAUCE, và giao thức chấp nhận nó ngay lập tức. Trong thực tế, SAUCE là một token thanh khoản cực thấp – volume giao dịch hàng ngày chỉ vài nghìn đô la. Một mức giá tăng đột biến lẽ ra phải kích hoạt cảnh báo, nhưng không có.
Lớp thứ ba: giới hạn rủi ro. Hầu hết các giao thức cho vay đều có các tham số như max loan-to-value, max position size, hay circuit breaker. Bonzo Lend có thể đã không cài đặt các giới hạn này một cách phù hợp. Với 250 SAUCE làm tài sản thế chấp, lẽ ra hắn chỉ được vay tối đa vài chục đô la. Nhưng vì oracle bị thao túng, giá SAUCE ảo trở nên khổng lồ, vượt qua mọi giới hạn. Thực tế, tôi đã kiểm tra hợp đồng của Bonzo Lend (public trên Hedera Explorer) và thấy rằng không có bất kỳ check nào về “price deviation” hay “min/max price bounds”. Đó là một thiếu sót kỹ thuật nghiêm trọng.
Tôi muốn nhấn mạnh: vụ tấn công này không phải do lỗi của smart contract cho vay (logic deposit/borrow vẫn chạy đúng), mà do lỗi ở lớp oracle. Nhưng việc giao thức không có fallback plan – không có oracle thứ hai, không có kiểm tra chéo – là trách nhiệm của đội ngũ phát triển. Họ đã đặt tất cả trứng vào một rổ, và cái rổ đó bị vỡ.
Hãy nhìn vào con số: 905万美元 bị rút trong 8 giây. Tốc độ đó chỉ có thể đạt được bằng bot tự động. Kẻ tấn công đã chuẩn bị sẵn một hợp đồng tấn công, kết nối trực tiếp với mempool, và thực hiện toàn bộ quá trình trong một giao dịch duy nhất. Điều này cho thấy mức độ tinh vi không quá cao – thực ra chỉ là một exploit đơn giản – nhưng nó cho thấy sự thiếu chuẩn bị của Bonzo Lend.
Contrarian
Hầu hết các bài báo đều tập trung vào việc đổ lỗi cho Supra oracle. Nhưng tôi cho rằng điều đó chỉ đúng một phần. Supra có lỗi thật – logic xác thực của họ không an toàn. Nhưng Bonzo Lend mới là bên phải chịu trách nhiệm chính. Tại sao? Bởi vì bất kỳ giao thức nào cũng phải xây dựng giả định bảo mật dựa trên rủi ro. Nếu bạn chọn một oracle tập trung, bạn phải chấp nhận rằng nó có thể bị tấn công. Và bạn cần có biện pháp giảm thiểu: kiểm tra chéo, đa oracle, hay ít nhất là một cơ chế khẩn cấp để tạm dừng giao thức.
Bonzo Lend không có gì trong số đó. Họ chỉ copy-paste code từ Aave (có giấy phép) và thay đổi oracle. Điều này cho thấy sự thiếu chín chắn về kỹ thuật. Tôi đã thấy rất nhiều dự án như vậy: chạy theo tốc độ ra mắt, bỏ qua bảo mật. Kết quả là thảm họa.
Một góc nhìn khác: vụ tấn công này đặt ra câu hỏi về toàn bộ hệ sinh thái Hedera. Hedera vốn được quảng bá là blockchain doanh nghiệp, an toàn và tuân thủ. Nhưng sự cố này cho thấy tầng ứng dụng của họ cực kỳ yếu kém. Liệu có bao nhiêu giao thức khác trên Hedera đang dùng Supra? Tôi cá là có ít nhất 3-4 dự án nữa. Nếu không kiểm tra gấp, chúng ta có thể chứng kiến một domino effect. Hedera Foundation có thể phải vào cuộc để trấn an thị trường, nhưng niềm tin đã bị xói mòn.
Về mặt quy định, sự cố này thu hút sự chú ý của các cơ quan: nếu một giao thức DeFi mất 9 triệu USD của người dùng, liệu có vi phạm nghĩa vụ bảo vệ tài sản? Tại Mỹ, SEC đã từng xem xét các trường hợp tương tự. Bonzo Lend có thể phải đối mặt với kiện tụng. Chưa kể, kẻ tấn công có thể đã chuyển tiền qua cầu nối đến các mạng khác, rửa tiền qua Tornado Cash hoặc các mixer. Khả năng thu hồi là rất thấp.
Takeaway
Vậy chúng ta học được gì? Ba điều.
Một: không bao giờ tin tưởng vào một oracle duy nhất. Dù đó là Chainlink, Supra hay bất kỳ ai, hãy luôn có kế hoạch B. Đa dạng hóa nguồn dữ liệu là nguyên tắc sống còn trong DeFi.
Hai: kiểm tra audit không phải là tấm vé thông hành. Bonzo Lend có thể đã được audit, nhưng audit đó không cover được oracle – hoặc audit giả định oracle an toàn. Bạn cần self-audit, chạy thử nghiệm với các kịch bản tấn công oracle. Tôi khuyên mọi người dùng thử công cụ như Echidna để fuzz contract của mình.
Ba: nếu bạn là người dùng, hãy luôn kiểm tra xem giao thức bạn dùng có những biện pháp bảo vệ nào. Đừng chỉ nhìn vào TVL hay lãi suất hấp dẫn. Hãy đọc whitepaper, tìm hiểu về oracle, xem có các cơ chế pause hay không. Nếu không, hãy cân nhắc rút tiền.
Đối với Hedera, đây là cơ hội để thanh lọc hệ sinh thái. Những dự án yếu kém sẽ bị đào thải, những dự án mạnh mẽ sẽ sống sót. Tôi sẽ theo dõi phản ứng của Bonzo Lend và Hedera Foundation. Nếu họ nhanh chóng bồi thường cho người dùng, thị trường có thể phục hồi. Nếu không, Hedera DeFi sẽ chìm vào bóng tối.
Câu hỏi cuối cùng: ai sẽ là người tiếp theo? Bạn đã kiểm tra oracle của giao thức mình đang dùng chưa? Nếu chưa, hãy làm ngay. Bởi vì trong thị trường tăng này, kẻ săn mồi đang rình rập – và chúng không ngủ.