Đọc xong báo cáo "phân tích" về vụ tấn công an ninh của @CetusProtocol, bạn sẽ nhận ra một hiện tượng "đáng chú ý": chi tiết kỹ thuật được công bố 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 "tại sao lại bị hack", một câu hỏi cốt lõi, lại có vẻ như né tránh.
Báo cáo sử dụng nhiều trang để giải thích về hàm checked\_shlw của thư viện integer-mate kiểm tra lỗi (nên ≤2^192, thực tế ≤2^256), và định tính điều này là "sự hiểu lầm về 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 vào 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ì 'integer-mate' là một thư viện toán học mã nguồn mở và được sử dụng rộng rãi, nên sẽ là một sai lầm lố bịch khi bạn có được một cổ phần thanh khoản cao ngất ngưởng cho 1 token?
Phân tích đường đi của cuộc tấn công Hacker sẽ thấy rằng, để thực hiện cuộc tấn công hoàn hảo, Hacker phải đồng thời thỏa mãn bốn điều kiện: kiểm tra tràn sai, phép toán dịch bit lớn, quy tắc làm tròn lên, thiếu xác minh tính hợp lý kinh tế.
Cetus đã hoàn toàn "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ố thiên văn 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ý là "1 token đổi lấy phần chia giá trên trời", lại không có bất kỳ kiểm tra kiến thức kinh tế nào trước khi thực hiện.
Vì vậy, những điểm mà Cetus thực sự nên suy ngẫm là:
1）Tại sao việc sử dụng thư viện bên ngoài phổ quát lại không được kiểm tra an toàn đầ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, Cetus đã sử dụng nó để quản lý tài sản lên đến hàng triệu đô la mà không hiểu đầy đủ các ranh giới an toàn của thư viện này là đâu, và nếu thư viện không còn hiệu lực thì có giải pháp thay thế phù hợp nào không, v.v. Rõ ràng, Cetus thiếu ý thức bảo vệ an toàn chuỗi cung ứng cơ bản nhất;
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ở rộng thì càng cần có những ranh giới rõ ràng.
Khi hệ thống cho phép nhập vào những số thiên văn được kẻ tấn công xây dựng một cách tinh vi, đội ngũ rõ ràng đã không suy nghĩ về việc, liệu nhu cầu thanh khoản như vậy có hợp lý không? Ngay cả quỹ đầu tư phòng hộ lớn nhất thế giới cũng không thể cần một phần thanh khoản quá lớn 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 vẫn không phát hiện ra vấn đề trước? Câu này vô tình phơi bày một sai lầm nhận thức chí mạng: bên dự án đã ủy thác 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á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 phát hiện lỗi mã, ai mà nghĩ rằng việc kiểm tra hệ thống để tính toán tỷ lệ trao đổi như một câu chuyện không tưởng có thể có vấn đề?
Sự xác thực 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 ninh 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 ra 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, trong phân tích cuối cùng, điều này phơi bày những thiếu sót về bảo mật hệ thống của ngành DeFi: các nhóm có nền tảng kỹ thuật thuần túy thiếu "mùi 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ự tự phản ánh đầy đủ.
So với những thiếu sót kỹ thuật đơn thuần liên quan đến cuộc tấn công hacker lần này, tôi nghĩ rằng bắt đầu từ Cetus, tất cả các đội DeFi nên từ bỏ sự hạn chế của tư duy thuần túy về công nghệ, 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ụ, 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ớ 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 của các ông lớn trong ngành @evilcos, @chiachih_wu, @yajinzhou, @mikelee205 khi trao đổi.
Với sự trưởng thành ngày càng tăng của ngành, các vấn đề Bug kỹ thuật ở cấp mã sẽ ngày càng giảm, trong khi "Bug ý thức" trong 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 "rào cản 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 cơ bản của nhiều sự kiện "đổ lỗi" sau khi kiểm toán an ninh vẫn bị tấn công bởi Hacker 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!
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.
Hơn 200 triệu USD bị đánh cắp, sự kiện an ninh Cetus đã mang lại những bài học gì?
Đọc xong báo cáo "phân tích" về vụ tấn công an ninh của @CetusProtocol, bạn sẽ nhận ra một hiện tượng "đáng chú ý": chi tiết kỹ thuật được công bố 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 "tại sao lại bị hack", một câu hỏi cốt lõi, lại có vẻ như né tránh.
Báo cáo sử dụng nhiều trang để giải thích về hàm
checked\_shlwcủa thư việninteger-matekiểm tra lỗi (nên ≤2^192, thực tế ≤2^256), và định tính điều này là "sự hiểu lầm về 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 vào 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ì 'integer-mate' là một thư viện toán học mã nguồn mở và được sử dụng rộng rãi, nên sẽ là một sai lầm lố bịch khi bạn có được một cổ phần thanh khoản cao ngất ngưởng cho 1 token?
Phân tích đường đi của cuộc tấn công Hacker sẽ thấy rằng, để thực hiện cuộc tấn công hoàn hảo, Hacker phải đồng thời thỏa mãn bốn điều kiện: kiểm tra tràn sai, phép toán dịch bit lớn, quy tắc làm tròn lên, thiếu xác minh tính hợp lý kinh tế.
Cetus đã hoàn toàn "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ố thiên văn 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ý là "1 token đổi lấy phần chia giá trên trời", lại không có bất kỳ kiểm tra kiến thức kinh tế nào trước khi thực hiện.
Vì vậy, những điểm mà Cetus thực sự nên suy ngẫm là:
1）Tại sao việc sử dụng thư viện bên ngoài phổ quát lại không được kiểm tra an toàn đầ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, Cetus đã sử dụng nó để quản lý tài sản lên đến hàng triệu đô la mà không hiểu đầy đủ các ranh giới an toàn của thư viện này là đâu, và nếu thư viện không còn hiệu lực thì có giải pháp thay thế phù hợp nào không, v.v. Rõ ràng, Cetus thiếu ý thức bảo vệ an toàn chuỗi cung ứng cơ bản nhất;Khi hệ thống cho phép nhập vào những số thiên văn được kẻ tấn công xây dựng một cách tinh vi, đội ngũ rõ ràng đã không suy nghĩ về việc, liệu nhu cầu thanh khoản như vậy có hợp lý không? Ngay cả quỹ đầu tư phòng hộ lớn nhất thế giới cũng không thể cần một phần thanh khoản quá lớn 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 vẫn không phát hiện ra vấn đề trước? Câu này vô tình phơi bày một sai lầm nhận thức chí mạng: bên dự án đã ủy thác 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á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 phát hiện lỗi mã, ai mà nghĩ rằng việc kiểm tra hệ thống để tính toán tỷ lệ trao đổi như một câu chuyện không tưởng có thể có vấn đề?
Sự xác thực 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 ninh 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 ra 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, trong phân tích cuối cùng, điều này phơi bày những thiếu sót về bảo mật hệ thống của ngành DeFi: các nhóm có nền tảng kỹ thuật thuần túy thiếu "mùi 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ự tự phản ánh đầy đủ.
So với những thiếu sót kỹ thuật đơn thuần liên quan đến cuộc tấn công hacker lần này, tôi nghĩ rằng bắt đầu từ Cetus, tất cả các đội DeFi nên từ bỏ sự hạn chế của tư duy thuần túy về công nghệ, 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ụ, 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ớ 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 của các ông lớn trong ngành @evilcos, @chiachih_wu, @yajinzhou, @mikelee205 khi trao đổi.
Với sự trưởng thành ngày càng tăng của ngành, các vấn đề Bug kỹ thuật ở cấp mã sẽ ngày càng giảm, trong khi "Bug ý thức" trong 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 "rào cản 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 cơ bản của nhiều sự kiện "đổ lỗi" sau khi kiểm toán an ninh vẫn bị tấn công bởi Hacker 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!