Ngày 22 tháng 5 năm 2025, Cetus Protocol – sàn giao dịch phân tán hàng đầu trên blockchain Sui – đã mất khoảng 223 triệu đô la do lỗi tràn số nguyên duy nhất trong thư viện toán học AMM (CLMM) của nó. Vùng lỗ hổng nằm trong một hàm, get_delta_a bên trong clmm_math.move, và khai thác một kiểm tra tràn số không đúng kích thước đã tồn tại trong nhiều cuộc kiểm tra bảo mật.
Đây không phải là câu chuyện về một lỗ hổng mới. Đây là câu chuyện về một lớp lỗi đã được biết đến – toán học giới hạn trong CLMM – mà ngành công nghiệp đã không thể kiểm tra một cách có hệ thống, mặc dù có một tiền lệ gần giống (KyberSwap Elastic, tháng 11 năm 2023, 48,8 triệu USD) tồn tại trong 18 tháng. Sự tấn công của Cetus tốn khoảng làm năm lần nhiều hơn do TVL của Sui đã tăng đáng kể trong thời gian đó.
Lỗi: Kiểm tra quá mức sai kích thước trong checked_shlw
Cách thực hiện CLMM của Cetus sử dụng thư viện toán học chia sẻ, clmm_math.move, được viết bằng Move (ngôn ngữ smart contract của Sui). Move an toàn về bộ nhớ và cung cấp bảo vệ tràn vượt tích hợp cho phép tính toán tiêu chuẩn (+, -, *, /). Tuy nhiên, thư viện này cần một tác vụ đảo sang trái rộng trên một số nguyên không âm 256 bit (u256) – một tác vụ xử lý bit đặc biệt mà thư viện tiêu chuẩn của Move hiển thị dưới dạng checked_shlw.
Tính năng checked_shlw(value: u256, shift: u8) dịch value sang trái bằng shift bit và nên dừng nếu kết quả vượt quá giới hạn của u256. Thang giới hạn tràn vượt đúng cho dịch sang trái 64 bit là:
MAX_SAFE_INPUT = (1 << 192) - 1 // 2^192 - 1
Vì u256 tối đa là 2^256 - 1, dịch sang trái 64 bit có nghĩa là bất kỳ đầu vào ≥ 2^192 sẽ bị tràn. Tuy nhiên, mã Cetus sử dụng một số cố định sai - sai đúng 2^64. Kiểm tra lỗi thực sự cho phép các đầu vào lên đến 2^256 - 1 (tất cả phạm vi u256) được truyền qua, gây ra vòng lặp im lặng.
// CORRECT: abort if value >= 2^192
assert!(value < (1u256 << 192), E_OVERFLOW);
// BUGGY (what Cetus had): off by 2^64 assert!(value < (1u256 << 256), E_OVERFLOW); // 1<<256 == 0 in u256, so this check passes for ALL values
Nhà phát triển có thể đã nhầm lẫn số bit dịch chuyển (64) với chiều rộng bit còn lại (256-64=192). Đây là một "lỗi phân loại" - nhầm lẫn giữa số bit được dịch chuyển và số bit còn lại.
Hướng dẫn tấn công: Sáu bước để kiếm được 223 triệu USD
Nhân vật tấn công không phải chờ đợi điều kiện thị trường để kích hoạt lỗi. Họ tạo ra các điều kiện tiên quyết bằng cách thực hiện một thay đổi nhanh chóng:
- Thay đổi flash — Vay 10 triệu haSUI (một sản phẩm phái sinh của staking) từ một nhóm Cetus.
- Khoảng tick cực đại — Mở vị trí LP với khoảng tick
[300000, 300200], một dải hẹp ở giới hạn trên của khoảng tick (tick tối đa = 887272). Các bộ kiểm tra tiêu chuẩn không bao giờ thực hiện khoảng tick này. - Sự linh hoạt tối thiểu — Chỉ thêm 1 đơn vị token A làm cho nền tảng có tính linh hoạt.
- Lỗi quá mức - do kiểm tra kích thước không đúng,
get_delta_ađã trả về một giá trị lượng liquidity lớn:
- Drain — Xử lý lượng tiền tệ trong nhiều giao dịch, lấy ra khoảng 5,7 triệu SUI từ kho.
- Trả nợ và lợi nhuận — Trả nợ 10 triệu haSUI từ swap flash và giữ lại phần chênh lệch (~ 223 triệu USD vào thời điểm đó).
Tại sao kiểm tra này vẫn tồn tại: Vùng mù kiểm tra
Mỗi cuộc kiểm toán chính của Cetus (và hầu hết các quy trình CLMM) bao gồm:
- Các khoảng giá trị bình thường (ví dụ, [-100000, 100000])
- Mức độ liquidity tiêu chuẩn
- Các đường dẫn swap tiêu biểu
Không thực hiện kiểm tra hệ thống:
- Các khoảng tick ở hoặc gần
MAX_TICK(887272) hoặcMIN_TICK(-887272) - Cơ hội liquidity của đơn vị tại các mức tick cực kỳ thấp
- Các đầu vào giới hạn vượt quá cho
checked_shlwvà các hoạt động dịch chuyển rộng tương tự
Vấn đề lỗ hổng KyberSwap Elastic (tháng 11 năm 2023, 48,8 triệu USD) đáng kể về mặt chức năng – một lỗi sai số trong quá trình khởi tạo vị trí CLMM. Dịch vụ này đã có 18 tháng để cảnh báo. Tuy nhiên, Cetus, được phát triển trên một chuỗi đang phát triển, thừa hưởng điểm mù tương tự.
Lỗi về "Ngôn ngữ an toàn"
Move được quảng cáo là một ngôn ngữ smart contract an toàn với bảo vệ tràn. Điều này đúng cho toán tính chuẩn. Tuy nhiên, checked_shlw là một công thức nội tại chuyên biệt cho việc xử lý bit, nơi người phát triển phải xác định giới hạn tràn. Move không thể suy ra giới hạn chính xác vì nó phụ thuộc vào công dụng ngữ nghĩa của phép dịch chuyển – liệu nó dịch chuyển bằng 64? 128? Một số lượng cố định?
Chìa khóa quan trọng: "Ngôn ngữ an toàn về bộ nhớ" ≠ "Ngôn ngữ an toàn về toán học" khi các nhà phát triển bỏ qua các phép toán tiêu chuẩn cho các hoạt động cấp bit. Lỗi Cetus không phải là một thất bại của các đảm bảo của Move; nó là một thất bại trong việc sử dụng đúng "cửa thoát" của Move cho các dịch chuyển rộng.
Move vs. Solidity: Mỗi loại bảo vệ gì?
| Chức năng | Solidity 0.8+ | Move |
|---|---|---|
a + b | Kiểm tra tràn giới hạn tích hợp | Kiểm tra tràn giới hạn tích hợp |
a * b | Kiểm tra tràn giới hạn tích hợp | Kiểm tra tràn giới hạn tích hợp |
a << 64 (u256) | Không có kiểm tra tích hợp (người phát triển phải sử dụng unchecked hoặc giới hạn thủ công) | checked_shlw cần giới hạn thủ công |
a >> 64 | Không có kiểm tra tích hợp | checked_shrw cần giới hạn thủ công |
Hai hệ sinh thái này đều yêu cầu sự cẩn thận của nhà phát triển để thực hiện các thay đổi lớn. Bug Cetus chứng minh rằng việc kiểm tra sơ đồ giới hạn cũng quan trọng như việc kiểm tra toán học chính nó.
Kết quả đặc thù của Sui: Tạm dừng hoạt động của validator và tranh luận về quản trị
Không giống như Ethereum, nơi các stolen funds thường không thể khôi phục một khi đã bị chuyển đi, mô hình trung tâm đối tượng của Sui cho phép các validator xác định và tạm dừng các đối tượng Coin cụ thể được giữ bởi địa chỉ của kẻ tấn công. Trong vòng vài giờ, các validator đã phối hợp để tạm dừng khoảng 160 triệu USD của các stolen funds còn lại với sự hỗ trợ của cơ chế quản trị.
Điều này đã gây ra tranh cãi gay gắt:
- Pro-freeze: Người dùng được bảo vệ, phần lớn số tiền đã được khôi phục, chứng minh khả năng của chuỗi trong việc phản ứng với lỗi nghiêm trọng.
- Phòng ngừa freeze (Anti-freeze): Vi phạm khả năng chống kiểm duyệt, tạo ra tiền lệ cho sự can thiệp của validator, có thể bị lạm dụng cho mục đích kiểm duyệt chính trị.
token SUI giảm 7%, token CETUS giảm 40%, và các token trong hệ sinh thái Sui mất tới 80% giá trị trong tuần sau đó. Người tấn công đã thành công trong việc chuyển ~$62 triệu USDC sang Ethereum và chuyển đổi thành ~23.000 ETH trước khi lệnh freeze có hiệu lực.
So sánh lịch sử: KyberSwap Elastic (Tháng 11 năm 2023)
| Khía cạnh | KyberSwap Elastic | Cetus Protocol |
|---|---|---|
| Ngày | Tháng 11 năm 2023 | Tháng 5 năm 2025 |
| Blockchain | Ethereum | Sui |
| Thiệt hại | 48,8 triệu USD | 223 triệu USD |
| Nguyên nhân gốc rễ | Tròn số giới hạn tick trong computeSwapStep | Tràn số nguyên trong checked_shlw (get_delta_a) |
| Vectơ tấn công | tick cực kỳ + mất độ chính xác | tick cực kỳ + tràn số dời |
Thất bại của ngành không phải là khám phá lớp lỗi – nó là không thể thực hiện kiểm tra có hệ thống cho nó trong mọi triển khai CLMM mới.
Các bài học phòng thủ: điều gì đã ngăn chặn được sự việc này
1. Kiểm tra dựa trên thuộc tính ở các cực điểm
Các thử nghiệm đơn vị tiêu chuẩn bao gồm các "lối đi hạnh phúc". Các thử nghiệm dựa trên thuộc tính (sử dụng các công cụ như Proptest cho Move hoặc Echidna/ Foundry cho Solidity) nên xác nhận các tính chất không thay đổi trong toàn bộ phạm vi thời gian:// Pseudocode for property test
#[test]
fn test_get_delta_a_no_overflow_at_any_tick() {
for tick_lower in MIN_TICK..=MAX_TICK {
for tick_upper in (tick_lower+1)..=MAX_TICK {
for liquidity in [1, 1000, MAX_LIQUIDITY] {
let result = get_delta_a(liquidity, tick_lower, tick_upper);
assert!(result <= MAX_U256); // Never overflows
}
}
}
}
2. Kiểm tra hoạt động chuyển đổi rộng
Mọi việc sử dụng `checked_shlw`, `checked_shrw` hoặc các intrinsec wide-shift tương đương nên được thực hiện ở biên giới:- Đầu vào =
2^192 - 1(mức an toàn tối đa) - Đầu vào =
2^192(lần tràn đầu tiên) - Input =
2^256 - 1(max u256)
3. Các thử nghiệm bảo tồn không thay đổi cho CLMM
Danh sách kiểm tra kiểm toán nên yêu cầu: "* Không có chuỗi các tác vụ hợp lệ (mint, burn, swap, flash) có thể khiến giá trị không thay đổi của kho không vượt quá giá trị chính xác theo toán học.*" Điều này sẽ phát hiện cả lỗi tràn và lỗi hướng tròn.4. Diện tích kiểm toán phải bao gồm thư viện chung
`clmm_math.move` là một thư viện chia sẻ được sử dụng trong tất cả các pool của Cetus. Kiểm tra chỉ các hợp đồng pool trong khi coi thư viện toán học là "có thể tin cậy" là một khoảng trống. Mỗi thư viện toán học chia sẻ nên được được bao phủ bởi kiểm tra toán học độc lập.5. Thay đổi Flash như điều kiện bắt đầu tấn công – theo dõi các hoạt động sửa đổi trạng thái
Các quy trình nên theo dõi các thay đổi flash + tạo đồng xu LP ngay lập tức ở các tick cực cao như một mẫu đáng nghi. Sự kết hợp này (các bước chuẩn bị trạng thái có hiệu quả về vốn) là một dấu hiệu của các lỗ hổng toán học.
Hỏi đáp
Cetus Protocol hack đã mất bao nhiêu tiền?
Khoảng 223 triệu USD (tương đương 5,7 triệu SUI vào thời điểm đó), trở thành vụ hack DeFi lớn thứ hai của năm 2025 sau Bybit (1,46 tỷ USD).Nguyên nhân gốc rễ của vụ tấn công Cetus là gì?
Một bùng nhịp số nguyên trong hàm `checked_shlw` trong `get_delta_a` (trong `clmm_math.move`). Kiểm tra bùng nhịp sử dụng một giá trị cố định bị sai lệch bằng `2^64`, cho phép dịch sang trái 64 bit diễn ra một cách không phát hiện.Lực lượng tấn công đã khai thác lỗi Cetus như thế nào?
hacker đã sử dụng flash swap để vay 10M haSUI, mở một vị trí LP với phạm vi tick cực đại `[300000, 300200]` với 1 đơn vị likidty, gây ra quá tải để nhận được ~10^37 likidty, sau đó rút hết pool.Tại sao điều này được gọi là "lợi dụng thư viện chia sẻ"?
Công thức dễ bị tấn công `get_delta_a` nằm trong `clmm_math.move` - một thư viện toán học được chia sẻ và được sử dụng bởi tất cả các pool Cetus CLMM. Lỗi nằm trong thư viện, chứ không phải trong hợp đồng pool riêng lẻ.Cetus hack có liên quan đến vụ hack KyberSwap không?
Đúng – nguyên nhân cơ bản tương tự. Cả hai đều khai thác toán học giới hạn tick trong quá trình khởi tạo vị trí CLMM. KyberSwap (tháng 11 năm 2023, 48,8 triệu USD) là một lỗi tròn số; Cetus (tháng 5 năm 2025, 223 triệu USD) là một tình trạng tràn số nguyên. Cùng một điểm mù, 18 tháng sau, thiệt hại tăng 5 lần.Các tính năng bảo mật của Move có thể ngăn chặn loại lỗi này không?
Các kiểm tra overflow tích hợp trong Move bảo vệ số học tiêu chuẩn (+, -, *, /). Chúng không tự động bảo vệ các hàm nội tại shift rộng như `checked_shlw` — nhà phát triển phải xác định giới hạn chính xác. Lỗi Cetus là một lỗi giới hạn được nhà phát triển xác định, không phải là lỗi của ngôn ngữ.Điều gì đã xảy ra với số tiền bị đánh cắp?
Người tấn công đã chuyển ~62 triệu USDT sang Ethereum (~23.000 ETH). Các validator Sui đã phối hợp để freeze ~160 triệu USD còn lại on-chain – một phản ứng quản trị gây tranh cãi nhưng hiệu quả, độc đáo với mô hình đối tượng của Sui.Kết luận
Vụ hack Cetus Protocol là một ví dụ về thất bại trong thử nghiệm hệ thống. Khuyết điểm (CLMM tick-boundary arithmetic) đã được biết đến trong 18 tháng. Sự tiền lệ (KyberSwap) đã được công bố. Cách khắc phục (thử nghiệm dựa trên thuộc tính ở các giới hạn, fuzzing các thay đổi lớn, kiểm toán các thư viện chung) đã được ghi lại đầy đủ. Tuy nhiên, một DEX hàng đầu trên một L1 lớn đã được phát hành với cùng một điểm mù và mất 223 triệu USD.
Dạy học này vượt ra ngoài Sui hoặc Move: Các trường hợp biên độ toán học trong các thư viện toán học được kiểm tra và hoàn thiện vẫn là điểm mù nhất trong ngành. Các kẻ tấn công không tìm thấy lỗi mới – họ thiết kế các điều kiện giới hạn mà các bộ kiểm tra bỏ qua. Cho đến khi việc kiểm tra bằng cách sử dụng phương pháp pha trộn và kiểm tra dựa trên thuộc tính ở các giới hạn toán học trở thành yêu cầu kiểm tra bắt buộc, chứ không phải là các phương pháp tốt nhất có thể lựa chọn, mô hình này sẽ lặp lại – trên Sui, trên Ethereum, trên mỗi chuỗi chạy DeFi.
Câu hỏi 223 triệu đô la không phải là "làm thế nào điều này xảy ra?" mà là "tại sao chúng ta vẫn chưa kiểm tra điều này?"
Bài phân tích này dựa trên 12+ nguồn độc lập bao gồm các báo cáo hậu kiểm (Cetus, Sui Foundation), báo cáo kiểm toán an ninh (Dedaub, Verichains, Quillaudits, Cyfrin), phân tích chuỗi (blockSec, Cyvers, SlowMist) và các tiền lệ lịch sử (KyberSwap). Tất cả các chi tiết kỹ thuật được kiểm chứng qua tối thiểu 3 nguồn cho mỗi tuyên bố.
