Tương lai của quản lý tài sản kỹ thuật số sẽ là quá trình đồng tiến hóa của các cơ chế bảo mật hợp đồng thông minh và sự phát triển liên tục của tấn công và phòng thủ.

Tác giả: flush, kong, Đội ngũ bảo mật SlowMist

Biên tập bởi: Liz

bối cảnh

Vào ngày 21 tháng 2 năm 2025, ngành công nghiệp crypto đã gặp phải cuộc khủng hoảng quản lý tài sản tồi tệ nhất trong lịch sử. Ví đa chữ ký trên Chuỗi của nền tảng giao dịch Bybit đã bị nhắm mục tiêu và gần 1,5 tỷ đô la Mỹ tài sản đã bị mất một cách lặng lẽ thông qua một giao dịch có "chữ ký hợp pháp". Phân tích Chuỗi tiếp theo cho thấy kẻ tấn công đã lấy được quyền đa chữ ký thông qua các cuộc tấn công kỹ thuật xã hội tinh vi, cấy logic độc hại bằng chức năng delegatecall của hợp đồng Safe và cuối cùng bỏ qua cơ chế xác minh đa chữ ký để chuyển tiền đến một địa chỉ nặc danh.

Sự cố lần đã phơi bày một thực tế tàn khốc: "Đa chữ ký" không có nghĩa là "bảo mật tuyệt đối". Ngay cả một cơ chế bảo mật như ví đa chữ ký Safe vẫn có rủi ro bị hack nếu thiếu các biện pháp bảo vệ bổ sung. Đây không phải là cuộc tấn công đầu tiên vào ví đa chữ ký Safe . Năm ngoái, WazirX(230 triệu đô la) và Radiant Capital(50 triệu đô la) đều là nạn nhân của các cuộc tấn công tương tự. Theo phân tích trong bài viết SlowMist : Phương pháp hacker và câu hỏi đằng sau vụ trộm gần 1,5 tỷ đô la Bybit , sự cố tấn công ví đa chữ ký Safe cho thấy tính tương đồng về mặt kỹ thuật sau:

• Quá phụ thuộc vào cơ chế chữ ký: giao toàn bộ trách nhiệm bảo mật cho private key.
• Thiếu khả năng phòng thủ động: Thiếu chức năng rủi ro ro theo thời gian thực trước khi thực hiện giao dịch.
• Kiểm soát quyền hạn chi tiết: Không thiết lập cơ chế danh sách trắng cho các hoạt động rủi ro cao như delegatecall.

Vấn đề cốt lõi của sê-ri sự kiện này không nằm ở bản thân hợp đồng Safe mà nằm ở những rủi ro bảo mật trong quá trình tích hợp toàn bộ hệ thống, đặc biệt là ở liên kết xác minh giao diện người dùng. Điều này thúc đẩy chúng ta phải suy nghĩ: Làm thế nào chúng ta có thể tăng cường khả năng bảo vệ của ví đa chữ ký thông qua các biện pháp bảo mật bổ sung của Safe ?

An Safe

Safe là ví đa chữ ký chủ yếu được sử dụng để quản lý việc lưu trữ và chuyển giao an toàn tài sản có giá trị cao và tiền kỹ thuật số. Là cơ sở hạ tầng cho quản lý tài sản phi tập trung , nó đảm bảo tính bảo mật của hoạt động quỹ thông qua cơ chế xác minh hợp tác bên long, ngăn chặn một quản trị viên hoặc hacker khai thác một điểm lỗi duy nhất để thực hiện các hoạt động độc hại. Nó được sử dụng rộng rãi trong các tình huống như quản trị DAO, lưu ký quỹ của công ty và nhóm quỹ phi phi tập trung . Hợp đồng được phát triển bởi đội ngũ Safe(trước đây là Gnosis Safe ) và là giải pháp quản lý tài sản theo Chuỗi tiêu chuẩn hiện tại của ngành. Hợp đồng sử dụng tiêu chuẩn EIP-712 để triển khai chữ ký dữ liệu có cấu trúc, do đó cải thiện tính bảo mật và khả năng xác minh dữ liệu giao dịch.

Mục đích cốt lõi

