Đọc xong báo cáo "Tổng kết" về an ninh tấn công của @CetusProtocol, bạn sẽ phát hiện ra một hiện tượng "đáng suy ngẫm": chi tiết kỹ thuật được công bố khá minh bạch, phản ứng khẩn cấp cũng được coi là tiêu chuẩn trong sách giáo khoa, nhưng trong câu hỏi then chốt nhất "tại sao lại bị hack", lại có vẻ tránh né.
Báo cáo sử dụng một lượng lớn nội dung để giải thích hàm checked\_shlw trong thư viện integer-mate kiểm tra lỗi (nên ≤2^192, thực tế ≤2^256), và định nghĩa điều này là "hiểu sai ngữ nghĩa". Mặc dù mô tả này về mặt kỹ thuật là đúng, nhưng nó khéo léo chuyển trọng tâm sang trách nhiệm bên ngoài, như thể Cetus cũng là nạn nhân vô tội của khiếm khuyết kỹ thuật này.
Câu hỏi đặt ra là, vì sao integer-mate lại là một thư viện toán học mã nguồn mở và được ứng dụng rộng rãi, nhưng lại xảy ra một lỗi không hợp lý khi chỉ cần 1 token là có thể nhận được một phần thanh khoản có giá trị khổng lồ?
Phân tích đường tấn công của hacker sẽ phát hiện ra rằng để thực hiện một cuộc tấn công hoàn hảo, hacker phải đáp ứng đồng thời bốn điều kiện: kiểm tra tràn sai lầm, phép toán dịch chuyển lớn, quy tắc làm tròn lên, và thiếu xác minh tính hợp lý kinh tế.
Cetus đã "lơ là" ở mỗi "điều kiện kích hoạt", chẳng hạn như: chấp nhận đầu vào của người dùng là những con số khổng lồ như 2^200, thực hiện các phép toán dịch chuyển cực kỳ nguy hiểm, hoàn toàn tin tưởng vào cơ chế kiểm tra của thư viện bên ngoài, điều nghiêm trọng nhất là - khi hệ thống tính toán ra kết quả "1 token đổi lấy một phần giá trên trời" như vậy, lại không có bất kỳ kiểm tra kiến thức kinh tế nào và đã trực tiếp thực hiện.
Vì vậy, những điểm thực sự mà Cetus nên xem xét là như sau:
1）Tại sao lại không thực hiện kiểm tra an toàn với thư viện bên ngoài phổ biến? Mặc dù thư viện integer-mate có đặc điểm là mã nguồn mở, phổ biến và được sử dụng rộng rãi, nhưng Cetus đã sử dụng nó để quản lý tài sản trị giá hàng trăm triệu đô la mà không hiểu rõ ranh giới an toàn của thư viện này ở đâu, và nếu thư viện không hoạt động thì có phương án thay thế phù hợp hay không, v.v. Rõ ràng, Cetus thiếu nhận thức cơ bản về bảo mật chuỗi cung ứng;
Tại sao lại cho phép nhập số lượng khổng lồ mà không đặt giới hạn? Mặc dù các giao thức DeFi nên tìm kiếm sự phi tập trung, nhưng một hệ thống tài chính trưởng thành càng mở cửa thì càng cần có những giới hạn rõ ràng.
Khi hệ thống cho phép một số tiền khổng lồ được xây dựng cẩn thận bởi một kẻ tấn công, nhóm dường như đã không nghĩ về việc liệu yêu cầu thanh khoản như vậy có hợp lý hay không. Ngay cả quỹ phòng hộ lớn nhất thế giới cũng không có khả năng cần một phần thanh khoản phóng đại như vậy. Rõ ràng, nhóm Cetus thiếu tài năng quản lý rủi ro với trực giác tài chính;
Tại sao vẫn không có vấn đề nào được tìm thấy trước sau nhiều vòng kiểm tra bảo mật? Câu này vô tình phơi bày một hiểu lầm nhận thức chết người: nhóm dự án thuê ngoài trách nhiệm bảo mật cho công ty bảo mật và coi việc kiểm toán là huy chương vàng để được miễn trừ. Nhưng thực tế rất khắc nghiệt: các kỹ sư kiểm toán bảo mật rất giỏi trong việc tìm ra lỗi mã, và ai có thể nghĩ rằng việc kiểm tra hệ thống để tính toán tỷ lệ trao đổi tuyệt vời có thể là sai?
Việc xác thực vượt qua ranh giới giữa toán học, mật mã và kinh tế học chính là điểm mù lớn nhất về an toàn trong DeFi hiện đại. Các công ty kiểm toán sẽ nói "Đây là lỗi thiết kế mô hình kinh tế, không phải vấn đề logic mã"; phía dự án thì phàn nàn "kiểm toán không phát hiện vấn đề"; còn người dùng chỉ biết rằng tiền của họ đã biến mất!
Bạn thấy đấy, điều này cuối cùng đã phơi bày điểm yếu hệ thống về an toàn trong ngành DeFi: các đội ngũ chỉ có nền tảng kỹ thuật thiếu nghiêm trọng "khả năng cảm nhận rủi ro tài chính" cơ bản.
Và từ báo cáo của Cetus, đội ngũ rõ ràng chưa có sự suy ngẫm đúng mức.
So với việc chỉ đơn thuần chỉ ra những thiếu sót về kỹ thuật liên quan đến cuộc tấn công của hacker lần này, tôi cảm thấy từ Cetus bắt đầu, tất cả các đội DeFi nên từ bỏ sự hạn chế của tư duy chỉ dựa vào kỹ thuật, thực sự nuôi dưỡng nhận thức về rủi ro an ninh của "kỹ sư tài chính".
Ví dụ, giới thiệu các chuyên gia kiểm soát rủi ro tài chính để bù đắp cho điểm mù kiến thức của đội ngũ kỹ thuật; Thực hiện cơ chế đánh giá kiểm toán đa bên, không chỉ xem xét kiểm toán mã mà còn tạo ra kiểm toán mô hình kinh tế cần thiết; Trau dồi "ý thức tài chính", mô phỏng các kịch bản tấn công khác nhau và các biện pháp đối phó tương ứng, đồng thời luôn nhạy cảm với các hoạt động bất thường.
Điều này khiến tôi nhớ đến kinh nghiệm làm việc trước đây tại công ty an ninh, bao gồm sự đồng thuận như vậy trong các cuộc trao đổi giữa những đại diện lớn trong ngành an ninh như @evilcos, @chiachih_wu, @yajinzhou, @mikelee205.
Khi ngành trưởng thành, số lượng lỗi kỹ thuật ở cấp độ mã sẽ giảm, và thách thức lớn nhất là logic kinh doanh "nhận thức lỗi" với ranh giới không rõ ràng và trách nhiệm mơ hồ.
Công ty kiểm toán chỉ có thể đảm bảo mã không có lỗi, nhưng làm thế nào để đạt được "giới hạn logic" cần đội ngũ dự án có hiểu biết sâu sắc hơn về bản chất của công việc và khả năng kiểm soát giới hạn. (Nguyên nhân cơ bản của nhiều sự kiện "đổ lỗi" vẫn bị hacker tấn công sau nhiều cuộc kiểm toán an ninh trước đây chính là ở đây)
Tương lai của DeFi thuộc về những đội ngũ có kỹ thuật mã hóa vững vàng, đồng thời hiểu sâu sắc về logic kinh doanh!
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.
Cetus vấn đề an toàn gợi ý: Đội ngũ DeFi cần chú ý điều gì?
Tác giả: Haotian
Đọc xong báo cáo "Tổng kết" về an ninh tấn công của @CetusProtocol, bạn sẽ phát hiện ra một hiện tượng "đáng suy ngẫm": chi tiết kỹ thuật được công bố khá minh bạch, phản ứng khẩn cấp cũng được coi là tiêu chuẩn trong sách giáo khoa, nhưng trong câu hỏi then chốt nhất "tại sao lại bị hack", lại có vẻ tránh né.
Báo cáo sử dụng một lượng lớn nội dung để giải thích hàm
checked\_shlwtrong thư việninteger-matekiểm tra lỗi (nên ≤2^192, thực tế ≤2^256), và định nghĩa điều này là "hiểu sai ngữ nghĩa". Mặc dù mô tả này về mặt kỹ thuật là đúng, nhưng nó khéo léo chuyển trọng tâm sang trách nhiệm bên ngoài, như thể Cetus cũng là nạn nhân vô tội của khiếm khuyết kỹ thuật này.Câu hỏi đặt ra là, vì sao
integer-matelại là một thư viện toán học mã nguồn mở và được ứng dụng rộng rãi, nhưng lại xảy ra một lỗi không hợp lý khi chỉ cần 1 token là có thể nhận được một phần thanh khoản có giá trị khổng lồ?Phân tích đường tấn công của hacker sẽ phát hiện ra rằng để thực hiện một cuộc tấn công hoàn hảo, hacker phải đáp ứng đồng thời bốn điều kiện: kiểm tra tràn sai lầm, phép toán dịch chuyển lớn, quy tắc làm tròn lên, và thiếu xác minh tính hợp lý kinh tế.
Cetus đã "lơ là" ở mỗi "điều kiện kích hoạt", chẳng hạn như: chấp nhận đầu vào của người dùng là những con số khổng lồ như 2^200, thực hiện các phép toán dịch chuyển cực kỳ nguy hiểm, hoàn toàn tin tưởng vào cơ chế kiểm tra của thư viện bên ngoài, điều nghiêm trọng nhất là - khi hệ thống tính toán ra kết quả "1 token đổi lấy một phần giá trên trời" như vậy, lại không có bất kỳ kiểm tra kiến thức kinh tế nào và đã trực tiếp thực hiện.
Vì vậy, những điểm thực sự mà Cetus nên xem xét là như sau:
1）Tại sao lại không thực hiện kiểm tra an toàn với thư viện bên ngoài phổ biến? Mặc dù thư viện
integer-matecó đặc điểm là mã nguồn mở, phổ biến và được sử dụng rộng rãi, nhưng Cetus đã sử dụng nó để quản lý tài sản trị giá hàng trăm triệu đô la mà không hiểu rõ ranh giới an toàn của thư viện này ở đâu, và nếu thư viện không hoạt động thì có phương án thay thế phù hợp hay không, v.v. Rõ ràng, Cetus thiếu nhận thức cơ bản về bảo mật chuỗi cung ứng;Khi hệ thống cho phép một số tiền khổng lồ được xây dựng cẩn thận bởi một kẻ tấn công, nhóm dường như đã không nghĩ về việc liệu yêu cầu thanh khoản như vậy có hợp lý hay không. Ngay cả quỹ phòng hộ lớn nhất thế giới cũng không có khả năng cần một phần thanh khoản phóng đại như vậy. Rõ ràng, nhóm Cetus thiếu tài năng quản lý rủi ro với trực giác tài chính;
Việc xác thực vượt qua ranh giới giữa toán học, mật mã và kinh tế học chính là điểm mù lớn nhất về an toàn trong DeFi hiện đại. Các công ty kiểm toán sẽ nói "Đây là lỗi thiết kế mô hình kinh tế, không phải vấn đề logic mã"; phía dự án thì phàn nàn "kiểm toán không phát hiện vấn đề"; còn người dùng chỉ biết rằng tiền của họ đã biến mất!
Bạn thấy đấy, điều này cuối cùng đã phơi bày điểm yếu hệ thống về an toàn trong ngành DeFi: các đội ngũ chỉ có nền tảng kỹ thuật thiếu nghiêm trọng "khả năng cảm nhận rủi ro tài chính" cơ bản.
Và từ báo cáo của Cetus, đội ngũ rõ ràng chưa có sự suy ngẫm đúng mức.
So với việc chỉ đơn thuần chỉ ra những thiếu sót về kỹ thuật liên quan đến cuộc tấn công của hacker lần này, tôi cảm thấy từ Cetus bắt đầu, tất cả các đội DeFi nên từ bỏ sự hạn chế của tư duy chỉ dựa vào kỹ thuật, thực sự nuôi dưỡng nhận thức về rủi ro an ninh của "kỹ sư tài chính".
Ví dụ, giới thiệu các chuyên gia kiểm soát rủi ro tài chính để bù đắp cho điểm mù kiến thức của đội ngũ kỹ thuật; Thực hiện cơ chế đánh giá kiểm toán đa bên, không chỉ xem xét kiểm toán mã mà còn tạo ra kiểm toán mô hình kinh tế cần thiết; Trau dồi "ý thức tài chính", mô phỏng các kịch bản tấn công khác nhau và các biện pháp đối phó tương ứng, đồng thời luôn nhạy cảm với các hoạt động bất thường.
Điều này khiến tôi nhớ đến kinh nghiệm làm việc trước đây tại công ty an ninh, bao gồm sự đồng thuận như vậy trong các cuộc trao đổi giữa những đại diện lớn trong ngành an ninh như @evilcos, @chiachih_wu, @yajinzhou, @mikelee205.
Khi ngành trưởng thành, số lượng lỗi kỹ thuật ở cấp độ mã sẽ giảm, và thách thức lớn nhất là logic kinh doanh "nhận thức lỗi" với ranh giới không rõ ràng và trách nhiệm mơ hồ.
Công ty kiểm toán chỉ có thể đảm bảo mã không có lỗi, nhưng làm thế nào để đạt được "giới hạn logic" cần đội ngũ dự án có hiểu biết sâu sắc hơn về bản chất của công việc và khả năng kiểm soát giới hạn. (Nguyên nhân cơ bản của nhiều sự kiện "đổ lỗi" vẫn bị hacker tấn công sau nhiều cuộc kiểm toán an ninh trước đây chính là ở đây)
Tương lai của DeFi thuộc về những đội ngũ có kỹ thuật mã hóa vững vàng, đồng thời hiểu sâu sắc về logic kinh doanh!