Vào ngày 22 tháng 5 năm 2025, Cetus đã gặp phải một cuộc tấn công hợp đồng thông minh phức tạp nhằm vào bể CLMM. Chúng tôi đã ngay lập tức hành động để giảm thiểu tác động, báo cáo này nhằm công khai minh bạch thời gian xảy ra sự kiện, phân tích nguyên nhân, tình trạng tài chính và kế hoạch tiếp theo, đồng thời cùng nhau thúc đẩy các vấn đề tiếp theo.
Dòng thời gian sự kiện
Thời gian UTC 10:30:50 – Cuộc tấn công được khởi động thông qua giao dịch bất thường.
UTC thời gian 10:40:00 – Hệ thống giám sát phát hiện hành vi bất thường của quỹ.
UTC thời gian 10:53:00 – Nhóm Cetus đã xác định nguồn tấn công và gửi cảnh báo đến các thành viên trong hệ sinh thái Sui.
UTC thời gian 10:57:47 – Hồ bơi CLMM cốt lõi đã bị vô hiệu hóa để ngăn chặn việc mở rộng tổn thất.
UTC thời gian 11:20:00 - Tất cả các hợp đồng thông minh liên quan bị vô hiệu hóa toàn cầu.
UTC thời gian 12:50:00 – Các trình xác thực Sui bắt đầu bỏ phiếu từ chối xử lý các giao dịch được ký bởi địa chỉ của kẻ tấn công, khi số phiếu bầu stake vượt quá ngưỡng 33%, các trình xác thực đã "đóng băng" hiệu quả những địa chỉ này.
UTC thời gian 18:04:07 – Gửi tin nhắn thương lượng trên chuỗi cho kẻ tấn công.
UTC thời gian 18:15:28 – Hợp đồng lỗ hổng đã được sửa chữa và nâng cấp (chưa khởi động lại).
Phân tích tấn công
Kẻ tấn công đã lợi dụng một lỗ hổng trong thư viện mã nguồn mở inter\_mate của hợp đồng CLMM, quy trình tấn công như sau:
a. Kẻ tấn công khởi xướng trao đổi chớp nhoáng (flash_swap) tạm thời hạ thấp giá trong quỹ.
b. Mở vị thế ở khoảng giá cao hơn.
c. Sử dụng kiểm tra tràn sai trong logic thêm thanh khoản (add\_liquidity) để tiêm giá trị thanh khoản cao giả mạo với một lượng token rất nhỏ.
d. Thông qua việc loại bỏ thanh khoản nhiều lần (remove_liquidity) để rút cạn dự trữ token.
e. Sử dụng các phép tính chưa được xác minh (như overflowing\_sub, get\_liquidity\_from\_a), lặp lại quy trình trên thông qua các giá trị thanh khoản được cấu trúc cẩn thận.
Lỗ hổng này đã không được phát hiện trong cuộc kiểm toán an ninh trước đó.
Nguyên nhân gốc
Lỗ hổng xuất phát từ sự hiểu lầm về ngữ nghĩa của phép dịch trái trong thư viện mã nguồn mở integer-mate, mà hợp đồng CLMM phụ thuộc vào. Trong phương thức checked\_shlw của nó, kiểm tra thực tế nên là "giá trị đầu vào có ≤2^192", nhưng trong phiên bản bị tấn công lại kiểm tra sai thành "≤2^256", dẫn đến việc kiểm tra tràn số không hiệu quả. Đây là nguyên nhân duy nhất thực sự của cuộc tấn công gần đây.
Kẻ tấn công đã lợi dụng những lỗ hổng nêu trên, bằng cách thao tác với thang giá (tick) của quỹ và cơ chế thanh khoản, đã thành công trong việc rút đi một lượng lớn tài sản qua nhiều vòng tấn công.
Cần làm rõ rằng gần đây trên mạng xã hội có người hiểu sai rằng cuộc tấn công xuất phát từ "MAX_U64 lỗi kiểm tra số học" được đánh dấu trong báo cáo kiểm toán trước đó, điều này đã làm hiểu lầm nhiều người dùng không biết sự thật. Chúng tôi xin tuyên bố: Vấn đề này không liên quan đến cuộc tấn công lần này. Vấn đề này chỉ là một đề xuất tối ưu hóa ở cấp độ thông tin, chỉ trong những trường hợp cực đoan mới có thể dẫn đến việc giao dịch bị quay lại, và đã được tối ưu hóa và sửa chữa trong các phiên bản trước.
Để bảo vệ lợi ích chung của toàn bộ hệ sinh thái, với sự hỗ trợ của hầu hết các xác thực viên Sui, hai địa chỉ ví Sui của kẻ tấn công đã được khẩn cấp đóng băng. Các ví bị đóng băng chứa phần lớn số tiền bị đánh cắp:
Kẻ tấn công ví Sui 1 (đã bị đóng băng): 0xcd8962dad278d8b50fa0f9eb0186bfa4cbdecc6d59377214c88d0286a0ac9562
Kẻ tấn công ví Sui 2 (đã bị đóng băng): 0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06
Các khoản tiền bị đánh cắp còn lại đã được kẻ tấn công hoàn toàn quy đổi và chuyển sang ETH, hiện đang được lưu trữ trong hai ví Ethereum sau đây:
Kẻ tấn công ví Ethereum 1: 0x0251536bfcf144b88e1afa8fe60184ffdb4caf16
Kẻ tấn công ví Ethereum 2: 0x89012a55cd6b88e407c9d4ae9b3425f55924919b
Kế hoạch tiếp theo
Xem xét hợp đồng và tăng cường an ninh
Chúng tôi đang hợp tác với đội ngũ an ninh Sui và nhiều đối tác kiểm toán để xem xét lại hợp đồng đã nâng cấp và tiến hành kiểm toán liên hợp. Chỉ sau khi xác minh toàn diện được thông qua, chúng tôi mới dần khôi phục việc kích hoạt các bể CLMM và các dịch vụ liên quan.
Chúng tôi dự định ngay lập tức khởi động kiểm toán bổ sung và phát hành báo cáo kiểm toán định kỳ dựa trên TVL (Tổng giá trị khóa). Đồng thời, sẽ tiếp tục tăng cường giám sát trên chuỗi, tối ưu hóa cấu hình quản lý rủi ro và thực hiện hạn chế tốc độ có thể kiểm soát đối với lưu chuyển tài sản.
Khôi phục tài sản LP
Chúng tôi đang tích cực hợp tác với các đối tác trong hệ sinh thái cốt lõi để thiết kế các giải pháp phục hồi cho các bể thanh khoản và LP bị ảnh hưởng, nhằm khôi phục chức năng rút thanh khoản và tất cả các dịch vụ của các bể bị ảnh hưởng trong thời gian sớm nhất.
Để đạt được mục tiêu cuối cùng là hoàn trả toàn bộ số tiền mà người dùng đã mất, chúng tôi chân thành kêu gọi tất cả các xác thực viên Sui ủng hộ cuộc bỏ phiếu trên chuỗi mà chúng tôi vừa phát động gần đây. Cuộc bỏ phiếu này sẽ cho phép người dùng nhanh chóng thu hồi phần lớn tài sản. Với sự ủng hộ của bạn, chúng tôi sẽ nhanh chóng tiến hành công việc bồi thường tổn thất cho người dùng và xây dựng lại niềm tin của cộng đồng.
Luật pháp và công việc thương thảo
Trong khi các quy trình pháp lý và thực thi pháp luật tiến triển, chúng tôi cũng đã cung cấp cơ hội cho những kẻ tấn công để trở thành hacker mũ trắng. Sắp tới, chúng tôi sẽ gửi thông báo cuối cùng tới những kẻ tấn công, mọi tiến triển sẽ được công bố một cách minh bạch với cộng đồng.
Kết luận
Chúng tôi chân thành cảm ơn người dùng, quỹ Sui và các đối tác sinh thái đã phản hồi nhanh chóng và hỗ trợ mạnh mẽ, giúp chúng tôi có thể nhanh chóng đóng băng hơn 160 triệu USD và truyền đạt thông tin quan trọng tới các bên bị ảnh hưởng. Đồng thời, chúng tôi hiểu rằng việc phục hồi toàn diện vẫn cần thời gian và đang tích cực thực hiện các biện pháp để đẩy nhanh tiến trình.
Kể từ khi thành lập, Cetus luôn là một trong những đội DeFi đầu tư nhiều nhất vào kiểm toán hợp đồng thông minh và bảo vệ hệ thống trên chuỗi Sui. Tuy nhiên, thực tế không như mong đợi: các hợp đồng nền tảng và thư viện mã nguồn mở phụ thuộc đã trải qua nhiều vòng kiểm toán và được các nhà phát triển trong hệ sinh thái sử dụng thành công rộng rãi, điều này khiến chúng tôi lầm tưởng rằng đã đủ an toàn. Sau khi suy ngẫm lại, chúng tôi nhận ra rằng mình đã không giữ đủ sự cảnh giác. Bài học đau đớn này đã khiến chúng tôi hiểu rằng: cần phải làm nhiều hơn nữa.
Trong tương lai, chúng tôi sẽ tăng cường hệ thống an ninh và kiểm soát rủi ro thông qua các biện pháp sau:
Sử dụng các công cụ như Blockaid để thực hiện giám sát theo thời gian thực, phát hiện và phản ứng kịp thời với các mối đe dọa và lỗ hổng.
Tối ưu hóa cấu hình quản lý rủi ro, thực hiện giới hạn tốc độ có thể kiểm soát cho dòng chảy tài sản.
Nâng cao tỷ lệ bao phủ kiểm tra mã nguồn hợp đồng thông minh
Chỉ số độ phủ mã nguồn công khai
Tiến hành kiểm toán trước khi phát hành chính thức, sau khi có thay đổi mã quan trọng và khi đạt được cột mốc TVL quan trọng.
Nâng cấp chương trình thưởng lỗi mũ trắng, thưởng lớn cho các báo cáo lỗ hổng có giá trị
Các biện pháp trên đã được thực hiện và chúng tôi sẽ tiếp tục sâu sắc hơn.
Ngoài ra, chúng tôi nhận thức rằng việc bảo vệ các giao thức DeFi không thể chỉ dựa vào nỗ lực của đội ngũ và bên kiểm toán, mà cần sức mạnh của toàn bộ hệ sinh thái - từ các nhà phát triển đến những người đóng góp mũ trắng tích cực - cùng nhau giám sát, phòng thủ và cải thiện. Chúng tôi hy vọng tập hợp tất cả sức mạnh có sẵn để xây dựng một cơ sở hạ tầng bền vững và có khả năng phục hồi cho toàn bộ hệ sinh thái, có thể chịu được thử thách của thời gian.
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Báo cáo sự kiện bị đánh cắp của Cetus: Công bố thời gian và chi tiết cuộc tấn công
Nguồn: Cetus; Biên dịch: AIMan@Kim sắc tài chính
Vào ngày 22 tháng 5 năm 2025, Cetus đã gặp phải một cuộc tấn công hợp đồng thông minh phức tạp nhằm vào bể CLMM. Chúng tôi đã ngay lập tức hành động để giảm thiểu tác động, báo cáo này nhằm công khai minh bạch thời gian xảy ra sự kiện, phân tích nguyên nhân, tình trạng tài chính và kế hoạch tiếp theo, đồng thời cùng nhau thúc đẩy các vấn đề tiếp theo.
Dòng thời gian sự kiện
Thời gian UTC 10:30:50 – Cuộc tấn công được khởi động thông qua giao dịch bất thường.
UTC thời gian 10:40:00 – Hệ thống giám sát phát hiện hành vi bất thường của quỹ.
UTC thời gian 10:53:00 – Nhóm Cetus đã xác định nguồn tấn công và gửi cảnh báo đến các thành viên trong hệ sinh thái Sui.
UTC thời gian 10:57:47 – Hồ bơi CLMM cốt lõi đã bị vô hiệu hóa để ngăn chặn việc mở rộng tổn thất.
UTC thời gian 11:20:00 - Tất cả các hợp đồng thông minh liên quan bị vô hiệu hóa toàn cầu.
UTC thời gian 12:50:00 – Các trình xác thực Sui bắt đầu bỏ phiếu từ chối xử lý các giao dịch được ký bởi địa chỉ của kẻ tấn công, khi số phiếu bầu stake vượt quá ngưỡng 33%, các trình xác thực đã "đóng băng" hiệu quả những địa chỉ này.
UTC thời gian 18:04:07 – Gửi tin nhắn thương lượng trên chuỗi cho kẻ tấn công.
UTC thời gian 18:15:28 – Hợp đồng lỗ hổng đã được sửa chữa và nâng cấp (chưa khởi động lại).
Phân tích tấn công
Kẻ tấn công đã lợi dụng một lỗ hổng trong thư viện mã nguồn mở
inter\_matecủa hợp đồng CLMM, quy trình tấn công như sau:a. Kẻ tấn công khởi xướng trao đổi chớp nhoáng (flash_swap) tạm thời hạ thấp giá trong quỹ.
b. Mở vị thế ở khoảng giá cao hơn.
c. Sử dụng kiểm tra tràn sai trong logic
thêm thanh khoản (add\_liquidity)để tiêm giá trị thanh khoản cao giả mạo với một lượng token rất nhỏ.d. Thông qua việc loại bỏ thanh khoản nhiều lần (remove_liquidity) để rút cạn dự trữ token.
e. Sử dụng các phép tính chưa được xác minh (như
overflowing\_sub,get\_liquidity\_from\_a), lặp lại quy trình trên thông qua các giá trị thanh khoản được cấu trúc cẩn thận.Lỗ hổng này đã không được phát hiện trong cuộc kiểm toán an ninh trước đó.
Nguyên nhân gốc
Lỗ hổng xuất phát từ sự hiểu lầm về ngữ nghĩa của phép dịch trái trong thư viện mã nguồn mở
integer-mate, mà hợp đồng CLMM phụ thuộc vào. Trong phương thứcchecked\_shlwcủa nó, kiểm tra thực tế nên là "giá trị đầu vào có ≤2^192", nhưng trong phiên bản bị tấn công lại kiểm tra sai thành "≤2^256", dẫn đến việc kiểm tra tràn số không hiệu quả. Đây là nguyên nhân duy nhất thực sự của cuộc tấn công gần đây.Kẻ tấn công đã lợi dụng những lỗ hổng nêu trên, bằng cách thao tác với thang giá (tick) của quỹ và cơ chế thanh khoản, đã thành công trong việc rút đi một lượng lớn tài sản qua nhiều vòng tấn công.
Cần làm rõ rằng gần đây trên mạng xã hội có người hiểu sai rằng cuộc tấn công xuất phát từ "MAX_U64 lỗi kiểm tra số học" được đánh dấu trong báo cáo kiểm toán trước đó, điều này đã làm hiểu lầm nhiều người dùng không biết sự thật. Chúng tôi xin tuyên bố: Vấn đề này không liên quan đến cuộc tấn công lần này. Vấn đề này chỉ là một đề xuất tối ưu hóa ở cấp độ thông tin, chỉ trong những trường hợp cực đoan mới có thể dẫn đến việc giao dịch bị quay lại, và đã được tối ưu hóa và sửa chữa trong các phiên bản trước.
Địa chỉ của kẻ tấn công (trên chuỗi Sui):
0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06
Tình trạng tài chính
Để bảo vệ lợi ích chung của toàn bộ hệ sinh thái, với sự hỗ trợ của hầu hết các xác thực viên Sui, hai địa chỉ ví Sui của kẻ tấn công đã được khẩn cấp đóng băng. Các ví bị đóng băng chứa phần lớn số tiền bị đánh cắp:
Kẻ tấn công ví Sui 1 (đã bị đóng băng): 0xcd8962dad278d8b50fa0f9eb0186bfa4cbdecc6d59377214c88d0286a0ac9562
Kẻ tấn công ví Sui 2 (đã bị đóng băng): 0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06
Các khoản tiền bị đánh cắp còn lại đã được kẻ tấn công hoàn toàn quy đổi và chuyển sang ETH, hiện đang được lưu trữ trong hai ví Ethereum sau đây:
Kẻ tấn công ví Ethereum 1: 0x0251536bfcf144b88e1afa8fe60184ffdb4caf16
Kẻ tấn công ví Ethereum 2: 0x89012a55cd6b88e407c9d4ae9b3425f55924919b
Kế hoạch tiếp theo
Xem xét hợp đồng và tăng cường an ninh
Chúng tôi đang hợp tác với đội ngũ an ninh Sui và nhiều đối tác kiểm toán để xem xét lại hợp đồng đã nâng cấp và tiến hành kiểm toán liên hợp. Chỉ sau khi xác minh toàn diện được thông qua, chúng tôi mới dần khôi phục việc kích hoạt các bể CLMM và các dịch vụ liên quan.
Chúng tôi dự định ngay lập tức khởi động kiểm toán bổ sung và phát hành báo cáo kiểm toán định kỳ dựa trên TVL (Tổng giá trị khóa). Đồng thời, sẽ tiếp tục tăng cường giám sát trên chuỗi, tối ưu hóa cấu hình quản lý rủi ro và thực hiện hạn chế tốc độ có thể kiểm soát đối với lưu chuyển tài sản.
Khôi phục tài sản LP
Chúng tôi đang tích cực hợp tác với các đối tác trong hệ sinh thái cốt lõi để thiết kế các giải pháp phục hồi cho các bể thanh khoản và LP bị ảnh hưởng, nhằm khôi phục chức năng rút thanh khoản và tất cả các dịch vụ của các bể bị ảnh hưởng trong thời gian sớm nhất.
Để đạt được mục tiêu cuối cùng là hoàn trả toàn bộ số tiền mà người dùng đã mất, chúng tôi chân thành kêu gọi tất cả các xác thực viên Sui ủng hộ cuộc bỏ phiếu trên chuỗi mà chúng tôi vừa phát động gần đây. Cuộc bỏ phiếu này sẽ cho phép người dùng nhanh chóng thu hồi phần lớn tài sản. Với sự ủng hộ của bạn, chúng tôi sẽ nhanh chóng tiến hành công việc bồi thường tổn thất cho người dùng và xây dựng lại niềm tin của cộng đồng.
Luật pháp và công việc thương thảo
Trong khi các quy trình pháp lý và thực thi pháp luật tiến triển, chúng tôi cũng đã cung cấp cơ hội cho những kẻ tấn công để trở thành hacker mũ trắng. Sắp tới, chúng tôi sẽ gửi thông báo cuối cùng tới những kẻ tấn công, mọi tiến triển sẽ được công bố một cách minh bạch với cộng đồng.
Kết luận
Chúng tôi chân thành cảm ơn người dùng, quỹ Sui và các đối tác sinh thái đã phản hồi nhanh chóng và hỗ trợ mạnh mẽ, giúp chúng tôi có thể nhanh chóng đóng băng hơn 160 triệu USD và truyền đạt thông tin quan trọng tới các bên bị ảnh hưởng. Đồng thời, chúng tôi hiểu rằng việc phục hồi toàn diện vẫn cần thời gian và đang tích cực thực hiện các biện pháp để đẩy nhanh tiến trình.
Kể từ khi thành lập, Cetus luôn là một trong những đội DeFi đầu tư nhiều nhất vào kiểm toán hợp đồng thông minh và bảo vệ hệ thống trên chuỗi Sui. Tuy nhiên, thực tế không như mong đợi: các hợp đồng nền tảng và thư viện mã nguồn mở phụ thuộc đã trải qua nhiều vòng kiểm toán và được các nhà phát triển trong hệ sinh thái sử dụng thành công rộng rãi, điều này khiến chúng tôi lầm tưởng rằng đã đủ an toàn. Sau khi suy ngẫm lại, chúng tôi nhận ra rằng mình đã không giữ đủ sự cảnh giác. Bài học đau đớn này đã khiến chúng tôi hiểu rằng: cần phải làm nhiều hơn nữa.
Trong tương lai, chúng tôi sẽ tăng cường hệ thống an ninh và kiểm soát rủi ro thông qua các biện pháp sau:
Sử dụng các công cụ như Blockaid để thực hiện giám sát theo thời gian thực, phát hiện và phản ứng kịp thời với các mối đe dọa và lỗ hổng.
Tối ưu hóa cấu hình quản lý rủi ro, thực hiện giới hạn tốc độ có thể kiểm soát cho dòng chảy tài sản.
Nâng cao tỷ lệ bao phủ kiểm tra mã nguồn hợp đồng thông minh
Chỉ số độ phủ mã nguồn công khai
Tiến hành kiểm toán trước khi phát hành chính thức, sau khi có thay đổi mã quan trọng và khi đạt được cột mốc TVL quan trọng.
Nâng cấp chương trình thưởng lỗi mũ trắng, thưởng lớn cho các báo cáo lỗ hổng có giá trị
Các biện pháp trên đã được thực hiện và chúng tôi sẽ tiếp tục sâu sắc hơn.
Ngoài ra, chúng tôi nhận thức rằng việc bảo vệ các giao thức DeFi không thể chỉ dựa vào nỗ lực của đội ngũ và bên kiểm toán, mà cần sức mạnh của toàn bộ hệ sinh thái - từ các nhà phát triển đến những người đóng góp mũ trắng tích cực - cùng nhau giám sát, phòng thủ và cải thiện. Chúng tôi hy vọng tập hợp tất cả sức mạnh có sẵn để xây dựng một cơ sở hạ tầng bền vững và có khả năng phục hồi cho toàn bộ hệ sinh thái, có thể chịu được thử thách của thời gian.