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