Tóm tắt Chainfeeds:
Chúng ta phải sử dụng các công cụ tương tự như kẻ tấn công, tiến hành các bài kiểm tra tấn công (red teaming) trên giao thức, liên tục giám sát nó và đặt ra các giới hạn nghiêm ngặt đối với các tổn thất tiềm tàng để có thể sống sót trong trường hợp xấu nhất.
Nguồn bài viết:
https://x.com/systematicls/status/2048756004972855667
Tác giả bài viết:
sysls
Quan điểm :
sysls: Khi đã xác định được các bất biến, hãy nâng chúng lên thành các kiểm tra thời gian chạy. Cân nhắc kỹ xem bất biến nào thực sự có thể thực thi được. Đây là mô hình FREI-PI (Yêu cầu chức năng, Tác động, Tương tác, Bất biến giao thức): ở cuối mỗi hàm liên quan đến giá trị, hãy xác minh lại các bất biến cốt lõi mà hàm đó cam kết duy trì. Nhiều cuộc tấn công có thể vượt qua CEI (Kiểm tra-Tác động-Tương tác) (chẳng hạn như các cuộc tấn công gọng kìm Khoản vay nhanh, các cuộc tấn công thanh lý có sự hỗ trợ oracle và rút cạn khả năng thanh toán giữa các chức năng) bị phát hiện trong các kiểm tra bất biến ở cuối hàm. Kỹ thuật fuzzing có trạng thái xây dựng một chuỗi các lệnh gọi ngẫu nhiên trên toàn bộ giao diện công khai của giao thức và khẳng định các bất biến ở mỗi bước. Hầu hết các cuộc tấn công trong hoàn cảnh sản xuất đều là đa giao dịch, và fuzzing có trạng thái gần như là phương pháp đáng tin cậy duy nhất để phát hiện ra các đường dẫn này trước khi kẻ tấn công. Sử dụng kiểm thử bất biến, hãy xác minh rằng một thuộc tính đúng với bất kỳ chuỗi lệnh gọi nào được tạo ra bởi fuzzing. Kết hợp với xác minh hình thức, nó có thể chứng minh rằng thuộc tính đó đúng trong tất cả các trạng thái có thể đạt được. Các bất biến cốt lõi của bạn tuyệt đối cần được xác minh ở cấp độ này. Sự phức tạp là kẻ thù của bảo mật. Mỗi sự phụ thuộc bên ngoài đều mở rộng bề mặt tấn công. Nếu bạn đang thiết kế cơ sở hạ tầng, bạn nên để người dùng tự lựa chọn "ai đáng tin cậy". Nếu không thể loại bỏ các phụ thuộc, hãy đa dạng hóa chúng để ngăn chặn các điểm lỗi đơn lẻ phá hủy giao thức. Mở rộng phạm vi kiểm toán của bạn để mô phỏng cách các phụ thuộc này có thể gặp lỗi và giới hạn mức độ thiệt hại tối đa mà chúng có thể gây ra. Vụ tấn công KelpDAO gần đây là một ví dụ: chúng kế thừa cấu hình mặc định của LayerZero yêu cầu DVNCount=1, tồn tại bên ngoài phạm vi kiểm toán . Cuối cùng, cơ sở hạ tầng Chuỗi nằm ngoài phạm vi kiểm toán đã bị xâm phạm. Hầu hết các bề mặt tấn công trong DeFi đã được liệt kê. Kiểm tra từng loại một, tự hỏi liệu nó có áp dụng cho giao thức của bạn hay không và triển khai các biện pháp kiểm soát tương ứng. Xây dựng khả năng nhóm đỏ, cho phép tác nhân AI của bạn chủ động tìm ra các lỗ hổng trong giao thức — đây đã là một yêu cầu cơ bản ở giai đoạn này. Trong quản trị dựa trên bỏ phiếu, quyền lực ban đầu tập trung vào chữ ký đa chữ ký đội ngũ và cần thời gian để phân phối. Ngay cả với việc phân phối token rộng rãi, việc ủy quyền thường tập trung vào một vài ví (đôi khi thậm chí chỉ một ví). Một khi những tài khoản này bị xâm phạm, mọi chuyện sẽ kết thúc. Hãy triển khai "ví giám sát" với quyền hạn bị giới hạn nghiêm ngặt: chúng chỉ có thể tạm dừng giao thức và, trong trường hợp cực đoan (≥4/7), thay thế các ủy quyền bị xâm phạm bằng các ví được xác định trước. Ví giám sát không bao giờ có thể thực thi Đề án quản trị. Điều này cung cấp một lớp cứu hộ có thể khôi phục sự ổn định của hệ thống mà không làm đảo lộn quản trị. Lớp này có thể được loại bỏ dần khi quản trị trưởng thành và trở nên phi tập trung hơn.
Nguồn nội dung 
