Độ sâu phân tích tình huống khó khăn của Safe: Liệu Guard có thể xây dựng lại tháp Babel hợp đồng?
Vào ngày 21 tháng 2 năm 2025, ngành công nghiệp tiền điện tử đã trải qua cuộc khủng hoảng quản lý tài sản nghiêm trọng nhất trong lịch sử. Ví đa ký trên chuỗi của một nền tảng giao dịch đã bị tấn công có chủ đích, gần 1,5 tỷ đô la tài sản đã âm thầm bị mất thông qua một giao dịch "chữ ký hợp pháp". Phân tích trên chuỗi sau đó cho thấy, kẻ tấn công đã thu được quyền đa ký thông qua một cuộc tấn công kỹ thuật xã hội tinh vi, sử dụng tính năng deleGatecall của hợp đồng Safe để nhúng logic độc hại, cuối cùng vượt qua cơ chế xác thực đa chữ ký, chuyển tiền đến địa chỉ ẩn danh.
Sự kiện này đã phơi bày một thực tế tàn khốc: "Chữ ký đa dạng" không đồng nghĩa với "an toàn tuyệt đối", ngay cả với cơ chế an toàn như ví đa chữ ký Safe, nếu thiếu các biện pháp bảo vệ bổ sung, vẫn có nguy cơ bị tấn công. Đây cũng không phải là trường hợp đầu tiên bị tấn công nhằm vào ví đa chữ ký Safe. Năm ngoái, hai nền tảng đã chịu thiệt hại lần lượt 230 triệu USD và 50 triệu USD, đều gặp phải các phương pháp tấn công tương tự. Các sự kiện tấn công vào ví đa chữ ký Safe cho thấy sự tương đồng kỹ thuật sau đây:
Lệ thuộc quá mức vào cơ chế chữ ký: Giao toàn bộ trách nhiệm bảo mật cho việc lưu trữ khóa riêng.
Thiếu phòng thủ động: Thiếu quét rủi ro thời gian thực trước khi thực hiện giao dịch.
Kiểm soát quyền hạn thô: Chưa thiết lập cơ chế danh sách trắng cho các thao tác rủi ro cao như deleGatecall.
Vấn đề cốt lõi của chuỗi sự kiện này không nằm ở bản hợp đồng Safe mà nằm ở những rủi ro an ninh trong quá trình tích hợp của toàn bộ hệ thống, đặc biệt là ở giai đoạn xác thực phía trước. Điều này khiến chúng ta cần suy nghĩ: Làm thế nào để tăng cường khả năng bảo vệ của ví đa chữ ký thông qua cơ chế biện pháp an toàn bổ sung của Safe?
An toàn
Safe là một ví Multi-Sig ( đa chữ ký, chủ yếu được sử dụng để quản lý tài sản có giá trị cao và lưu trữ, chuyển giao tiền điện tử một cách an toàn. Là cơ sở hạ tầng cho quản lý tài sản phi tập trung, nó đảm bảo an toàn cho các giao dịch quỹ thông qua cơ chế xác thực hợp tác nhiều bên, ngăn chặn các quản trị viên đơn lẻ hoặc hacker lợi dụng điểm lỗi đơn để thực hiện các thao tác ác ý, được ứng dụng rộng rãi trong quản trị DAO, ủy thác quỹ doanh nghiệp, quỹ phi tập trung và các tình huống khác. Hợp đồng này được đội ngũ Safe phát triển, là giải pháp quản lý tài sản trên chuỗi theo tiêu chuẩn ngành hiện tại. Hợp đồng áp dụng tiêu chuẩn EIP-712 để thực hiện chữ ký dữ liệu có cấu trúc, do đó nâng cao tính bảo mật và khả năng xác minh của dữ liệu giao dịch.
) Ứng dụng cốt lõi
Quản lý an toàn vốn: Hợp đồng yêu cầu nhiều chủ sở hữu đã được thiết lập trước ###Owners( cùng xác nhận giao dịch trước khi thực hiện, từ đó hiệu quả ngăn chặn sai sót điểm đơn hoặc hành vi độc hại, đảm bảo an toàn vốn.
Thực hiện và quản lý giao dịch: Thông qua cơ chế xác thực đa chữ ký được tích hợp sẵn, hợp đồng có thể thực hiện việc chuyển tiền ra bên ngoài, gọi các hợp đồng khác hoặc xử lý các logic kinh doanh phức tạp khi đáp ứng điều kiện ngưỡng chữ ký, hỗ trợ thanh toán và bồi thường phí bằng token và đồng tiền gốc.
Mở rộng mô-đun: Hợp đồng áp dụng thiết kế mô-đun, thông qua việc kế thừa và kết hợp nhiều mô-đun quản lý (như OwnerManager, ModuleManager, GuardManager, FallbackManager, v.v.), làm cho chức năng của nó linh hoạt và dễ mở rộng, cung cấp hỗ trợ tùy chỉnh cho các tình huống ứng dụng khác nhau.
) Phân tích hàm
Hàm execTransaction thực hiện giao dịch đã được xác thực qua chữ ký đa tầng:
Tính toán giá trị băm duy nhất của giao dịch (kết hợp các tham số giao dịch, nonce, v.v.);
Xác minh tính hợp lệ của tất cả các chữ ký, đảm bảo mỗi chữ ký đều đến từ chủ sở hữu hợp pháp hoặc địa chỉ đã được phê duyệt trước;
Gọi logic nghiệp vụ của địa chỉ mục tiêu, và ghi lại trạng thái thành công hoặc thất bại thông qua sự kiện sau khi thực hiện giao dịch;
Hỗ trợ xử lý phí gas linh hoạt, đảm bảo tính toán chính xác chi phí giao dịch khi thanh toán bồi thường.
Hàm checkContractSignatures & checkNSignatures xác thực dữ liệu chữ ký của giao dịch hoặc tin nhắn:
Xử lý riêng biệt chữ ký tài khoản EOA, chữ ký hợp đồng ###EIP-1271(, và băm đã được phê duyệt trước;
Đảm bảo chữ ký được sắp xếp theo thứ tự của chủ sở hữu và mỗi chữ ký đều đến từ địa chỉ hợp lệ, ngăn chặn các cuộc tấn công phát lại và sự giả mạo chữ ký.
Hàm getTransactionHash tạo ra băm giao dịch, được sử dụng để xác minh chữ ký và ngăn chặn các cuộc tấn công phát lại:
Sử dụng tiêu chuẩn EIP-712 để thực hiện băm có cấu trúc cho dữ liệu giao dịch;
Sử dụng lắp ráp nội tuyến để tối ưu hóa thao tác bộ nhớ, nâng cao hiệu suất tính toán;
Kết hợp với giá trị nonce hiện tại, đảm bảo tính duy nhất cho mỗi giao dịch.
Hàm handlePayment xử lý việc thanh toán bồi thường gas trong quá trình thực hiện giao dịch:
Tính toán số tiền thanh toán dựa trên chi phí gas thực tế đã tiêu thụ và chi phí cơ bản;
Hỗ trợ thanh toán bằng ETH và các token khác, đảm bảo bồi thường phí chính xác.
onBeforeExecTransaction là hàm hook ảo nội bộ, được gọi trước khi hàm execTransaction được thực thi. Mục đích thiết kế của hàm này là cho phép các hợp đồng con kế thừa hợp đồng Safe thực hiện xử lý logic tùy chỉnh trước khi giao dịch được thực thi. Tập hợp các tham số nhận bao gồm:
đến：Địa chỉ mục tiêu - Địa chỉ hợp đồng hoặc tài khoản mà giao dịch sẽ gọi
giá trị：Số lượng Ether gửi theo giao dịch
data：Dữ liệu tải - Bao gồm dữ liệu gọi chức năng và tham số.
operation：Loại thao tác - Xác định là CALL hay DELEGateCALL
safeTxGas：Giới hạn gas giao dịch - Số lượng gas dự trữ cho việc thực hiện giao dịch
baseGas：gas cơ bản - chi phí gas độc lập với việc thực hiện giao dịch
gasPrice：giá gas - dùng để tính toán phí giao dịch bồi thường giá gas
gasToken：địa chỉ token gas - token dùng để thanh toán phí giao dịch
refundReceiver：Người nhận hoàn tiền - Địa chỉ nhận bồi thường phí giao dịch
signatures：Tập hợp chữ ký - Dữ liệu chữ ký của người sở hữu giao dịch
Mặc dù hợp đồng ví đa ký với thiết kế an toàn nghiêm ngặt và cấu trúc mô-đun linh hoạt cung cấp giải pháp hiệu quả và an toàn cho quản lý tài sản kỹ thuật số, thực hiện kiểm soát an toàn toàn bộ quy trình từ khởi tạo giao dịch đến thực hiện cuối cùng, và trở thành công cụ quan trọng trong quản lý an toàn blockchain, nhưng cũng cần lưu ý rằng nạn nhân chủ yếu dựa vào ví phần cứng để ký, trong khi một số thiết bị phần cứng có hiệu suất hiển thị kém đối với dữ liệu có cấu trúc, dễ dẫn đến việc người dùng không thể nhận diện chính xác dữ liệu giao dịch trong thời gian ngắn, từ đó có nguy cơ "ký mù". Đối với hiện tượng này, ngoài việc tối ưu hóa phần cứng và hiệu quả hiển thị dữ liệu của nó, còn có thể khám phá việc tăng cường xác nhận đa lớp, gợi ý thông minh và công cụ xác thực chữ ký để giảm thiểu thêm rủi ro an toàn do ký mù gây ra.
![Độ sâu phân tích Safe khó khăn: Guard có thể tái cấu trúc Tháp Babel hợp đồng?])https://img-cdn.gateio.im/webp-social/moments-e4f0b0daf2f48ba716dc7fdddcfdabec.webp(
Bảo vệ an toàn
Tính năng bảo mật quan trọng được giới thiệu trong phiên bản 1.3.0 của hợp đồng Safe - cơ chế Safe Guard. Cơ chế này nhằm cung cấp các điều kiện hạn chế bổ sung cho các kế hoạch đa chữ ký n-out-of-m tiêu chuẩn, tăng cường hơn nữa tính bảo mật của giao dịch. Giá trị cốt lõi của Safe Guard nằm ở khả năng thực hiện kiểm tra bảo mật ở các giai đoạn khác nhau của việc thực hiện giao dịch:
Kiểm tra trước giao dịch )checkTransaction(: Cơ chế Guard có thể thực hiện kiểm tra lập trình trên tất cả các tham số giao dịch trước khi thực hiện giao dịch, đảm bảo rằng giao dịch phù hợp với các quy tắc an toàn đã được thiết lập.
Kiểm tra )checkAfterExecution( sau giao dịch: Sau khi giao dịch được thực hiện xong, Guard sẽ thực hiện thêm xác minh an toàn, kiểm tra xem trạng thái cuối cùng của ví Safe sau khi thực hiện giao dịch có đúng như mong đợi hay không.
) Phân tích kiến trúc
Trong Safe, giao dịch đa chữ ký thường được thực hiện thông qua hàm execTransaction. Khi Safe Guard được kích hoạt, khi người dùng thực hiện giao dịch đa chữ ký, hợp đồng Safe sẽ gọi hàm checkTransaction của hợp đồng Guard để thực hiện kiểm tra trước giao dịch, và khi giao dịch đa chữ ký hoàn thành, hợp đồng Safe sẽ gọi hàm checkAfterExecution của hợp đồng Guard để kiểm tra kết quả thực hiện giao dịch.
Khi hợp đồng Safe thực hiện kiểm tra trước giao dịch đa chữ ký thông qua cơ chế Guard, hàm checkTransaction của nó sẽ nhận dữ liệu ngữ cảnh giao dịch đầy đủ, bao gồm địa chỉ hợp đồng mục tiêu, phương thức gọi, dữ liệu thực thi (như deleGatecall), thông tin chữ ký của chủ sở hữu, cấu hình Gas và thông tin thanh toán. Cơ chế này cho phép các nhà phát triển thực hiện các chiến lược quản lý rủi ro đa chiều, chẳng hạn như kiểm soát danh sách trắng hợp đồng (giới hạn địa chỉ có thể tương tác), quản lý quyền cấp độ hàm (vô hiệu hóa bộ chọn hàm nguy hiểm), giới hạn tần suất giao dịch và các quy tắc động dựa trên dòng tiền. Bằng cách cấu hình hợp lý các chiến lược Guard, có thể hiệu quả ngăn chặn kẻ tấn công lợi dụng các lớp không phải hợp đồng để tấn công.
Trong bối cảnh liên tục xuất hiện các sự kiện an ninh gần đây, sự quan tâm đến tính an toàn của hợp đồng ví đa chữ ký ngày càng gia tăng từ nhiều phía. Các nhà cung cấp ví phần cứng đều kêu gọi tăng cường khả năng phân tích và bảo vệ của hợp đồng Safe, nhằm ngăn ngừa việc xảy ra các rủi ro tương tự. Sau sự kiện trên một nền tảng giao dịch, nhiều dự án bắt đầu tập trung vào hợp đồng Safe và khám phá các giải pháp nâng cấp và mở rộng dựa trên cơ chế Guard. Trong đó, không ít ứng dụng đổi mới dựa trên cơ chế Guard được phát triển, xây dựng một giải pháp an ninh lớp trung gian dựa trên ví đa chữ ký Safe, cung cấp bảo vệ an toàn bổ sung giữa tài sản cơ sở và tài sản người dùng. Vai trò cốt lõi của nó là thông qua việc truyền vào hàm checkTransaction các hợp đồng mục tiêu, cách gọi, dữ liệu thực thi, thông tin chữ ký owner, thông tin thanh toán và thông tin gas liên quan đến giao dịch đa chữ ký Safe, để thực hiện kiểm tra giao dịch với độ chi tiết cực cao, bao gồm kiểm soát quyền truy cập như gọi hợp đồng trong danh sách trắng, thao tác hàm trong danh sách trắng, mục tiêu chuyển tiền trong danh sách trắng, tần suất giao dịch, v.v.
Điều đáng lưu ý là Safe chỉ cung cấp chức năng quản lý Guard và callback, logic kiểm tra giao dịch đa chữ ký thực tế do người dùng tự thực hiện, và mức độ an toàn phụ thuộc vào chất lượng của việc thực hiện Guard. Một số giải pháp đã mở rộng ý tưởng này, cấu hình một Guardian chuyên biệt cho mỗi Vault để chỉ định địa chỉ mục tiêu và quyền hoạt động được phép, thực hiện ba yếu tố kiểm soát quyền chính: chỉ định hợp đồng được phép, định nghĩa các chức năng được phép thực hiện và yêu cầu xác minh ACL. Đồng thời, áp dụng cơ chế quản trị tách biệt, Vault Guardian chịu trách nhiệm thực hiện, trong khi Governor kiểm soát quyền quản trị, đảm bảo ngay cả khi Guardian gặp sự cố, cũng có thể kịp thời thực hiện các biện pháp khắc phục để bảo vệ tài sản của người dùng. Ý tưởng thiết kế tương tự cũng đã được áp dụng trong các mô-đun an toàn của các dự án khác, thông qua việc chặn các hoạt động then chốt, và nhờ cơ chế danh sách trắng để kiểm soát chặt chẽ các hoạt động rủi ro cao như cài đặt mô-đun, thiết lập hook và quản lý bộ xác minh, từ đó đảm bảo rằng chỉ những hợp đồng đã được tin tưởng mới có thể được thêm vào hệ thống, cung cấp sự bảo vệ an toàn bền vững cho ví.
Trong chuỗi tấn công sự kiện trên một nền tảng giao dịch, nếu hợp đồng Safe triển khai cơ chế Guard được cấu hình hợp lý, kẻ tấn công thông qua execTransaction phát động cuộc gọi deleGatecall độc hại sẽ bị chặn bởi nhiều chính sách trong giai đoạn kiểm tra trước: hàm checkTransaction của Guard đầu tiên nhận diện loại thao tác deleGatecall và kích hoạt quy tắc vô hiệu hóa (ví dụ, buộc giới hạn operation chỉ là gọi thông thường), sau đó phân tích trường data phát hiện địa chỉ hợp đồng bất thường và bộ chọn hàm nguy hiểm, thông qua danh sách trắng hợp đồng và chính sách danh sách đen hàm đã được thiết lập, giao dịch sẽ bị hoàn tác ngay lập tức, cuối cùng hình thành hệ thống phòng thủ "chặn chính sách → chặn logic", hoàn toàn ngăn chặn việc chỉnh sửa lưu trữ và chuyển tiền.
![Độ sâu phân tích Safe khó khăn: Guard có thể tái cấu trúc tháp Babel hợp đồng không?]###https://img-cdn.gateio.im/webp-social/moments-4947f64f2aa4163ee644b6f8e911c6f8.webp(
Tóm lại, Safe chỉ cung cấp chức năng Guard sau phiên bản 1.3.0, mặc dù Guard có thể cung cấp kiểm tra giao dịch đa ký với độ chi tiết rất cao, nhưng người dùng có một ngưỡng khá lớn khi sử dụng chức năng Guard. Họ cần tự triển khai logic kiểm tra Guard, việc triển khai Guard thô sơ hoặc có khuyết điểm có thể không giúp người dùng nâng cao độ an toàn của ví Safe của họ, do đó việc thực hiện kiểm toán an ninh cho việc triển khai Guard là cần thiết. Không có gì phải nghi ngờ rằng, việc triển khai Guard an toàn và thích hợp có thể nâng cao đáng kể độ an toàn của ví Safe.
Kết luận và triển vọng
Một sự kiện tấn công nền tảng giao dịch đã làm nổi bật tầm quan trọng của việc cập nhật kịp thời cơ sở hạ tầng an ninh. Nền tảng này đang sử dụng phiên bản v1.1.1 (\u003c1.3.0) của hợp đồng Safe, điều này có nghĩa là họ không thể sử dụng cơ chế Guard, một tính năng an ninh quan trọng. Nếu nền tảng này nâng cấp lên hợp đồng Safe phiên bản 1.3.0 hoặc cao hơn, và thực hiện cơ chế Guard phù hợp, chẳng hạn như chỉ định địa chỉ whitelist duy nhất nhận tiền và thực hiện xác thực ACL cho các hàm hợp đồng một cách nghiêm ngặt, có thể họ đã có thể tránh được thiệt hại lần này. Mặc dù đây chỉ là giả thuyết, nhưng nó cung cấp những ý tưởng quan trọng cho việc quản lý an ninh tài sản trong tương lai.
Cơ chế Safe Guard giống như một hệ thống kiểm tra an ninh thông minh được lắp đặt cho két bảo hiểm tài sản số, hiệu quả của nó phụ thuộc vào độ chặt chẽ của thiết kế quy tắc và chất lượng thực hiện. Đối mặt với các phương thức tấn công ngày càng tinh vi, chúng ta cần:
Xác minh tự động: Thiết lập cơ chế xác minh giao dịch tự động
Điều chỉnh chiến lược động: Điều chỉnh chính sách an ninh theo thời gian thực dựa trên thông tin tình báo về mối đe dọa
Nhiều lớp phòng thủ: Kết hợp nhiều cơ chế bảo mật để xây dựng hệ thống phòng thủ độ sâu
Kiểm toán liên tục: thực hiện kiểm toán an ninh định kỳ cho Guard
Quản lý tài sản kỹ thuật số trong tương lai sẽ là sự kết hợp thông minh
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.
8 thích
Phần thưởng
8
4
Chia sẻ
Bình luận
0/400
MetaverseLandlord
· 07-09 09:40
Safe lại một lần nữa bị hack? Thật không thể hiểu nổi.
Xem bản gốcTrả lời0
MEVictim
· 07-09 09:39
Ôi, cái safe này chỉ là một trò cười mà thôi.
Xem bản gốcTrả lời0
MechanicalMartel
· 07-09 09:39
又一个 hợp đồng thông minh挖洞神🤔
Xem bản gốcTrả lời0
SchrodingerWallet
· 07-09 09:26
chơi đùa với mọi người vài năm đồ ngốc vẫn đang lăng xê
Cơ chế Safe Guard: Hướng đi mới để tái cấu trúc kiến trúc an ninh của Ví đa chữ ký
Độ sâu phân tích tình huống khó khăn của Safe: Liệu Guard có thể xây dựng lại tháp Babel hợp đồng?
Vào ngày 21 tháng 2 năm 2025, ngành công nghiệp tiền điện tử đã trải qua cuộc khủng hoảng quản lý tài sản nghiêm trọng nhất trong lịch sử. Ví đa ký trên chuỗi của một nền tảng giao dịch đã bị tấn công có chủ đích, gần 1,5 tỷ đô la tài sản đã âm thầm bị mất thông qua một giao dịch "chữ ký hợp pháp". Phân tích trên chuỗi sau đó cho thấy, kẻ tấn công đã thu được quyền đa ký thông qua một cuộc tấn công kỹ thuật xã hội tinh vi, sử dụng tính năng deleGatecall của hợp đồng Safe để nhúng logic độc hại, cuối cùng vượt qua cơ chế xác thực đa chữ ký, chuyển tiền đến địa chỉ ẩn danh.
Sự kiện này đã phơi bày một thực tế tàn khốc: "Chữ ký đa dạng" không đồng nghĩa với "an toàn tuyệt đối", ngay cả với cơ chế an toàn như ví đa chữ ký Safe, nếu thiếu các biện pháp bảo vệ bổ sung, vẫn có nguy cơ bị tấn công. Đây cũng không phải là trường hợp đầu tiên bị tấn công nhằm vào ví đa chữ ký Safe. Năm ngoái, hai nền tảng đã chịu thiệt hại lần lượt 230 triệu USD và 50 triệu USD, đều gặp phải các phương pháp tấn công tương tự. Các sự kiện tấn công vào ví đa chữ ký Safe cho thấy sự tương đồng kỹ thuật sau đây:
Vấn đề cốt lõi của chuỗi sự kiện này không nằm ở bản hợp đồng Safe mà nằm ở những rủi ro an ninh trong quá trình tích hợp của toàn bộ hệ thống, đặc biệt là ở giai đoạn xác thực phía trước. Điều này khiến chúng ta cần suy nghĩ: Làm thế nào để tăng cường khả năng bảo vệ của ví đa chữ ký thông qua cơ chế biện pháp an toàn bổ sung của Safe?
An toàn
Safe là một ví Multi-Sig ( đa chữ ký, chủ yếu được sử dụng để quản lý tài sản có giá trị cao và lưu trữ, chuyển giao tiền điện tử một cách an toàn. Là cơ sở hạ tầng cho quản lý tài sản phi tập trung, nó đảm bảo an toàn cho các giao dịch quỹ thông qua cơ chế xác thực hợp tác nhiều bên, ngăn chặn các quản trị viên đơn lẻ hoặc hacker lợi dụng điểm lỗi đơn để thực hiện các thao tác ác ý, được ứng dụng rộng rãi trong quản trị DAO, ủy thác quỹ doanh nghiệp, quỹ phi tập trung và các tình huống khác. Hợp đồng này được đội ngũ Safe phát triển, là giải pháp quản lý tài sản trên chuỗi theo tiêu chuẩn ngành hiện tại. Hợp đồng áp dụng tiêu chuẩn EIP-712 để thực hiện chữ ký dữ liệu có cấu trúc, do đó nâng cao tính bảo mật và khả năng xác minh của dữ liệu giao dịch.
) Ứng dụng cốt lõi
) Phân tích hàm
Hàm execTransaction thực hiện giao dịch đã được xác thực qua chữ ký đa tầng:
Hàm checkContractSignatures & checkNSignatures xác thực dữ liệu chữ ký của giao dịch hoặc tin nhắn:
Hàm getTransactionHash tạo ra băm giao dịch, được sử dụng để xác minh chữ ký và ngăn chặn các cuộc tấn công phát lại:
Hàm handlePayment xử lý việc thanh toán bồi thường gas trong quá trình thực hiện giao dịch:
onBeforeExecTransaction là hàm hook ảo nội bộ, được gọi trước khi hàm execTransaction được thực thi. Mục đích thiết kế của hàm này là cho phép các hợp đồng con kế thừa hợp đồng Safe thực hiện xử lý logic tùy chỉnh trước khi giao dịch được thực thi. Tập hợp các tham số nhận bao gồm:
Mặc dù hợp đồng ví đa ký với thiết kế an toàn nghiêm ngặt và cấu trúc mô-đun linh hoạt cung cấp giải pháp hiệu quả và an toàn cho quản lý tài sản kỹ thuật số, thực hiện kiểm soát an toàn toàn bộ quy trình từ khởi tạo giao dịch đến thực hiện cuối cùng, và trở thành công cụ quan trọng trong quản lý an toàn blockchain, nhưng cũng cần lưu ý rằng nạn nhân chủ yếu dựa vào ví phần cứng để ký, trong khi một số thiết bị phần cứng có hiệu suất hiển thị kém đối với dữ liệu có cấu trúc, dễ dẫn đến việc người dùng không thể nhận diện chính xác dữ liệu giao dịch trong thời gian ngắn, từ đó có nguy cơ "ký mù". Đối với hiện tượng này, ngoài việc tối ưu hóa phần cứng và hiệu quả hiển thị dữ liệu của nó, còn có thể khám phá việc tăng cường xác nhận đa lớp, gợi ý thông minh và công cụ xác thực chữ ký để giảm thiểu thêm rủi ro an toàn do ký mù gây ra.
![Độ sâu phân tích Safe khó khăn: Guard có thể tái cấu trúc Tháp Babel hợp đồng?])https://img-cdn.gateio.im/webp-social/moments-e4f0b0daf2f48ba716dc7fdddcfdabec.webp(
Bảo vệ an toàn
Tính năng bảo mật quan trọng được giới thiệu trong phiên bản 1.3.0 của hợp đồng Safe - cơ chế Safe Guard. Cơ chế này nhằm cung cấp các điều kiện hạn chế bổ sung cho các kế hoạch đa chữ ký n-out-of-m tiêu chuẩn, tăng cường hơn nữa tính bảo mật của giao dịch. Giá trị cốt lõi của Safe Guard nằm ở khả năng thực hiện kiểm tra bảo mật ở các giai đoạn khác nhau của việc thực hiện giao dịch:
) Phân tích kiến trúc
Trong Safe, giao dịch đa chữ ký thường được thực hiện thông qua hàm execTransaction. Khi Safe Guard được kích hoạt, khi người dùng thực hiện giao dịch đa chữ ký, hợp đồng Safe sẽ gọi hàm checkTransaction của hợp đồng Guard để thực hiện kiểm tra trước giao dịch, và khi giao dịch đa chữ ký hoàn thành, hợp đồng Safe sẽ gọi hàm checkAfterExecution của hợp đồng Guard để kiểm tra kết quả thực hiện giao dịch.
Khi hợp đồng Safe thực hiện kiểm tra trước giao dịch đa chữ ký thông qua cơ chế Guard, hàm checkTransaction của nó sẽ nhận dữ liệu ngữ cảnh giao dịch đầy đủ, bao gồm địa chỉ hợp đồng mục tiêu, phương thức gọi, dữ liệu thực thi (như deleGatecall), thông tin chữ ký của chủ sở hữu, cấu hình Gas và thông tin thanh toán. Cơ chế này cho phép các nhà phát triển thực hiện các chiến lược quản lý rủi ro đa chiều, chẳng hạn như kiểm soát danh sách trắng hợp đồng (giới hạn địa chỉ có thể tương tác), quản lý quyền cấp độ hàm (vô hiệu hóa bộ chọn hàm nguy hiểm), giới hạn tần suất giao dịch và các quy tắc động dựa trên dòng tiền. Bằng cách cấu hình hợp lý các chiến lược Guard, có thể hiệu quả ngăn chặn kẻ tấn công lợi dụng các lớp không phải hợp đồng để tấn công.
Trong bối cảnh liên tục xuất hiện các sự kiện an ninh gần đây, sự quan tâm đến tính an toàn của hợp đồng ví đa chữ ký ngày càng gia tăng từ nhiều phía. Các nhà cung cấp ví phần cứng đều kêu gọi tăng cường khả năng phân tích và bảo vệ của hợp đồng Safe, nhằm ngăn ngừa việc xảy ra các rủi ro tương tự. Sau sự kiện trên một nền tảng giao dịch, nhiều dự án bắt đầu tập trung vào hợp đồng Safe và khám phá các giải pháp nâng cấp và mở rộng dựa trên cơ chế Guard. Trong đó, không ít ứng dụng đổi mới dựa trên cơ chế Guard được phát triển, xây dựng một giải pháp an ninh lớp trung gian dựa trên ví đa chữ ký Safe, cung cấp bảo vệ an toàn bổ sung giữa tài sản cơ sở và tài sản người dùng. Vai trò cốt lõi của nó là thông qua việc truyền vào hàm checkTransaction các hợp đồng mục tiêu, cách gọi, dữ liệu thực thi, thông tin chữ ký owner, thông tin thanh toán và thông tin gas liên quan đến giao dịch đa chữ ký Safe, để thực hiện kiểm tra giao dịch với độ chi tiết cực cao, bao gồm kiểm soát quyền truy cập như gọi hợp đồng trong danh sách trắng, thao tác hàm trong danh sách trắng, mục tiêu chuyển tiền trong danh sách trắng, tần suất giao dịch, v.v.
Điều đáng lưu ý là Safe chỉ cung cấp chức năng quản lý Guard và callback, logic kiểm tra giao dịch đa chữ ký thực tế do người dùng tự thực hiện, và mức độ an toàn phụ thuộc vào chất lượng của việc thực hiện Guard. Một số giải pháp đã mở rộng ý tưởng này, cấu hình một Guardian chuyên biệt cho mỗi Vault để chỉ định địa chỉ mục tiêu và quyền hoạt động được phép, thực hiện ba yếu tố kiểm soát quyền chính: chỉ định hợp đồng được phép, định nghĩa các chức năng được phép thực hiện và yêu cầu xác minh ACL. Đồng thời, áp dụng cơ chế quản trị tách biệt, Vault Guardian chịu trách nhiệm thực hiện, trong khi Governor kiểm soát quyền quản trị, đảm bảo ngay cả khi Guardian gặp sự cố, cũng có thể kịp thời thực hiện các biện pháp khắc phục để bảo vệ tài sản của người dùng. Ý tưởng thiết kế tương tự cũng đã được áp dụng trong các mô-đun an toàn của các dự án khác, thông qua việc chặn các hoạt động then chốt, và nhờ cơ chế danh sách trắng để kiểm soát chặt chẽ các hoạt động rủi ro cao như cài đặt mô-đun, thiết lập hook và quản lý bộ xác minh, từ đó đảm bảo rằng chỉ những hợp đồng đã được tin tưởng mới có thể được thêm vào hệ thống, cung cấp sự bảo vệ an toàn bền vững cho ví.
Trong chuỗi tấn công sự kiện trên một nền tảng giao dịch, nếu hợp đồng Safe triển khai cơ chế Guard được cấu hình hợp lý, kẻ tấn công thông qua execTransaction phát động cuộc gọi deleGatecall độc hại sẽ bị chặn bởi nhiều chính sách trong giai đoạn kiểm tra trước: hàm checkTransaction của Guard đầu tiên nhận diện loại thao tác deleGatecall và kích hoạt quy tắc vô hiệu hóa (ví dụ, buộc giới hạn operation chỉ là gọi thông thường), sau đó phân tích trường data phát hiện địa chỉ hợp đồng bất thường và bộ chọn hàm nguy hiểm, thông qua danh sách trắng hợp đồng và chính sách danh sách đen hàm đã được thiết lập, giao dịch sẽ bị hoàn tác ngay lập tức, cuối cùng hình thành hệ thống phòng thủ "chặn chính sách → chặn logic", hoàn toàn ngăn chặn việc chỉnh sửa lưu trữ và chuyển tiền.
![Độ sâu phân tích Safe khó khăn: Guard có thể tái cấu trúc tháp Babel hợp đồng không?]###https://img-cdn.gateio.im/webp-social/moments-4947f64f2aa4163ee644b6f8e911c6f8.webp(
Tóm lại, Safe chỉ cung cấp chức năng Guard sau phiên bản 1.3.0, mặc dù Guard có thể cung cấp kiểm tra giao dịch đa ký với độ chi tiết rất cao, nhưng người dùng có một ngưỡng khá lớn khi sử dụng chức năng Guard. Họ cần tự triển khai logic kiểm tra Guard, việc triển khai Guard thô sơ hoặc có khuyết điểm có thể không giúp người dùng nâng cao độ an toàn của ví Safe của họ, do đó việc thực hiện kiểm toán an ninh cho việc triển khai Guard là cần thiết. Không có gì phải nghi ngờ rằng, việc triển khai Guard an toàn và thích hợp có thể nâng cao đáng kể độ an toàn của ví Safe.
Kết luận và triển vọng
Một sự kiện tấn công nền tảng giao dịch đã làm nổi bật tầm quan trọng của việc cập nhật kịp thời cơ sở hạ tầng an ninh. Nền tảng này đang sử dụng phiên bản v1.1.1 (\u003c1.3.0) của hợp đồng Safe, điều này có nghĩa là họ không thể sử dụng cơ chế Guard, một tính năng an ninh quan trọng. Nếu nền tảng này nâng cấp lên hợp đồng Safe phiên bản 1.3.0 hoặc cao hơn, và thực hiện cơ chế Guard phù hợp, chẳng hạn như chỉ định địa chỉ whitelist duy nhất nhận tiền và thực hiện xác thực ACL cho các hàm hợp đồng một cách nghiêm ngặt, có thể họ đã có thể tránh được thiệt hại lần này. Mặc dù đây chỉ là giả thuyết, nhưng nó cung cấp những ý tưởng quan trọng cho việc quản lý an ninh tài sản trong tương lai.
Cơ chế Safe Guard giống như một hệ thống kiểm tra an ninh thông minh được lắp đặt cho két bảo hiểm tài sản số, hiệu quả của nó phụ thuộc vào độ chặt chẽ của thiết kế quy tắc và chất lượng thực hiện. Đối mặt với các phương thức tấn công ngày càng tinh vi, chúng ta cần:
Quản lý tài sản kỹ thuật số trong tương lai sẽ là sự kết hợp thông minh