• Quản lý an ninh quỹ: Hợp đồng yêu cầu nhiều chủ sở hữu được thiết lập trước cùng nhau xác nhận giao dịch trước khi giao dịch có thể được thực hiện, do đó ngăn ngừa hiệu quả các lỗi đơn lẻ hoặc hoạt động độc hại và đảm bảo an ninh quỹ.
• Thực hiện và quản lý giao dịch: Thông qua cơ chế xác minh đa chữ ký tích hợp, hợp đồng có thể thực hiện chuyển khoản bên ngoài, gọi các hợp đồng khác hoặc xử lý logic việc kinh doanh phức tạp khi đáp ứng các điều kiện ngưỡng chữ ký và hỗ trợ thanh toán và bồi thường phí cho token và tiền tệ gốc.
• Mở rộng mô-đun : Hợp đồng áp dụng thiết kế mô-đun. Bằng cách kế thừa và kết hợp nhiều mô-đun quản lý (như OwnerManager, ModuleManager, GuardManager, FallbackManager, v.v.), các 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 chức năng

Hàm execTransaction thực hiện một giao dịch được xác minh bằng nhiều chữ ký:

• Tính toán giá trị băm duy nhất của giao dịch (kết hợp với các tham số giao dịch, nonce, v.v.);
• Xác minh tính hợp lệ của tất cả chữ ký, đảm bảo rằng mỗi chữ ký đều đến từ chủ sở hữu hợp pháp hoặc địa chỉ đã được chấp thuận trước;
• Gọi logic việc kinh doanh 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 các sự kiện sau khi giao dịch được thực hiện;
• 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.

Các hàm checkContractSignatures & checkNSignatures xác minh 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à mã băm được chấp thuận trước;
• Đảm bảo rằng các chữ ký được sắp xếp theo thứ tự chủ sở hữu và mỗi chữ ký đều đến từ một địa chỉ hợp lệ, ngăn chặn các cuộc tấn công phát lại và giả mạo chữ ký.

Hàm getTransactionHash tạo ra một hàm băm giao dịch để 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 trên dữ liệu giao dịch;
• Sử dụng lắp ráp nội tuyến để tối ưu hóa hoạt động bộ nhớ và cải thiện hiệu quả tính toán;
• Kết hợp với giá trị nonce hiện tại, nó đảm bảo tính duy nhất của mỗi giao dịch.

Hàm handlePayment xử lý việc thanh toán bù gas trong quá trình thực hiện giao dịch:

• Tính toán số tiền phải thanh toán dựa trên lượng gas thực tế tiêu thụ và mức phí cơ bản;
• Hỗ trợ thanh toán bằng ETH và 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. Chức năng này được thiết kế để cho phép các hợp đồng phụ 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 hiện. Bộ tham số nhận được bao gồm:

• đến: Địa chỉ mục tiêu – Địa chỉ hợp đồng hoặc tài khoản được giao dịch gọi đến
• giá trị: Giá trị ETH– số lượng ETH được gửi cùng với giao dịch
• dữ liệu: tải dữ liệu– gọi dữ liệu chứa bộ chọn hàm và tham số
• hoạt động: Loại hoạt động – xác định xem đó là CALL hay DELEGATECALL
• safeTxGas: Giới hạn gas giao dịch – lượng gas được dành riêng để thực hiện giao dịch
• baseGas: Gas cơ bản – chi phí gas không phụ thuộc vào việc thực hiện giao dịch
• gasPrice: giá gas – giá gas được sử dụng để tính toán bồi thường phí giao dịch
• gasToken: Gas Token– Địa chỉ token được sử dụng để thanh toán phí giao dịch
• refundReceiver: Người nhận hoàn tiền – Địa chỉ nhận được khoản bồi thường phí giao dịch
• chữ ký: bộ sưu tập chữ ký – dữ liệu chữ ký của chủ sở hữu trên giao dịch

Mặc dù hợp đồng ví đa chữ ký, với thiết kế bảo mật 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 bảo mật 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 để quản lý bảo mật blockchain , nhưng điều quan trọng cần lưu ý là hầu hết nạn nhân đều dựa vào ví phần cứng để ký và một số thiết bị phần cứng chưa được tốt đối với chữ ký dữ liệu có cấu trúc, điều này dễ khiến người dùng không thể xác định chính xác dữ liệu giao dịch trong thời gian ngắn, do đó gây ra rủi ro"ký mù". Để giải quyết hiện tượng này, ngoài việc tối ưu hóa phần cứng và hiệu ứng hiển thị dữ liệu, chúng ta cũng có thể khám phá các biện pháp như thêm nhiều xác nhận, lời nhắc thông minh và các công cụ xác minh chữ ký nâng cao để giảm thêm các rủi ro bảo mật do chữ ký ẩn gây ra.

Bảo vệ an Safe

