Tác giả: Artela blog Trung Quốc, trung bình # Tóm tắt
Các cuộc tấn công vào lại vẫn là một thách thức, các phương pháp phòng thủ hiện tại chủ yếu tập trung vào cấp độ mã nguồn của giao thức, chỉ có hiệu lực trước khi hợp đồng chuyển sang trạng thái thời gian chạy
"Bảo vệ thời gian chạy" là một bổ sung quan trọng cho bảo mật DeFi. Nó nhằm mục đích "bảo vệ kết quả thực thi" và đảm bảo rằng việc thực thi giao thức phù hợp với thiết kế dự kiến của nó
Thiết kế của EVM không hỗ trợ "bảo vệ thời gian chạy", vì hợp đồng thông minh không thể truy cập thông tin ngữ cảnh đầy đủ của trạng thái thời gian chạy
Artela khám phá mô hình lớp thực thi EVM+Extension, tăng cường lớp thực thi để loại bỏ các cuộc tấn công vào lại
Artela triển khai các tiện ích mở rộng "bảo vệ thời gian chạy" trên chuỗi thông qua Lập trình khía cạnh
Chúng tôi trình bày từng bước cách ngăn chặn các cuộc tấn công vào lại hợp đồng Curve thông qua Aspect
Tại sao các cuộc tấn công vào lại vẫn là một thách thức bất chấp các biện pháp kiểm soát rủi ro hiện có
Mặc dù các cuộc tấn công vào lại là một vấn đề nổi tiếng và nhiều biện pháp kiểm soát rủi ro đã được đưa ra, các sự cố bảo mật liên quan đến các cuộc tấn công như vậy vẫn tiếp tục xảy ra trong hai năm qua:
Cuộc tấn công tài chính Curve (tháng 7 năm 2023) — 60 triệu đô la Curve bị tấn công vào lại do lỗi biên dịch trong ngôn ngữ lập trình hợp đồng Vyper.
Cuộc tấn công vào giao thức gốc (tháng 11 năm 2022) — Dự án Stablecoin trị giá 7 triệu đô la Origin Dollar (OUSD) đã bị tấn công vào lại.
Cuộc tấn công Siren Protocol (tháng 9 năm 2021) — 3,5 triệu USD, nhóm AMM bị tấn công vào lại.
Cuộc tấn công Cream Finance (tháng 8 năm 2021) - 18,8 triệu đô la, những kẻ tấn công đã khai thác lỗ hổng tái đăng ký để vay thứ cấp.
Hiện tại, trọng tâm của việc ngăn chặn các cuộc tấn công vào lại là ở cấp mã nguồn của hợp đồng thông minh. Các biện pháp bao gồm tích hợp OpenZeppelin's ReentrancyGuard và tiến hành kiểm tra bảo mật trên mã logic hợp đồng để tránh các rủi ro bảo mật được xác định trước.
Cách tiếp cận này, được gọi là giải pháp "hộp trắng", nhằm mục đích tránh các lỗ hổng ở cấp mã nguồn để giảm thiểu lỗi logic. Tuy nhiên, thách thức chính của nó là không có khả năng phòng thủ trước những mối nguy hiểm tiềm ẩn chưa biết.
"Dịch" hợp đồng từ mã nguồn sang thời gian chạy thực tế là một quá trình đầy thách thức. Mỗi bước có thể mang lại những vấn đề không lường trước được cho các nhà phát triển và bản thân mã nguồn hợp đồng có thể không bao gồm đầy đủ tất cả các tình huống tiềm ẩn. Trong trường hợp của Curve, ngay cả khi mã nguồn giao thức là chính xác, vẫn có thể có sự khác biệt giữa lần chạy cuối cùng và thiết kế dự định của giao thức do các vấn đề về trình biên dịch.
Dựa vào tính bảo mật của giao thức ở cấp độ mã nguồn và biên dịch là chưa đủ. Ngay cả khi mã nguồn có vẻ hoàn hảo, các lỗ hổng vẫn có thể xuất hiện bất ngờ do các vấn đề về trình biên dịch.
Chúng tôi cần bảo vệ thời gian chạy
Không giống như các biện pháp kiểm soát rủi ro hiện có tập trung ở cấp mã nguồn giao thức và có hiệu lực trước khi thực thi, bảo vệ thời gian chạy liên quan đến việc các nhà phát triển giao thức viết các quy tắc và hoạt động bảo vệ thời gian chạy để xử lý các trường hợp không lường trước được trong thời gian chạy. Điều này tạo điều kiện đánh giá thời gian thực và phản hồi kết quả thực thi thời gian chạy.
Bảo vệ thời gian chạy là rất quan trọng trong việc tăng cường bảo mật DeFi và là một bổ sung quan trọng cho các biện pháp bảo mật hiện có. Bằng cách bảo vệ giao thức theo cách "hộp đen", nó tăng cường bảo mật bằng cách đảm bảo rằng kết quả hoạt động cuối cùng phù hợp với thiết kế dự định của giao thức mà không can thiệp trực tiếp vào việc thực thi mã hợp đồng.
Những thách thức khi thực hiện bảo vệ thời gian chạy
Thật không may, thiết kế EVM không hỗ trợ bảo vệ thời gian chạy trên chuỗi vì các hợp đồng thông minh không có quyền truy cập vào bối cảnh thời gian chạy đầy đủ.
Làm thế nào để vượt qua thử thách này? Chúng tôi tin rằng các điều kiện tiên quyết sau đây là cần thiết:
Một mô-đun chuyên dụng cung cấp quyền truy cập vào tất cả thông tin trên các hợp đồng thông minh, bao gồm toàn bộ bối cảnh giao dịch.
Sự ủy quyền cần thiết được lấy từ hợp đồng thông minh, cấp cho mô-đun quyền hoàn nguyên các giao dịch khi cần.
Đảm bảo rằng chức năng của mô-đun có hiệu lực sau khi hợp đồng thông minh được thực thi và trước khi trạng thái được gửi.
EVM hiện đang đối mặt với những hạn chế trong việc giải quyết những thách thức trên và không thể đáp ứng những đổi mới hơn nữa. Theo mô hình chuỗi khối mô-đun, lớp thực thi cần khám phá bước đột phá vượt ra ngoài EVM.
Ý tưởng của Artela là EVM + tiện ích mở rộng gốc, bằng cách xây dựng lớp tiện ích mở rộng gốc WASM của EVM để thực hiện vượt ra ngoài EVM.
Giới thiệu lập trình khía cạnh
Chúng tôi đã ra mắt Lập trình khía cạnh, một khung lập trình cho chuỗi khối Artela hỗ trợ mở rộng quy mô gốc trên chuỗi khối.
Aspect là một mô-đun mở rộng gốc có thể lập trình, được sử dụng để tích hợp động các chức năng tùy chỉnh vào chuỗi khối khi chạy, như một phần bổ sung mô-đun cho các hợp đồng thông minh và nâng cao chức năng trên chuỗi.
Tính năng của Aspect là nó có thể truy cập API cấp hệ thống của lớp cơ sở chuỗi khối và thêm logic mở rộng tại mỗi điểm tham gia của vòng đời giao dịch. Hợp đồng thông minh có thể ràng buộc các khía cạnh cụ thể để kích hoạt các chức năng mở rộng. Khi một giao dịch gọi một hợp đồng thông minh, giao dịch cũng được xử lý bởi khía cạnh liên quan đến hợp đồng.
Cách lập trình khía cạnh thực hiện bảo vệ thời gian chạy
Aspect có thể ghi lại trạng thái thực thi của từng lệnh gọi hàm và ngăn chặn việc truy cập lại trong khi thực hiện chức năng gọi lại. Khi một cuộc gọi truy cập lại xảy ra trong quá trình thực thi chức năng gọi lại, Aspect sẽ phát hiện và khôi phục giao dịch ngay lập tức, ngăn chặn những kẻ tấn công khai thác lỗ hổng truy cập lại. Với cách tiếp cận này, Aspect loại bỏ hiệu quả các cuộc tấn công vào lại, đảm bảo tính bảo mật và ổn định của hợp đồng thông minh.
Aspect thực hiện các thuộc tính quan trọng để bảo vệ thời gian chạy:
Có thể được kích hoạt sau khi thực hiện hợp đồng thông minh và trước khi gửi trạng thái: Các mô-đun Aspect có thể được thiết lập để kích hoạt sau khi thực hiện hợp đồng thông minh nhưng trước khi gửi trạng thái.
Truy cập bối cảnh giao dịch hoàn chỉnh: Aspect có thể truy cập bối cảnh giao dịch hoàn chỉnh, bao gồm toàn bộ thông tin giao dịch (phương thức, tham số, v.v.), ngăn xếp cuộc gọi (tất cả các cuộc gọi hợp đồng nội bộ trong khi thực hiện), thay đổi bối cảnh trạng thái và tất cả các sự kiện kích hoạt giao dịch.
Khả năng gọi hệ thống: Aspect có thể thực hiện các cuộc gọi hệ thống và bắt đầu các giao dịch thoái lui khi cần thiết.
Ràng buộc và ủy quyền với hợp đồng thông minh: Hợp đồng thông minh có thể được ràng buộc với Aspect và cấp quyền cho Aspect tham gia xử lý giao dịch.
Thực hiện khía cạnh để bảo vệ reentrancy
Trong chương này, chúng tôi thảo luận về cách thực hiện bảo vệ thời gian chạy của Aspect trên chuỗi.
Khía cạnh "Ý định bảo vệ hợp đồng" thực tế có thể được triển khai tại điểm nối của "preContractCall" và "postContractCall" để ngăn chặn các cuộc tấn công vào lại.
preContractCall: Được kích hoạt trước khi thực hiện cuộc gọi hợp đồng chéo
postContractCall: được kích hoạt sau khi thực hiện cuộc gọi hợp đồng chéo
Để bảo vệ việc tham gia lại, mục tiêu của chúng tôi là ngăn chặn việc tham gia lại hợp đồng cho đến khi cuộc gọi hoàn tất. Với Aspect, chúng ta có thể đạt được điều này bằng cách thêm logic cụ thể tại các điểm cắt trong vòng đời giao dịch.
Trong điểm cắt "preContractCall", Aspect giám sát ngăn xếp cuộc gọi hợp đồng. Nếu có bất kỳ cuộc gọi trùng lặp nào trong ngăn xếp cuộc gọi (có nghĩa là một lần vào lại không mong muốn trong cuộc gọi bị khóa của chúng tôi), khía cạnh sẽ khôi phục cuộc gọi.
Triển khai hợp đồng Curve và ngăn chặn các cuộc tấn công vào lại
Chúng tôi đã viết một hợp đồng mô phỏng Curve và giả mạo một cuộc tấn công vào lại để tái tạo quy trình này theo cách dễ hiểu hơn. Mã hợp đồng như sau:
Có thể thấy rằng cả add_liquidity và remove_liquidity của hợp đồng trên đều được bảo vệ bởi cùng một khóa khóa vào lại, điều đó có nghĩa là nếu chức năng bảo vệ vào lại hoạt động bình thường thì không thể vào lại chức năng được bảo vệ bằng cách thay đổi khóa (ví dụ: trong xóa _liquidity gọi thêm_liquidity).
Biên dịch hợp đồng trên với trình biên dịch vyper 0.2.15, 0.2.16 hoặc 0.3.0 (các phiên bản này đã biết các vấn đề về bảo vệ vào lại).
Sau đó, chúng tôi triển khai hợp đồng nạn nhân ở trên và tấn công nó bằng hợp đồng sau:
Để mô phỏng một cuộc tấn công thực tế, phương thức tấn công của hợp đồng này cố gắng nhập lại add_liquidity từ phương thức remove_liquidity thông qua chức năng dự phòng của nó. Nếu việc đăng nhập lại thực sự xảy ra, thì có thể quan sát thấy trong biên nhận rằng sự kiện AddLiquidity được ghi lại trước sự kiện RemoveLiquidity.
Bây giờ hãy sử dụng Aspect để bảo vệ hợp đồng trước sự tấn công. Trước khi thực hiện các thao tác sau, vui lòng hoàn thành các bước sau:
Triển khai Khía cạnh
Ràng buộc hợp đồng nạn nhân với Aspect
Nếu bạn không quen với các hoạt động của Aspect, trước tiên bạn có thể xem hướng dẫn dành cho nhà phát triển của chúng tôi.
Sau khi thực hiện xong những điều trên, bây giờ chúng ta hãy thử gọi lại phương thức tấn công để kiểm tra xem hoạt động có thành công hay không.
Từ hình ảnh chuyển động (bạn có thể xem liên kết gốc ở cuối bài viết), chúng ta có thể thấy rằng giao dịch reentrant đã được hoàn nguyên, điều đó có nghĩa là Aspect của chúng ta đang bảo vệ thành công hợp đồng nạn nhân khỏi các cuộc tấn công vào lại.
Tóm lại là
Cuộc tấn công gần đây vào Curve một lần nữa chứng minh rằng không có giao thức nào hoàn toàn an toàn 100%. Tập trung vào bảo mật ở cấp độ mã nguồn và biên dịch của giao thức là chưa đủ. Ngay cả khi mã nguồn có vẻ hoàn hảo, các lỗ hổng vẫn có thể xuất hiện bất ngờ do các vấn đề về trình biên dịch.
Để tăng cường tính bảo mật của DeFi, bảo vệ thời gian chạy trở nên quan trọng. Bằng cách bảo vệ giao thức theo cách "hộp đen", đảm bảo rằng việc thực thi giao thức phù hợp với thiết kế dự định của nó, nó có thể ngăn chặn hiệu quả các cuộc tấn công vào lại trong thời gian chạy.
Chúng tôi đã rẽ nhánh hợp đồng Curve và mô phỏng đầy đủ cuộc tấn công vào lại gần đây của nó, đồng thời tái tạo toàn bộ quá trình theo cách dễ hiểu hơn. Sử dụng lập trình khía cạnh như một cách tiếp cận mới để bảo vệ thời gian chạy trên chuỗi, chúng tôi trình bày từng bước cách bảo vệ hợp đồng nạn nhân với các khía cạnh. Mục tiêu của chúng tôi là giúp loại bỏ tận gốc các cuộc tấn công vào lại mà các giao thức DeFi như Curve có thể mắc phải, từ đó tăng cường bảo mật trên toàn bộ không gian DeFi.
Với Lập trình khía cạnh, các nhà phát triển không chỉ có thể đạt được sự bảo vệ thời gian chạy trên chuỗi trong không gian bảo mật mà còn cho phép các trường hợp sử dụng đổi mới chưa từng có như ý định, JIT và tự động hóa trên chuỗi. Ngoài ra, khung chung dựa trên SDK Cosmos này sẽ không chỉ hỗ trợ chuỗi khối Artela mà còn hỗ trợ các chuỗi khối khác để xây dựng các tiện ích mở rộng gốc dựa trên các lớp thực thi của riêng chúng.
Xem bản gốc
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.
Runtime Protection thực hiện bảo vệ kiểm soát rủi ro trên chuỗi DeFi
Tác giả: Artela blog Trung Quốc, trung bình # Tóm tắt
Các cuộc tấn công vào lại vẫn là một thách thức, các phương pháp phòng thủ hiện tại chủ yếu tập trung vào cấp độ mã nguồn của giao thức, chỉ có hiệu lực trước khi hợp đồng chuyển sang trạng thái thời gian chạy
"Bảo vệ thời gian chạy" là một bổ sung quan trọng cho bảo mật DeFi. Nó nhằm mục đích "bảo vệ kết quả thực thi" và đảm bảo rằng việc thực thi giao thức phù hợp với thiết kế dự kiến của nó
Thiết kế của EVM không hỗ trợ "bảo vệ thời gian chạy", vì hợp đồng thông minh không thể truy cập thông tin ngữ cảnh đầy đủ của trạng thái thời gian chạy
Artela khám phá mô hình lớp thực thi EVM+Extension, tăng cường lớp thực thi để loại bỏ các cuộc tấn công vào lại
Artela triển khai các tiện ích mở rộng "bảo vệ thời gian chạy" trên chuỗi thông qua Lập trình khía cạnh
Chúng tôi trình bày từng bước cách ngăn chặn các cuộc tấn công vào lại hợp đồng Curve thông qua Aspect
Tại sao các cuộc tấn công vào lại vẫn là một thách thức bất chấp các biện pháp kiểm soát rủi ro hiện có
Mặc dù các cuộc tấn công vào lại là một vấn đề nổi tiếng và nhiều biện pháp kiểm soát rủi ro đã được đưa ra, các sự cố bảo mật liên quan đến các cuộc tấn công như vậy vẫn tiếp tục xảy ra trong hai năm qua:
Cuộc tấn công tài chính Curve (tháng 7 năm 2023) — 60 triệu đô la Curve bị tấn công vào lại do lỗi biên dịch trong ngôn ngữ lập trình hợp đồng Vyper.
Cuộc tấn công vào giao thức gốc (tháng 11 năm 2022) — Dự án Stablecoin trị giá 7 triệu đô la Origin Dollar (OUSD) đã bị tấn công vào lại.
Cuộc tấn công Siren Protocol (tháng 9 năm 2021) — 3,5 triệu USD, nhóm AMM bị tấn công vào lại.
Cuộc tấn công Cream Finance (tháng 8 năm 2021) - 18,8 triệu đô la, những kẻ tấn công đã khai thác lỗ hổng tái đăng ký để vay thứ cấp.
Hiện tại, trọng tâm của việc ngăn chặn các cuộc tấn công vào lại là ở cấp mã nguồn của hợp đồng thông minh. Các biện pháp bao gồm tích hợp OpenZeppelin's ReentrancyGuard và tiến hành kiểm tra bảo mật trên mã logic hợp đồng để tránh các rủi ro bảo mật được xác định trước.
Cách tiếp cận này, được gọi là giải pháp "hộp trắng", nhằm mục đích tránh các lỗ hổng ở cấp mã nguồn để giảm thiểu lỗi logic. Tuy nhiên, thách thức chính của nó là không có khả năng phòng thủ trước những mối nguy hiểm tiềm ẩn chưa biết.
"Dịch" hợp đồng từ mã nguồn sang thời gian chạy thực tế là một quá trình đầy thách thức. Mỗi bước có thể mang lại những vấn đề không lường trước được cho các nhà phát triển và bản thân mã nguồn hợp đồng có thể không bao gồm đầy đủ tất cả các tình huống tiềm ẩn. Trong trường hợp của Curve, ngay cả khi mã nguồn giao thức là chính xác, vẫn có thể có sự khác biệt giữa lần chạy cuối cùng và thiết kế dự định của giao thức do các vấn đề về trình biên dịch.
Dựa vào tính bảo mật của giao thức ở cấp độ mã nguồn và biên dịch là chưa đủ. Ngay cả khi mã nguồn có vẻ hoàn hảo, các lỗ hổng vẫn có thể xuất hiện bất ngờ do các vấn đề về trình biên dịch.
Chúng tôi cần bảo vệ thời gian chạy
Không giống như các biện pháp kiểm soát rủi ro hiện có tập trung ở cấp mã nguồn giao thức và có hiệu lực trước khi thực thi, bảo vệ thời gian chạy liên quan đến việc các nhà phát triển giao thức viết các quy tắc và hoạt động bảo vệ thời gian chạy để xử lý các trường hợp không lường trước được trong thời gian chạy. Điều này tạo điều kiện đánh giá thời gian thực và phản hồi kết quả thực thi thời gian chạy.
Bảo vệ thời gian chạy là rất quan trọng trong việc tăng cường bảo mật DeFi và là một bổ sung quan trọng cho các biện pháp bảo mật hiện có. Bằng cách bảo vệ giao thức theo cách "hộp đen", nó tăng cường bảo mật bằng cách đảm bảo rằng kết quả hoạt động cuối cùng phù hợp với thiết kế dự định của giao thức mà không can thiệp trực tiếp vào việc thực thi mã hợp đồng.
Những thách thức khi thực hiện bảo vệ thời gian chạy
Thật không may, thiết kế EVM không hỗ trợ bảo vệ thời gian chạy trên chuỗi vì các hợp đồng thông minh không có quyền truy cập vào bối cảnh thời gian chạy đầy đủ.
Làm thế nào để vượt qua thử thách này? Chúng tôi tin rằng các điều kiện tiên quyết sau đây là cần thiết:
Một mô-đun chuyên dụng cung cấp quyền truy cập vào tất cả thông tin trên các hợp đồng thông minh, bao gồm toàn bộ bối cảnh giao dịch.
Sự ủy quyền cần thiết được lấy từ hợp đồng thông minh, cấp cho mô-đun quyền hoàn nguyên các giao dịch khi cần.
Đảm bảo rằng chức năng của mô-đun có hiệu lực sau khi hợp đồng thông minh được thực thi và trước khi trạng thái được gửi.
EVM hiện đang đối mặt với những hạn chế trong việc giải quyết những thách thức trên và không thể đáp ứng những đổi mới hơn nữa. Theo mô hình chuỗi khối mô-đun, lớp thực thi cần khám phá bước đột phá vượt ra ngoài EVM.
Ý tưởng của Artela là EVM + tiện ích mở rộng gốc, bằng cách xây dựng lớp tiện ích mở rộng gốc WASM của EVM để thực hiện vượt ra ngoài EVM.
Giới thiệu lập trình khía cạnh
Chúng tôi đã ra mắt Lập trình khía cạnh, một khung lập trình cho chuỗi khối Artela hỗ trợ mở rộng quy mô gốc trên chuỗi khối.
Aspect là một mô-đun mở rộng gốc có thể lập trình, được sử dụng để tích hợp động các chức năng tùy chỉnh vào chuỗi khối khi chạy, như một phần bổ sung mô-đun cho các hợp đồng thông minh và nâng cao chức năng trên chuỗi.
Tính năng của Aspect là nó có thể truy cập API cấp hệ thống của lớp cơ sở chuỗi khối và thêm logic mở rộng tại mỗi điểm tham gia của vòng đời giao dịch. Hợp đồng thông minh có thể ràng buộc các khía cạnh cụ thể để kích hoạt các chức năng mở rộng. Khi một giao dịch gọi một hợp đồng thông minh, giao dịch cũng được xử lý bởi khía cạnh liên quan đến hợp đồng.
Cách lập trình khía cạnh thực hiện bảo vệ thời gian chạy
Aspect có thể ghi lại trạng thái thực thi của từng lệnh gọi hàm và ngăn chặn việc truy cập lại trong khi thực hiện chức năng gọi lại. Khi một cuộc gọi truy cập lại xảy ra trong quá trình thực thi chức năng gọi lại, Aspect sẽ phát hiện và khôi phục giao dịch ngay lập tức, ngăn chặn những kẻ tấn công khai thác lỗ hổng truy cập lại. Với cách tiếp cận này, Aspect loại bỏ hiệu quả các cuộc tấn công vào lại, đảm bảo tính bảo mật và ổn định của hợp đồng thông minh.
Aspect thực hiện các thuộc tính quan trọng để bảo vệ thời gian chạy:
Có thể được kích hoạt sau khi thực hiện hợp đồng thông minh và trước khi gửi trạng thái: Các mô-đun Aspect có thể được thiết lập để kích hoạt sau khi thực hiện hợp đồng thông minh nhưng trước khi gửi trạng thái.
Truy cập bối cảnh giao dịch hoàn chỉnh: Aspect có thể truy cập bối cảnh giao dịch hoàn chỉnh, bao gồm toàn bộ thông tin giao dịch (phương thức, tham số, v.v.), ngăn xếp cuộc gọi (tất cả các cuộc gọi hợp đồng nội bộ trong khi thực hiện), thay đổi bối cảnh trạng thái và tất cả các sự kiện kích hoạt giao dịch.
Khả năng gọi hệ thống: Aspect có thể thực hiện các cuộc gọi hệ thống và bắt đầu các giao dịch thoái lui khi cần thiết.
Ràng buộc và ủy quyền với hợp đồng thông minh: Hợp đồng thông minh có thể được ràng buộc với Aspect và cấp quyền cho Aspect tham gia xử lý giao dịch.
Thực hiện khía cạnh để bảo vệ reentrancy
Trong chương này, chúng tôi thảo luận về cách thực hiện bảo vệ thời gian chạy của Aspect trên chuỗi.
Khía cạnh "Ý định bảo vệ hợp đồng" thực tế có thể được triển khai tại điểm nối của "preContractCall" và "postContractCall" để ngăn chặn các cuộc tấn công vào lại.
preContractCall: Được kích hoạt trước khi thực hiện cuộc gọi hợp đồng chéo
postContractCall: được kích hoạt sau khi thực hiện cuộc gọi hợp đồng chéo
Để bảo vệ việc tham gia lại, mục tiêu của chúng tôi là ngăn chặn việc tham gia lại hợp đồng cho đến khi cuộc gọi hoàn tất. Với Aspect, chúng ta có thể đạt được điều này bằng cách thêm logic cụ thể tại các điểm cắt trong vòng đời giao dịch.
Trong điểm cắt "preContractCall", Aspect giám sát ngăn xếp cuộc gọi hợp đồng. Nếu có bất kỳ cuộc gọi trùng lặp nào trong ngăn xếp cuộc gọi (có nghĩa là một lần vào lại không mong muốn trong cuộc gọi bị khóa của chúng tôi), khía cạnh sẽ khôi phục cuộc gọi.
Triển khai hợp đồng Curve và ngăn chặn các cuộc tấn công vào lại
Chúng tôi đã viết một hợp đồng mô phỏng Curve và giả mạo một cuộc tấn công vào lại để tái tạo quy trình này theo cách dễ hiểu hơn. Mã hợp đồng như sau:
Có thể thấy rằng cả add_liquidity và remove_liquidity của hợp đồng trên đều được bảo vệ bởi cùng một khóa khóa vào lại, điều đó có nghĩa là nếu chức năng bảo vệ vào lại hoạt động bình thường thì không thể vào lại chức năng được bảo vệ bằng cách thay đổi khóa (ví dụ: trong xóa _liquidity gọi thêm_liquidity).
Biên dịch hợp đồng trên với trình biên dịch vyper 0.2.15, 0.2.16 hoặc 0.3.0 (các phiên bản này đã biết các vấn đề về bảo vệ vào lại).
Sau đó, chúng tôi triển khai hợp đồng nạn nhân ở trên và tấn công nó bằng hợp đồng sau:
Để mô phỏng một cuộc tấn công thực tế, phương thức tấn công của hợp đồng này cố gắng nhập lại add_liquidity từ phương thức remove_liquidity thông qua chức năng dự phòng của nó. Nếu việc đăng nhập lại thực sự xảy ra, thì có thể quan sát thấy trong biên nhận rằng sự kiện AddLiquidity được ghi lại trước sự kiện RemoveLiquidity.
Bây giờ hãy sử dụng Aspect để bảo vệ hợp đồng trước sự tấn công. Trước khi thực hiện các thao tác sau, vui lòng hoàn thành các bước sau:
Triển khai Khía cạnh
Ràng buộc hợp đồng nạn nhân với Aspect
Nếu bạn không quen với các hoạt động của Aspect, trước tiên bạn có thể xem hướng dẫn dành cho nhà phát triển của chúng tôi.
Sau khi thực hiện xong những điều trên, bây giờ chúng ta hãy thử gọi lại phương thức tấn công để kiểm tra xem hoạt động có thành công hay không.
Từ hình ảnh chuyển động (bạn có thể xem liên kết gốc ở cuối bài viết), chúng ta có thể thấy rằng giao dịch reentrant đã được hoàn nguyên, điều đó có nghĩa là Aspect của chúng ta đang bảo vệ thành công hợp đồng nạn nhân khỏi các cuộc tấn công vào lại.
Tóm lại là
Cuộc tấn công gần đây vào Curve một lần nữa chứng minh rằng không có giao thức nào hoàn toàn an toàn 100%. Tập trung vào bảo mật ở cấp độ mã nguồn và biên dịch của giao thức là chưa đủ. Ngay cả khi mã nguồn có vẻ hoàn hảo, các lỗ hổng vẫn có thể xuất hiện bất ngờ do các vấn đề về trình biên dịch.
Để tăng cường tính bảo mật của DeFi, bảo vệ thời gian chạy trở nên quan trọng. Bằng cách bảo vệ giao thức theo cách "hộp đen", đảm bảo rằng việc thực thi giao thức phù hợp với thiết kế dự định của nó, nó có thể ngăn chặn hiệu quả các cuộc tấn công vào lại trong thời gian chạy.
Chúng tôi đã rẽ nhánh hợp đồng Curve và mô phỏng đầy đủ cuộc tấn công vào lại gần đây của nó, đồng thời tái tạo toàn bộ quá trình theo cách dễ hiểu hơn. Sử dụng lập trình khía cạnh như một cách tiếp cận mới để bảo vệ thời gian chạy trên chuỗi, chúng tôi trình bày từng bước cách bảo vệ hợp đồng nạn nhân với các khía cạnh. Mục tiêu của chúng tôi là giúp loại bỏ tận gốc các cuộc tấn công vào lại mà các giao thức DeFi như Curve có thể mắc phải, từ đó tăng cường bảo mật trên toàn bộ không gian DeFi.
Với Lập trình khía cạnh, các nhà phát triển không chỉ có thể đạt được sự bảo vệ thời gian chạy trên chuỗi trong không gian bảo mật mà còn cho phép các trường hợp sử dụng đổi mới chưa từng có như ý định, JIT và tự động hóa trên chuỗi. Ngoài ra, khung chung dựa trên SDK Cosmos này sẽ không chỉ hỗ trợ chuỗi khối Artela mà còn hỗ trợ các chuỗi khối khác để xây dựng các tiện ích mở rộng gốc dựa trên các lớp thực thi của riêng chúng.