Giải thích phân tích của chuyên nghiệp về sự kiện tấn công Hacker của Cetus Protocol

Phiên bản thông dụng: Giải thích đơn giản về "dịch" các chuyên nghiệp về @CetusProtocol

Phân tích sự kiện tấn công hacker:

Cuộc tấn công lần này đã phơi bày một vấn đề tràn số nguyên cổ điển, thể hiện cụ thể ở việc cắt đứt dữ liệu trong quá trình chuyển đổi kiểu.

Phân tích chi tiết kỹ thuật:

1）Vị trí lỗ hổng: Vấn đề xuất hiện trong cơ chế chuyển đổi kiểu của hàm get_amount_by_liquidity, việc chuyển đổi cưỡng bức từ u256 sang u64 dẫn đến mất dữ liệu ở vị trí cao.

2）Quy trình tấn công:

1、Kẻ tấn công truyền vào tham số số lượng thanh khoản cực lớn thông qua hàm add_liquidity;

2、Hệ thống gọi hàm get_delta_b để tính toán số lượng B token cần thiết;

3. Trong quá trình tính toán, hai dữ liệu loại U128 được nhân lên và kết quả lý thuyết phải là loại U256;

Thiếu sót quan trọng: Hàm trả về giá trị u256 bị ép kiểu thành u64, dẫn đến 128 bit dữ liệu cao bị cắt.

3）Hiệu quả sử dụng: Trước đây cần rất nhiều token để đúc ra hạn mức thanh khoản, giờ chỉ cần một lượng token rất nhỏ là có thể hoàn thành. Kẻ tấn công có được phần thanh khoản khổng lồ với chi phí cực thấp, sau đó thực hiện việc phá hủy một phần thanh khoản để kiếm lợi từ quỹ.

Phép so sánh đơn giản: Giống như việc sử dụng máy tính chỉ hiển thị 8 chữ số để tính 10 tỷ × 10 tỷ, kết quả 20 chữ số chỉ có thể hiển thị 8 chữ số cuối, 12 chữ số đầu tiên sẽ biến mất. Kẻ tấn công đã lợi dụng "lỗ hổng mất độ chính xác trong tính toán" này.

Cần phải làm rõ một điểm: lỗ hổng này không liên quan đến kiến trúc an ninh nền tảng của @SuiNetwork, mà liên quan đến tính an toàn của ngôn ngữ Move "vinh quang" tạm thời vẫn đáng tin cậy. Tại sao?

Ngôn ngữ Move thực sự có những ưu điểm đáng kể về quản lý tài nguyên và an toàn kiểu, có thể hiệu quả ngăn chặn các vấn đề an toàn cơ bản như thanh toán kép, rò rỉ tài nguyên. Nhưng sự cố của giao thức Cetus lần này là một lỗi tính toán toán học ở cấp độ logic ứng dụng, không phải là khiếm khuyết trong thiết kế của ngôn ngữ Move.

Cụ thể, mặc dù hệ thống kiểu của Move rất nghiêm ngặt, nhưng đối với các thao tác chuyển đổi kiểu rõ ràng (explicit casting), vẫn cần dựa vào phán đoán đúng đắn của nhà phát triển. Khi chương trình chủ động thực hiện chuyển đổi kiểu từ u256 sang u64, trình biên dịch không thể xác định đây là thiết kế có chủ ý hay lỗi logic.

Ngoài ra, sự cố an ninh lần này hoàn toàn không liên quan đến cơ chế đồng thuận, xử lý giao dịch, quản lý trạng thái và các chức năng cốt lõi khác của Sui. Mạng Sui chỉ thực hiện trung thành các chỉ thị giao dịch được gửi bởi giao thức Cetus, lỗ hổng xuất phát từ khuyết điểm logic của chính giao thức ứng dụng.

Nói một cách đơn giản, không có ngôn ngữ lập trình nào tiên tiến đến mức có thể hoàn toàn ngăn chặn lỗi logic ở tầng ứng dụng. Move có thể phòng ngừa phần lớn các rủi ro an ninh ở tầng cơ sở, nhưng không thể thay thế cho lập trình viên trong việc kiểm tra biên giới logic kinh doanh và bảo vệ tràn số trong các phép toán.

Sửa đổi:

Đã trao đổi thêm với chuyên nghiệp, trước đây có sự sai lệch về chi tiết cụ thể trong phân tích kỹ thuật cuộc tấn công của @CetusProtocol, xin được điều chỉnh lại.

Trước đó đã xác định chính xác đây là một lỗ hổng loại tràn số trong phép toán, kẻ tấn công thông qua việc cấu trúc giá trị đặc biệt "lấy ít thắng nhiều" là đúng, giải đáp về sự an toàn của ngôn ngữ Move mà mọi người quan tâm cũng là đúng.

Chỉ đơn giản là thấy hiện tượng sai sót trong phép toán, suy đoán là vấn đề chuyển đổi kiểu, nhưng thực tế là vấn đề kiểm tra biên của các hàm khác. Thực tế, ngôn ngữ Move có cơ chế kiểm tra nghiêm ngặt đối với việc chuyển đổi từ u256 sang u64 và các loại khác, việc chuyển đổi rõ ràng như vậy thực sự sẽ có kiểm tra an toàn trong các trường hợp bình thường.

Cần sửa chữa vị trí lỗ hổng cụ thể và cơ chế thực hiện kỹ thuật như sau.

Vấn đề thực sự xuất hiện trong cơ chế kiểm tra tràn của hàm get\_delta\_a không còn hiệu lực:

1）Chức năng: Tính toán số lượng token A cần thiết khi thêm thanh khoản chỉ định;

2）Khuyết điểm chính: Kiểm tra tràn của hàm checked\_shlw có lỗi mã hóa, không ngăn chặn giá trị thanh khoản lớn không hợp lệ;

3）Tấn công lợi dụng: Hacker xây dựng giá trị thanh khoản đặc biệt, vượt qua kiểm tra không hiệu lực, cuối cùng thông qua cơ chế làm tròn lên của div\_round khiến số lượng token A cần thiết trở thành 14).

Hiệu ứng tấn công: Sử dụng 1 token A để đúc thanh khoản khổng lồ, sau đó rút cạn quỹ.