Cơ chế Safe Guard là một tính năng bảo mật quan trọng được giới thiệu trong hợp đồng Safe ở phiên bản 1.3.0. Cơ chế này được thiết kế để cung cấp các hạn chế bổ sung cho chương trình đa chữ ký n-out-of-m tiêu chuẩn, qua đó 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 quá trình 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 theo chương trình đối với tất cả các tham số giao dịch trước khi giao dịch được thực hiện để đảm bảo rằng giao dịch tuân thủ các quy tắc bảo mật được cài đặt trước.
• CheckAfterExecution: Sau khi giao dịch được thực hiện, Guard sẽ thực hiện xác minh bảo mật bổ sung để kiểm tra xem trạng thái cuối cùng của ví Safe sau khi giao dịch được thực hiện có như mong đợi hay không.

Phân tích kiến ​​trúc

Trong Safe , các giao dịch đa chữ ký thường được thực hiện thông qua hàm execTransaction. Khi Safe Guard được bậ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. Sau khi giao dịch đa chữ ký hoàn tất, 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. Việc thực hiện cụ thể như sau:

 function execTransaction( ... ) external payable override returns (bool success) { ... address guard = getGuard(); { if (guard != address(0)) { ITransactionGuard(guard).checkTransaction( // Transaction info to, value, data, operation, safeTxGas, // Payment info baseGas, gasPrice, gasToken, refundReceiver, // Signature info signatures, msg.sender ); } } ... { ... success = execute(to, value, data, operation, gasPrice == 0 ? (gasleft() - 2500) : safeTxGas); ... } { if (guard != address(0)) { ITransactionGuard(guard).checkAfterExecution(txHash, success); } }    }

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 hợp đồng này sẽ nhận được dữ liệu cảnh giao dịch đầy đủ, bao gồm địa chỉ hợp đồng đích, phương thức gọi, dữ liệu thực hiện (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 triển khai các chiến lược kiểm soát 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ỉ tương tác), quản lý quyền cấp chức năng (vô hiệu hóa bộ chọn chức năng rủi ro cao), hạn chế tần suất giao dịch và các quy tắc động dựa trên dòng vốn. Bằng cách cấu hình chiến lược Guard một cách hợp lý, kẻ tấn công có thể bị chặn hiệu quả khỏi việc sử dụng các khía cạnh phi hợp đồng để phát động các cuộc tấn công.

Trong bối cảnh các sự cố bảo mật gần đây, tất cả các bên đang ngày càng chú ý đến tính bảo mật của các hợp đồng ví đa chữ ký. Các nhà cung cấp ví phần cứng như KeyStone, OneKey, RigSec, v.v. đã kêu gọi tăng cường khả năng phân tích cú pháp và bảo vệ của các hợp đồng Safe để ngăn ngừa rủi ro tương tự xảy ra lần nữa. Sau sự cố Bybit , nhiều bên tham gia dự án bắt đầu tập trung vào hợp đồng Safe và tìm hiểu các giải pháp nâng cấp và mở rộng dựa trên cơ chế Guard. Trong đó, có nhiều ứng dụng sáng tạo dựa trên cơ chế Guard, xây dựng giải pháp bảo mật lớp trung gian dựa trên ví đa chữ ký Safe , cung cấp khả năng bảo vệ an ninh bổ sung giữa tài sản cơ sở và tài sản của người dùng. Chức năng cốt lõi của nó là chuyển hợp đồng mục tiêu, phương thức gọi, dữ liệu thực hiện, thông tin chữ ký của chủ sở hữu, thông tin thanh toán và thông tin gas liên quan đến giao dịch đa chữ ký an Safe đến hàm checkTransaction, để đạt được mục tiêu kiểm tra cực kỳ chi tiết đối với giao dịch, bao gồm các lệnh gọi hợp đồng danh sách trắng, hoạt động của hàm danh sách trắng, mục tiêu chuyển danh sách trắng, tần suất giao dịch và các biện pháp kiểm soát quyền khác.

Cần lưu ý rằng bản thân Safe chỉ cung cấp chức năng quản lý Guard và chức năng điều chỉnh hồi. Logic kiểm tra giao dịch đa chữ ký thực tế được chính người dùng triển khai và tính bảo mật của nó phụ thuộc vào chất lượng triển khai Guard. Ví dụ, Solv Guardian mở rộng ý tưởng này bằng cách cấu hình một Guardian chuyên dụng trong mỗi Vault để chỉ định địa chỉ mục tiêu và quyền hoạt động được phép, đồng thời triển khai ba yếu tố kiểm soát quyền chính là chỉ định hợp đồng được phép, xác định hoạt động chức năng được phép và yêu cầu xác minh ACL. Đồng thời, một cơ chế quản trị riêng biệt được áp dụng, trong đó Vault Guardian chịu trách nhiệm thực hiện và Governor kiểm soát quyền quản trị, đảm bảo rằng ngay cả khi Guardian gặp sự cố, các biện pháp khắc phục có thể được thực hiện kịp thời để bảo vệ tài sản của người dùng. Một khái niệm thiết kế tương tự cũng được áp dụng trong SecurityControlModule của Elytro, mô-đun các hoạt động chính thông qua hàm preExecute và sử dụng cơ chế danh sách trắng để tinh chỉnh các hoạt động rủi ro cao như cài đặt mô-đun , cài đặt hook và quản lý trình xác thực, do đó đảm bảo rằng chỉ những hợp đồng đáng tin cậy mới có thể được thêm vào hệ thống, cung cấp khả năng bảo vệ bảo mật lâu dài cho ví.

Trong Chuỗi tấn công sự kiện Bybit , nếu hợp đồng Safe triển khai cơ chế Guard được cấu hình đúng, thì delegatecall độc hại do kẻ tấn công khởi tạo thông qua execTransaction sẽ bị chặn bởi nhiều chiến lược trong giai đoạn tiền kiểm tra: Hàm checkTransaction của Guard trước tiên xác định loại hoạt động delegatecall và kích hoạt quy tắc vô hiệu hóa (chẳng hạn như buộc hoạt động chỉ là cuộc gọi bình thường), sau đó phân tích trường dữ liệu để phát hiện địa chỉ hợp đồng không thông thường (0x4622...7242) và bộ chọn hàm rủi ro cao, rồi trực tiếp khôi phục giao dịch thông qua các chiến lược danh sách trắng hợp đồng và danh sách đen hàm được cài đặt trước, cuối cùng hình thành nên hệ thống phòng thủ "chặn chiến lược → chặn logic", chặn hoàn toàn đường dẫn chuyển tiền và giả mạo lưu trữ.

Nhìn chung, 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 các kiểm tra giao dịch đa chữ ký cực kỳ chi tiết, nhưng vẫn có ngưỡng cao để người dùng có thể sử dụng chức năng Guard. Họ cần tự triển khai logic kiểm tra Guard. Một triển khai Guard thô sơ hoặc có lỗi có thể không giúp người dùng cải thiện tính bảo mật của ví Safe của họ, do đó cần phải kiểm toán tính bảo mật của triển khai Guard. Không còn nghi ngờ gì nữa, việc triển khai Guard an toàn và phù hợp có thể cải thiện đáng kể tính bảo mật của Safe Wallet.

Kết luận và triển vọng

Cuộc tấn công Bybit nhấn mạnh tầm quan trọng của việc cập nhật kịp thời cơ sở hạ tầng bảo mật. Bybit đã sử dụng phiên bản hợp đồng Safe v1.1.1 (<1.3.0), điều này có nghĩa là họ không thể sử dụng cơ chế Guard, một tính năng bảo mật quan trọng. Nếu Bybit nâng cấp lên phiên bản hợp đồng Safe 1.3.0 trở lên và triển khai cơ chế bảo vệ phù hợp, chẳng hạn như chỉ định địa chỉ danh sách trắng là địa chỉ duy nhất nhận tiền và thực hiện xác minh chức năng hợp đồng ACL nghiêm ngặt, thì có thể tránh được tổn thất lần. 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 an ninh thông minh được thêm vào két an toàn tài sản kỹ thuật số. Hiệu quả của nó phụ thuộc vào tính nghiêm ngặt của thiết kế quy tắc và chất lượng thực hiện. Đối diện những 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 chính sách động: điều chỉnh chính sách bảo mật theo thời gian thực dựa trên thông tin tình báo về mối đe dọa
• Phòng thủ nhiều lớp: 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 bảo mật định kì đối với các triển khai Guard

Tương lai của quản lý tài sản kỹ thuật số sẽ là quá trình đồng tiến hóa của các cơ chế bảo mật hợp đồng thông minh và sự phát triển liên tục của tấn công và phòng thủ. Chỉ bằng cách tích hợp các khái niệm bảo mật vào mọi liên kết, chúng ta mới có thể xây dựng được một rào cản bảo mật thực sự trong trò chơi giữa "ngọn giáo" của hacker và "lá chắn" của người bảo vệ.

Tham khảo

Tuyên bố miễn trừ trách nhiệm: Là blockchain, các bài viết được đăng trên trang web này chỉ đại diện cho quan điểm tác giả và khách và không liên quan gì đến quan điểm của Web3Caff. Thông tin trong bài viết chỉ mang tham khảo và không cấu thành bất kỳ lời khuyên hoặc đề nghị đầu tư nào. Vui lòng tuân thủ luật pháp và quy định có liên quan của quốc gia hoặc khu vực của bạn.