Hook: Một con số biết nói
Tuần trước, trong lúc đang kiểm tra dữ liệu on-chain của giao thức cho vay XYZ, tôi thấy một điều bất thường: có 47 giao dịch flash loan liên tiếp được thực hiện trong vòng 12 giây. Toàn bộ đều xuất phát từ cùng một địa chỉ contract, nhưng mỗi lần lại vay một lượng nhỏ và tương tác với một pool thanh khoản mới. Thông thường, flash loan dùng để arbitrage chỉ chạy 2-3 bước. 47 bước — đó không phải arbitrage. Đó là một cuộc tấn công có tổ chức, một 'bầy đàn' (swarm) các giao dịch nhỏ được thiết kế để vượt qua hệ thống phòng thủ của giao thức.
Context: DeFi và bài toán bảo vệ nhiều lớp
XYZ là một giao thức cho vay đa tài sản, sử dụng mô hình lãi suất dựa trên cung cầu, tương tự Aave và Compound — vốn có mô hình lãi suất tùy tiện, không gắn với thị trường thực. Tuy nhiên, điểm khác biệt của XYZ là họ tự hào về hệ thống 'phòng thủ nhiều lớp' của mình: một oracle giá được bảo vệ bởi nhiều nguồn, một bộ giới hạn rút tiền (withdrawal limits) theo từng block, và một mô-đun kiểm tra chênh lệch giá giữa các pool thanh khoản. Nhưng như nhiều dự án DeFi khác, họ tập trung bảo vệ các giao dịch lớn, mà bỏ qua mối đe dọa từ các giao dịch nhỏ lẻ, phân tán — giống như cách các hệ thống phòng không truyền thống bỏ qua bầy drone giá rẻ.
Sự kiện lần này bắt đầu khi một hacker (hoặc một nhóm) triển khai một smart contract đặc biệt, có khả năng thực hiện hàng loạt flash loan nhỏ, mỗi lần khai thác một lỗ hổng cụ thể trong logic tính lãi của XYZ. Lỗ hổng nằm ở chỗ: khi một pool thanh khoản có biến động giá nhỏ (ví dụ 0.01%), mô-đun kiểm tra chênh lệch sẽ không kích hoạt vì nó được thiết kế để chỉ phản ứng với chênh lệch > 0.5%. Bằng cách tạo ra hàng loạt biến động nhỏ liên tiếp, kẻ tấn công đã 'lừa' hệ thống cho phép các khoản vay với lãi suất thấp một cách bất thường.
Core: Chuỗi bằng chứng on-chain
Tôi đã dành hai ngày để lần theo dấu vết của 47 giao dịch đó. Dưới đây là những gì tôi tìm thấy:
1. Mô hình tấn công 'Swarm' - 47 giao dịch được thực hiện từ một contract duy nhất (0xABCD...1234). - Mỗi giao dịch chỉ vay 1.000 USDC, đủ nhỏ để không vượt qua giới hạn rút tiền theo block (block limit là 100.000 USDC). - Mỗi giao dịch tương tác với một pool thanh khoản khác nhau (USDC/DAI, USDC/USDT, DAI/USDT, v.v.), tận dụng biến động giá nhỏ giữa các pool. - Tổng cộng 47.000 USDC được vay, nhưng lợi nhuận thu về chỉ 2.300 USDC — rất nhỏ so với quy mô. Nhưng đó là vì đây chỉ là cuộc thử nghiệm. Vài giờ sau, một cuộc tấn công thứ hai với 1.200 giao dịch đã rút sạch 1,2 triệu USDC khỏi giao thức.
2. Phân tích hành vi oracle - Trong quá trình tấn công, oracle giá (Chainlink) đã cập nhật giá mỗi 10 giây. Nhưng do các giao dịch diễn ra trong cùng một block (12 giây), oracle không kịp phản ánh biến động tổng hợp. Hệ thống chỉ nhìn thấy từng giao dịch riêng lẻ. - Điểm mấu chốt: mô-đun kiểm tra chênh lệch chỉ so sánh giá hiện tại với giá cách đó 30 giây — một khoảng thời gian quá dài để phát hiện các biến động nhỏ liên tiếp trong cùng một block.
3. Dấu vết ví và dòng tiền - Contract tấn công được nạp tiền từ một ví trung gian (0xDEAD...), ví này lại nhận ETH từ một sàn giao dịch tập trung có KYC yếu (sàn Z). - Số tiền rút được (1,2 triệu USDC) ngay lập tức được chuyển qua Tornado Cash trong vòng 5 phút. Đến nay, chưa có dấu vết nào tiếp theo.
Bảng tóm tắt các giao dịch then chốt
| Tx Hash | Block | Amount | Pool | Action | Profit | |---------|-------|--------|------|--------|--------| | 0xabc1 | 18,200,001 | 1,000 USDC | USDC/DAI | Vay + Swap | 0.02% | | 0xabc2 | 18,200,001 | 1,000 USDC | USDC/USDT | Vay + Swap | 0.01% | | ... | ... | ... | ... | ... | ... | | 0xabc47 | 18,200,001 | 1,000 USDC | DAI/USDT | Vay + Swap | 0.03% |
(Không thể hiện hết 47 dòng trong bài, nhưng tôi đã kiểm tra tất cả)
Contrarian: Tương quan không phải nhân quả
Nhiều người sẽ vội kết luận: 'Lỗ hổng là do oracle giá chậm' hoặc 'Giới hạn rút tiền theo block quá thấp.' Nhưng đó là cách nghĩ sai hướng. Thực ra, lỗ hổng cốt lõi nằm ở thiết kế phòng thủ tuyến tính: tất cả các biện pháp bảo vệ đều dựa trên ngưỡng cố định và kiểm tra từng giao dịch riêng lẻ, không có khả năng phát hiện các mẫu tấn công phân tán theo thời gian.
Giao thức XYZ đã đầu tư rất nhiều vào bảo vệ chống lại các cuộc tấn công lớn (ví dụ: một flash loan 10 triệu USDC), nhưng lại bỏ qua các cuộc tấn công nhỏ lẻ, lặp đi lặp lại. Điều này tương tự như cách các hệ thống phòng không truyền thống tập trung vào đánh chặn tên lửa hành trình mà quên mất bầy drone giá rẻ.
Góc nhìn phản trực giác: - Giới hạn rút tiền theo block thực ra đã được tính toán đúng — nó bảo vệ khỏi rút một lần lớn. Nhưng nó tạo ra ảo tưởng an toàn khiến đội ngũ bỏ qua các cuộc tấn công nhỏ lặp lại. - Oracle giá Chainlink hoàn toàn đáng tin cậy cho các giao dịch đơn lẻ. Vấn đề là giao thức không có cơ chế 'tổng hợp biến động' trong một khoảng thời gian ngắn (ví dụ: nếu tổng biến động trong 5 block vượt quá X%, hãy tạm dừng). - Kẻ tấn công không cần kỹ thuật cao — chỉ cần viết một contract đơn giản thực hiện vòng lặp 47 lần. Số lượng giao dịch không phải là rào cản; sự ngu ngốc trong thiết kế phòng thủ mới là vấn đề.
Takeaway: Tín hiệu cho tuần tới
Cuộc tấn công này là một lời cảnh tỉnh cho toàn bộ ngành DeFi. Các giao thức đã quen với việc bảo vệ chống 'cá mập lớn', nhưng kẻ thù thực sự lại đến từ 'bầy cá nhỏ' phối hợp. Tôi dự đoán trong vòng 2-3 tuần tới, sẽ có ít nhất 3 giao thức khác bị tấn công theo cùng một mô hình 'flash loan swarm'.
Câu hỏi dành cho bạn: Nếu giao thức của bạn có một cơ chế phát hiện bất thường dựa trên tổng khối lượng giao dịch nhỏ trong một block, liệu nó có thể ngăn chặn được kiểu tấn công này không? Hay bạn vẫn đang tự tin rằng 'giới hạn rút tiền là đủ'?