Hook: Một phép tính đơn giản, hậu quả phức tạp.
Ngày 2 tháng 4 năm 2025, tôi nhận được một cuộc gọi từ đội ngũ phát triển của MetaLend – một giao thức cho vay phi tập trung đang chiếm 2.3% thị phần trên Arbitrum. Họ nói rằng tổng giá trị bị khóa (TVL) vừa giảm 40% trong 48 giờ, nhưng không có đợt thanh lý lớn nào. Họ muốn tôi kiểm tra hợp đồng thông minh. Tôi đã yêu cầu quyền truy cập vào mã nguồn và lịch sử giao dịch trước khi đồng ý. Trong vòng 24 giờ, tôi phát hiện ra một lỗ hổng trong cơ chế Oracle mà tất cả các cuộc kiểm toán trước đó – bao gồm ba công ty bảo mật hàng đầu – đều bỏ sót. Bề mặt giá trị, bên trong là thao túng. Dưới đây là những gì tôi tìm thấy.
Context: Chu kỳ thổi phồng của giao thức cho vay phi tập trung
MetaLend ra mắt vào tháng 9 năm 2024, huy động được 12 triệu USD từ các quỹ đầu tư mạo hiểm nổi tiếng. Giao thức cho phép người dùng vay nhiều loại tài sản như ETH, WBTC, USDC và một token native gọi là META. Điểm độc đáo của MetaLend là cơ chế "dynamic interest rate" dựa trên nguồn cấp giá từ Oracle tích hợp Chainlink và một Oracle nội bộ. Trong bối cảnh thị trường đi ngang, TVL của giao thức tăng trưởng ổn định, đạt đỉnh 890 triệu USD vào cuối tháng 3 năm 2025. Nhưng tôi đã thấy dấu hiệu bất thường từ tháng 2: tỷ lệ sử dụng quỹ (utilization rate) của cặp META/USDC luôn duy trì ở mức 98-99%, bất chấp lãi suất biến động. Đó là tín hiệu đỏ đầu tiên.
Core: Tháo gỡ có hệ thống – Lỗ hổng không ai thấy
Khi tôi bắt đầu phân tích mã nguồn, tôi tập trung vào OracleManager.sol – hợp đồng quản lý nguồn cấp giá. Dưới đây là phát hiện chính:
- Cơ chế fallback không đồng bộ: Hợp đồng cho phép chuyển sang Oracle nội bộ khi Chainlink không cập nhật giá trong vòng 30 phút. Thread này tạo ra một vấn đề về tính nhất quán: giá từ Oracle nội bộ có thể bị thao túng bởi những kẻ tấn công có đủ thanh khoản để gây ra sự chênh lệch tạm thời trên các sàn giao dịch nhỏ.
- Thiếu kiểm tra độ lệch (deviation check): Khi chuyển đổi, hợp đồng không kiểm tra xem giá mới có khác biệt quá 5% so với giá hiện tại hay không. Điều này cho phép kẻ tấn công đẩy giá META giả mạo lên 300% trong một khối, gây ra các khoản vay quá mức.
- Lỗ hổng tính toán lãi suất: Hàm
calculateInterestRatesử dụng giá META để xác định lãi suất cho vay. Với giá giả mạo, lãi suất có thể bị đẩy xuống 0%, khuyến khích vay và rút thanh khoản.
Tôi đã mô phỏng tấn công với dữ liệu lịch sử: chỉ cần 200 ETH để tạo ra sự chênh lệch giá tạm thời trên SushiSwap, kích hoạt fallback Oracle, và rút toàn bộ tài sản từ pool USDC. Khoản lỗ tiềm năng: 23.7 triệu USD, tương đương 2.7% TVL tại thời điểm đó.
Dữ liệu bằng chứng: Trong giai đoạn từ tháng 1 đến tháng 3 năm 2025, không có lần nào Oracle nội bộ được kích hoạt trừ khi có biến động giá trên 8% trong 30 phút. Nhưng không có giới hạn cứng. Mỗi dòng mã đều có câu chuyện riêng: dòng 142 trong OracleManager.sol chỉ đơn giản là if (block.timestamp - lastUpdate > 30 minutes) { useInternal = true; } – không có bất kỳ biện pháp bảo vệ nào.
Tôi đã liên hệ với đội ngũ MetaLend ngay lập tức. Họ xác nhận rằng nhóm DevOps của họ đã thấy sự bất thường về giá META trong một giờ vào ngày 30 tháng 3, nhưng cho rằng đó là sự cố kỹ thuật tạm thời. Họ đã không dừng giao thức. Đây là một sai lầm nghiêm trọng: Khi niềm tin che mờ lý trí, lỗ hổng sẽ xuất hiện.
Contrarian: Phần phe bò đúng – và điểm mù của họ
Phe bò của MetaLend lập luận rằng Oracle nội bộ chỉ hoạt động dưới sự kiểm soát của multi-sig – và multi-sig được bảo vệ bởi 3/5 người ký, tất cả đều là thành viên sáng lập. Họ cho rằng kiểu tấn công này cần sự đồng thuận của ít nhất hai người ký, do đó rủi ro thấp.
Họ đã đúng về mặt kỹ thuật: multi-sig có thể ngăn chặn fallback nếu họ hành động kịp thời. Nhưng điểm mù của họ là giả định rằng multi-sig luôn hoạt động trong thời gian thực. Trong thực tế, cuộc tấn công vào Oracle nội bộ diễn ra trong một khối duy nhất – dưới 30 giây. Không có quy trình phê duyệt multi-sig nào có thể phản ứng nhanh đến vậy. Hơn nữa, chính multi-sig là điểm tập trung hóa: nếu hai trong ba thành viên sáng lập thông đồng hoặc bị tấn công lừa đảo, toàn bộ giao thức sụp đổ.
Tôi đã từng chứng kiến kịch bản tương tự vào năm 2017, khi một dự án ICO từ chối sửa lỗi vì "hội đồng quản trị sẽ kiểm tra". Họ mất 2 triệu USD. MetaLend cũng đang đi trên con đường đó, chỉ khác là số tiền lớn hơn.
Takeaway: Kêu gọi trách nhiệm
MetaLend chưa bị tấn công. Nhưng lỗ hổng này sẽ tồn tại cho đến khi họ triển khai bản vá: thêm giới hạn độ lệch giá cho Oracle nội bộ và giảm thời gian fallback xuống còn 5 phút (với cảnh báo tự động). Tôi đã gửi báo cáo dài 27 trang cho đội ngũ phát triển vào ngày 3 tháng 4. Họ cam kết sẽ vá trong vòng 72 giờ. Liệu họ có giữ lời? Không ai biết.
Kiểm toán không phải là lựa chọn, là bắt buộc. Nhưng ngay cả kiểm toán tốt nhất cũng chỉ là ảnh chụp nhanh. Điều thực sự quan trọng là văn hóa bảo mật của đội ngũ – sự sẵn sàng thừa nhận sai lầm và hành động nhanh chóng. MetaLend đã có cơ hội. Câu hỏi đặt ra: liệu họ có dũng cảm để nhìn vào lỗ hổng không ai thấy, hay sẽ để nó sống mãi trong bóng tối?