Hôm nay, chúng tôi đã phối hợp chặt chẽ với @blockaid_ để điều tra vụ tấn công lỗ hổng bảo mật xảy ra đêm qua nhắm vào giao thức @humafinance v1. Báo cáo phân tích sự cố của Blockaid rất chi tiết (liên kết trong phản hồi đầu tiên), vì vậy chúng tôi sẽ không nhắc lại ở đây. Dưới đây là tóm tắt sự kiện và những bài học chúng tôi rút ra về kiến ​​trúc và vận hành hệ thống. 👇 Tóm lại Sự cố tấn công: Kẻ tấn công đã phát hiện ra một lỗ hổng trong hợp đồng thông minh và đánh cắp khoảng 101.000 đô la phí giao thức và phí chủ sở hữu nhóm từ ba nhóm v1 cũ trên Polygon . Tiền của người dùng: Tiền của người dùng không bị ảnh hưởng dưới bất kỳ hình thức nào. Phân lập rủi ro: Vấn đề nằm ở hợp đồng Huma EVM v1. Nó hoàn toàn không liên quan đến PST và tất cả các hợp đồng thông minh Huma trên Solana . Hợp đồng Solana : Chương trình trên Solana sử dụng kiến ​​trúc được thiết kế lại hoàn toàn và không bao gồm logic bị lỗi lần. Tình trạng hiện tại: Tất cả các nhóm thanh khoản v1 đều bị tạm ngừng hoạt động. Bài học kinh nghiệm chính: Nhìn lên nhìn, đây có vẻ là một lỗ hổng bảo mật trong hợp đồng thông minh ở phiên bản 1, ra mắt năm 2023, nhưng nó làm nổi bật một số vấn đề trong thiết kế và vận hành giao thức: 1. Tránh trộn lẫn các chuyển đổi trạng thái quan trọng trong các hàm có logic phức tạp. Các hàm `_updateDueInfo()` và `_getDueInfo()`, dùng để tính toán số tiền đến hạn và các khoản phí khác nhau, là những phần phức tạp nhất của hợp đồng v1. Việc nhúng các chuyển đổi trạng thái của người vay vào trong các hàm phức tạp này không phải là một lựa chọn khôn ngoan. Sau đó, chúng tôi không hài lòng với thiết kế này và đã từ bỏ nó trong thiết kế hợp đồng thông minh Huma v2, thay vào đó áp dụng một kiến ​​trúc đơn giản hơn. 2. Loại bỏ các tính năng không cần thiết. Chức năng `requestCredit()` được giới thiệu để hỗ trợ mở rộng trong tương lai, nhưng nó chưa bao giờ được sử dụng trong hoạt động thực tế. Các chức năng không quan trọng thường nhận được ít sự kiểm tra và đánh giá bảo mật hơn, do đó tạo ra một bề mặt tấn công không cần thiết. Chúng tôi đã thảo luận về việc loại bỏ nó trước khi phát hành, nhưng vào thời điểm đó, cho rằng nó sẽ không gây ra bất kỳ vấn đề lớn nào và đã giữ lại. Nếu một chức năng không thiết yếu, nó không nên được đưa vào hợp đồng. 3. Chủ động đóng cửa các pool không sử dụng. Việc giữ lại các pool cũ không còn cần thiết sẽ tạo ra rủi ro không cần thiết. Hiện nay, cả nhà phát triển và tin tặc đều đang tích cực sử dụng trí tuệ nhân tạo (AI), và một số hợp đồng cũ, chưa được AI kiểm toán, có thể có nhiều lỗ hổng hơn. Công việc đóng cửa pool thanh khoản v1 đã được tiến hành, nhưng chưa được ưu tiên hàng đầu; chúng ta cần quyết đoán hơn trong vấn đề này. Đây là một bài học đau đớn. Chúng ta nên rút kinh nghiệm từ nó và không để lãng phí cái giá đắt đỏ này. Tại đây, chúng tôi chia sẻ những suy nghĩ ban đầu và bài học kinh nghiệm, với hy vọng giúp các nhà xây dựng hệ sinh thái khác, đặc biệt là các dự án có hợp đồng cũ, nâng cao hiệu quả phòng thủ trước hacker. DeFi đoàn kết, DeFi vững mạnh! 🛡️