Suy ngẫm và bài học từ sự kiện Cetus bị hacker tấn công
Gần đây, một giao thức đã phát hành một báo cáo "tổng kết" về an ninh liên quan đến các cuộc tấn công của Hacker. Báo cáo này công khai các chi tiết kỹ thuật và phản ứng khẩn cấp một cách khá minh bạch, được coi là cấp sách giáo khoa. Tuy nhiên, khi trả lời câu hỏi cốt lõi "tại sao lại bị hack", báo cáo lại có vẻ hơi lảng tránh.
Báo cáo đã giải thích chi tiết về lỗi kiểm tra của hàm checked_shlw trong thư viện integer-mate (nên là ≤2^192, thực tế là ≤2^256), và định tính nó là "hiểu sai ngữ nghĩa". Mặc dù mô tả này về mặt kỹ thuật là không thể chê, nhưng nó khéo léo chuyển trọng tâm sang trách nhiệm bên ngoài, như thể giao thức bản thân cũng là nạn nhân vô tội của lỗi kỹ thuật này.
Tuy nhiên, điều đáng suy ngẫm là: vì sao integer-mate là một thư viện toán học mã nguồn mở được ứng dụng rộng rãi, lại xuất hiện một lỗi lố bịch như vậy trong giao thức, dẫn đến việc chỉ cần 1 token là có thể nhận được phần chia lợi nhuận thanh khoản khổng lồ?
Phân tích đường đi của hacker có thể phát hiện ra rằng việc thực hiện thành công một cuộc tấn công cần phải đồng thời thỏa mãn bốn điều kiện: kiểm tra tràn sai lầm, phép toán dịch lớn, quy tắc làm tròn lên và thiếu kiểm tra tính hợp lý về kinh tế. Điều đáng ngạc nhiên là giao thức đã mắc phải "sự cẩu thả" ở mỗi "điều kiện kích hoạt": chấp nhận đầu vào của người dùng là những con số thiên văn như 2^200, sử dụng phép toán dịch lớ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 "1 token đổi lấy phần chia giá trên trời" - một kết quả rõ ràng không hợp lý, lại không có bất kỳ kiểm tra về tính hợp lý kinh tế nào mà đã thực thi ngay lập tức.
Do đó, các vấn đề mà giao thức thực sự cần suy ngẫm bao gồm:
Tại sao không tiến hành kiểm tra an ninh đầy đủ khi sử dụng thư viện bên ngoài phổ biến? 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 khi quản lý tài sản trị giá hàng trăm triệu đô la, giao thức rõ ràng thiếu hiểu biết sâu sắc về ranh giới an ninh của thư viện đó, cũng như các phương án thay thế khi chức năng của thư viện gặp sự cố. Điều này cho thấy giao thức còn thiếu nhận thức về bảo vệ an ninh chuỗi cung ứng.
Tại sao lại cho phép nhập số thiên văn mà không đặt ra giới hạn hợp lý? Mặc dù giao thức tài chính phi tập trung theo đuổi tính mở, nhưng một hệ thống tài chính trưởng thành càng mở thì càng cần có ranh giới rõ ràng. Việc cho phép nhập những giá trị quá mức như vậy cho thấy đội ngũ thiếu những nhân tài quản lý rủi ro có trực giác tài chính.
Tại sao sau nhiều vòng kiểm tra an ninh vẫn không phát hiện được vấn đề? Điều này phản ánh một sai lầm nhận thức chết người: phía dự án hoàn toàn ủy thác trách nhiệm an ninh cho công ty an ninh, coi việc kiểm tra như một huy chương miễn trách. Tuy nhiên, kỹ sư kiểm tra an ninh chủ yếu giỏi trong việc phát hiện lỗ hổng mã, rất ít khi xem xét đến những vấn đề có thể xảy ra khi hệ thống thử nghiệm tính toán ra tỷ lệ trao đổi cực kỳ không hợp lý.
Sự xác minh vượt qua ranh giới củ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 lĩnh vực an ninh tài chính phi tập trung hiện đại. Các công ty kiểm toán có thể cho rằng điều này thuộc về khuyết điểm thiết kế mô hình kinh tế chứ không phải vấn đề logic mã; các bên dự án có thể phàn nàn rằng kiểm toán không phát hiện ra vấn đề; và cuối cùng, tài sản của người dùng là những người bị thiệt hại.
Sự kiện này đã phơi bày các điểm yếu an ninh hệ thống trong ngành tài chính phi tập trung: các nhóm có nền tảng công nghệ thuần túy thường thiếu "khả năng cảm nhận rủi ro tài chính" cơ bản.
Từ báo cáo của giao thức này, đội ngũ dường như chưa nhận thức đầy đủ về điều này. So với việc chỉ chú ý đến những khiếm khuyết kỹ thuật của cuộc tấn công Hacker này, tất cả các đội ngũ tài chính phi tập trung nên vượt qua những giới hạn của tư duy thuần túy kỹ thuật, thực sự phát triển nhận thức về rủi ro an toàn của "kỹ sư tài chính".
Các biện pháp cụ thể có thể bao gồm: thu hút các chuyên gia quản lý rủi ro tài chính để bù đắp cho những điểm mù về kiến thức của đội ngũ kỹ thuật; thiết lập cơ chế kiểm toán và đánh giá đa bên, không chỉ chú trọng vào kiểm toán mã nguồn mà còn cần quan tâm đến kiểm toán mô hình kinh tế; phát triển "khả năng nhạy bé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, duy trì sự cảnh giác cao độ đối với các hoạt động bất thường, v.v.
Điều này gợi nhớ đến sự đồng thuận của những người làm việc trong ngành an ninh: khi ngành ngày càng trưởng thành, các lỗ hổng kỹ thuật thuần túy ở mức mã sẽ dần dần giảm bớt, trong khi các "lỗ hổng nhận thức" trong logic kinh doanh với ranh giới không rõ ràng và trách nhiệm mơ hồ sẽ trở thành thách thức lớn nhất.
Công ty kiểm toán có thể đảm bảo rằng mã không có lỗ hổng, nhưng cách thực hiện "logic có giới hạn" thì cần đội ngũ dự á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 giới hạn. Điều này cũng giải thích tại sao nhiều dự án đã trải qua kiểm toán an ninh vẫn bị tấn công bởi Hacker.
Tương lai của tài chính phi tập trung chắc chắn sẽ thuộc về những đội ngũ không chỉ có kỹ thuật mã nguồn tốt mà còn hiểu sâu về logic kinh doanh!
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Cetus giao thức bị hack tiết lộ điểm yếu an ninh DeFi: khoảng cách giữa công nghệ và tài chính cần được lấp đầy ngay lập tức
Suy ngẫm và bài học từ sự kiện Cetus bị hacker tấn công
Gần đây, một giao thức đã phát hành một báo cáo "tổng kết" về an ninh liên quan đến các cuộc tấn công của Hacker. Báo cáo này công khai các chi tiết kỹ thuật và phản ứng khẩn cấp một cách khá minh bạch, được coi là cấp sách giáo khoa. Tuy nhiên, khi trả lời câu hỏi cốt lõi "tại sao lại bị hack", báo cáo lại có vẻ hơi lảng tránh.
Báo cáo đã giải thích chi tiết về lỗi kiểm tra của hàm checked_shlw trong thư viện integer-mate (nên là ≤2^192, thực tế là ≤2^256), và định tính nó là "hiểu sai ngữ nghĩa". Mặc dù mô tả này về mặt kỹ thuật là không thể chê, nhưng nó khéo léo chuyển trọng tâm sang trách nhiệm bên ngoài, như thể giao thức bản thân cũng là nạn nhân vô tội của lỗi kỹ thuật này.
Tuy nhiên, điều đáng suy ngẫm là: vì sao integer-mate là một thư viện toán học mã nguồn mở được ứng dụng rộng rãi, lại xuất hiện một lỗi lố bịch như vậy trong giao thức, dẫn đến việc chỉ cần 1 token là có thể nhận được phần chia lợi nhuận thanh khoản khổng lồ?
Phân tích đường đi của hacker có thể phát hiện ra rằng việc thực hiện thành công một cuộc tấn công cần phải đồng thời thỏa mãn bốn điều kiện: kiểm tra tràn sai lầm, phép toán dịch lớn, quy tắc làm tròn lên và thiếu kiểm tra tính hợp lý về kinh tế. Điều đáng ngạc nhiên là giao thức đã mắc phải "sự cẩu thả" ở mỗi "điều kiện kích hoạt": chấp nhận đầu vào của người dùng là những con số thiên văn như 2^200, sử dụng phép toán dịch lớ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 "1 token đổi lấy phần chia giá trên trời" - một kết quả rõ ràng không hợp lý, lại không có bất kỳ kiểm tra về tính hợp lý kinh tế nào mà đã thực thi ngay lập tức.
Do đó, các vấn đề mà giao thức thực sự cần suy ngẫm bao gồm:
Tại sao không tiến hành kiểm tra an ninh đầy đủ khi sử dụng thư viện bên ngoài phổ biến? 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 khi quản lý tài sản trị giá hàng trăm triệu đô la, giao thức rõ ràng thiếu hiểu biết sâu sắc về ranh giới an ninh của thư viện đó, cũng như các phương án thay thế khi chức năng của thư viện gặp sự cố. Điều này cho thấy giao thức còn thiếu nhận thức về bảo vệ an ninh chuỗi cung ứng.
Tại sao lại cho phép nhập số thiên văn mà không đặt ra giới hạn hợp lý? Mặc dù giao thức tài chính phi tập trung theo đuổi tính mở, nhưng một hệ thống tài chính trưởng thành càng mở thì càng cần có ranh giới rõ ràng. Việc cho phép nhập những giá trị quá mức như vậy cho thấy đội ngũ thiếu những nhân tài quản lý rủi ro có trực giác tài chính.
Tại sao sau nhiều vòng kiểm tra an ninh vẫn không phát hiện được vấn đề? Điều này phản ánh một sai lầm nhận thức chết người: phía dự án hoàn toàn ủy thác trách nhiệm an ninh cho công ty an ninh, coi việc kiểm tra như một huy chương miễn trách. Tuy nhiên, kỹ sư kiểm tra an ninh chủ yếu giỏi trong việc phát hiện lỗ hổng mã, rất ít khi xem xét đến những vấn đề có thể xảy ra khi hệ thống thử nghiệm tính toán ra tỷ lệ trao đổi cực kỳ không hợp lý.
Sự xác minh vượt qua ranh giới củ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 lĩnh vực an ninh tài chính phi tập trung hiện đại. Các công ty kiểm toán có thể cho rằng điều này thuộc về khuyết điểm thiết kế mô hình kinh tế chứ không phải vấn đề logic mã; các bên dự án có thể phàn nàn rằng kiểm toán không phát hiện ra vấn đề; và cuối cùng, tài sản của người dùng là những người bị thiệt hại.
Sự kiện này đã phơi bày các điểm yếu an ninh hệ thống trong ngành tài chính phi tập trung: các nhóm có nền tảng công nghệ thuần túy thường thiếu "khả năng cảm nhận rủi ro tài chính" cơ bản.
Từ báo cáo của giao thức này, đội ngũ dường như chưa nhận thức đầy đủ về điều này. So với việc chỉ chú ý đến những khiếm khuyết kỹ thuật của cuộc tấn công Hacker này, tất cả các đội ngũ tài chính phi tập trung nên vượt qua những giới hạn của tư duy thuần túy kỹ thuật, thực sự phát triển nhận thức về rủi ro an toàn của "kỹ sư tài chính".
Các biện pháp cụ thể có thể bao gồm: thu hút các chuyên gia quản lý rủi ro tài chính để bù đắp cho những điểm mù về kiến thức của đội ngũ kỹ thuật; thiết lập cơ chế kiểm toán và đánh giá đa bên, không chỉ chú trọng vào kiểm toán mã nguồn mà còn cần quan tâm đến kiểm toán mô hình kinh tế; phát triển "khả năng nhạy bé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, duy trì sự cảnh giác cao độ đối với các hoạt động bất thường, v.v.
Điều này gợi nhớ đến sự đồng thuận của những người làm việc trong ngành an ninh: khi ngành ngày càng trưởng thành, các lỗ hổng kỹ thuật thuần túy ở mức mã sẽ dần dần giảm bớt, trong khi các "lỗ hổng nhận thức" trong logic kinh doanh với ranh giới không rõ ràng và trách nhiệm mơ hồ sẽ trở thành thách thức lớn nhất.
Công ty kiểm toán có thể đảm bảo rằng mã không có lỗ hổng, nhưng cách thực hiện "logic có giới hạn" thì cần đội ngũ dự á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 giới hạn. Điều này cũng giải thích tại sao nhiều dự án đã trải qua kiểm toán an ninh vẫn bị tấn công bởi Hacker.
Tương lai của tài chính phi tập trung chắc chắn sẽ thuộc về những đội ngũ không chỉ có kỹ thuật mã nguồn tốt mà còn hiểu sâu về logic kinh doanh!