Thế tiến thoái Safe : Liệu Guard có thể xây dựng lại được Tháp Babel của Hợp đồng không?

Bài viết này được dịch máy
Xem bản gốc
Dưới đây là bản dịch tiếng Việt của nội dung trên:

Tác giả: flush & kong

Bối cảnh

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í tiền đa chữ ký trên chuỗi của sàn giao dịch Bybit đã bị tấn công có chủ đích, khiến gần 1,5 tỷ USD tài sản bị rò rỉ một cách lặng lẽ thông qua một giao dịch "ký hợp pháp". Phân tích sau sự kiện trên chuỗi cho thấy, kẻ tấn công đã thu được quyền đa chữ ký thông qua một cuộc tấn công kỹ thuật xã hội tinh vi, sau đó sử dụng chức năng delegatecall của hợp đồng Safe để cài đặt logic độc hại, cuối cùng đã vượt qua cơ chế xác minh đa chữ ký để chuyển tiền đến các địa chỉ ẩn danh.


Sự kiện này đã phơi bày một thực tế khắc nghiệt: "Đa chữ ký" không có nghĩa là "an toàn tuyệt đối", ngay cả với cơ chế an toàn như ví tiền đa chữ ký Safe, nếu thiếu các biện pháp bảo vệ bổ sung, vẫn tồn tại nguy cơ bị tấn công. Đây cũng không phải là vụ tấn công đầu tiên nhắm vào ví tiền đa chữ ký Safe. Năm ngoái, WazirX (thiệt hại 230 triệu USD) và Radiant Capital (thiệt hại 50 triệu USD) cũng đã gặp phải các kỹ thuật tấn công tương tự. Như phân tích trong bài viết "Kỹ thuật tấn công và những câu hỏi đằng sau vụ đánh cắp 1,5 tỷ USD của Bybit" của SlowMist, các vụ tấn công vào ví tiền đa chữ ký Safe đều thể hiện những điểm tương đồng về mặt kỹ thuật:

  • Quá phụ thuộc vào cơ chế chữ ký: Giao trách nhiệm bảo mật hoàn toàn cho việc quản lý private key.

  • 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ô: Không thiết lập cơ chế danh sách trắng cho các thao tác có rủi ro cao như delegatecall.

(Quy trình đánh cắp của Bybit: Sử dụng Safe v1.1.1)

Vấn đề cốt lõi của chuỗi sự kiện này không nằm ở hợp đồng Safe bản thân, mà là những lỗ hổng bảo mật trong quá trình tích hợp toàn hệ thống, đặc biệt là ở khâu xác minh phía trước. Điều này thúc đẩy 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í tiền đa chữ ký thông qua các biện pháp an toàn bổ sung của Safe?

Safe

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

Mục đích chính

  • Quản lý an toàn tài chính: Hợp đồng yêu cầu nhiều chủ sở hữu (Owners) được định sẵn phải cùng xác nhận giao dịch mới có thể thực hiện, từ đó hiệu quả ngăn chặn sai sót hoặc hành vi ác ý của một bên, đảm bảo an toàn tài chính.

  • 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 sẵn, hợp đồng có thể thực hiện các giao dịch chuyển tiền, gọi các hợp đồng khác hoặc xử lý logic kinh doanh phức tạp khi đáp ứng điều kiện ngưỡng chữ ký, hỗ trợ thanh toán bằng token và tiền gốc, cũng như bù đắp phí.

  • Mở rộng mô-đun: Hợp đồng được thiết kế theo kiến trúc mô-đun, thông qua kế thừa và kết hợp nhiều mô-đun quản lý (như OwnerManager, ModuleManager, GuardManager, FallbackManager, v.v.), giúp tính năng linh hoạt và dễ mở rộng, cung cấp hỗ trợ tùy chỉnh cho các trường hợp sử dụng khác nhau.

Phân tích chức năng

Hàm execTransaction thực hiện giao dịch đã được xác minh đa chữ ký:

  • 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ỉ đích, 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 giao dịch được thực hiện;

  • Hỗ trợ xử lý phí gas linh hoạt, đảm bảo tính chính xác khi thanh toán bù đắp.

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ý của tài khoản EOA, chữ ký hợp đồng (EIP-1271) và các giá trị băm được phê duyệt trước;

  • Đảm bảo các chữ ký được sắp xếp theo thứ tự chủ sở hữu, và mỗi chữ ký đều đến từ địa chỉ hợp lệ, ngăn chặn tấn công tái sử dụng và sửa đổi chữ ký.

Hàm getTransactionHash tạo ra giá trị băm giao dịch, dùng cho xác minh chữ ký và ngăn chặn tấn công tái sử dụng:

  • Sử dụng tiêu chuẩn EIP-712 để băm dữ liệu giao dịch có cấu trúc;

  • Sử dụng lắp ráp inline để 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 giá trị nonce hiện tại để đảm bảo tính duy nhất của mỗi giao dịch.

Hàm handlePayment xử lý thanh toán bù đắp phí 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 phí gas thực tế tiêu hao và mức phí cơ bản;

  • Hỗ trợ thanh toán bằng ETH và các token khác, đảm bảo bù đắp phí chính xác.


onBeforeExecTransaction là hàm钩 ảo bên trong, được gọi trước khi thực hiện hàm execTransaction. Mục đích thiết kế hàm này là cho phép các hợp đồng con kế thừa Safe thực hiện logic tùy chỉnh trước khi thực hiện giao dịch. Tập tham số nhận được bao gồm:

  • to: địa chỉ đích - hợp đồng hoặc tài khoản mà giao dịch sẽ gọi

  • value: giá trị ETH - số lượng ETH được gửi kèm trong giao dịch

  • data: tải trọng dữ liệu - chứa bộ chọn hàm và các tham số gọi

  • 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 - giá gas được sử dụng để tính phí giao dịch

  • gasToken: token gas - địa chỉ token được sử dụng để thanh toán phí giao dịch

  • refundReceiver: người nhận hoàn lại - địa chỉ nhận khoản bù đắp phí giao dịch

  • signatures: tập hợp chữ ký - dữ liệu chữ ký của các chủ sở hữu đối với giao dịch


Mặc dù hợp đồng ví tiền đa chữ ký, nhờ thiết kế an toàn nghiêm ngặt và cấu trúc mô-đun linh hoạt, đã cung cấp một 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, trở thành công cụ quản lý an ninh blockchain quan trọng, nhưng cũng cần lưu ý rằng, các nạn nhân chủ yếu phụ thuộc vào ví phần cứng để ký, trong khi một số thiết bị phần cứng có chất lượng hiển thị dữ liệu có cấu trúc kém, khiến người dùng không thể nhận dạng chính xác dữ liệu giao dịch trong thời gian ngắn, dẫn đến nguy cơ "ký mù". Ngoài việc cải thiện phần cứng và chất lượng hiển thị dữ liệu, có thể khám phá các biện pháp như tăng cường xác nhận đa lớp, cảnh báo thông minh và tăng cường công cụ xác minh chữ ký để giảm thiểu các lỗ hổng bảo mật do ký mù gây ra.

Safe Guard

Ở phiên bản 1.3.0, Safe đã giới thiệu một tính năng an to

Dưới bối cảnh liên tục xảy ra các sự cố an ninh gần đây, các bên ngày càng quan tâm đến tính an toàn của hợp đồng ví tiền chữ ký đa, các nhà cung cấp ví phần cứng như KeyStone, OneKey, RigSec đều kêu gcall tăng cường khả năng phân tích và bảo vệ hợp đồng Safe để ngăn ngừa các rủi ro tương tự xảy ra. Sau sự kiện Bybit, 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 số đó, không thiếu các ứng dụng sáng tạo dựa trên cơ chế Guard, xây dựng một lớp an ninh trung gian dựa trên ví tiền chữ ký đa Safe, cung cấp thêm bảo vệ an toàn cho tài sản nền tảng và tài sản của người dùng. Vai trò cốt lõi của nó là thông qua việc truyền các thông tin như hợp đồng mục tiêu của giao dịch chữ ký đa Safe, cách thức gọi, dữ liệu thực thi, thông tin chữ ký chủ sở hữu, thông tin thanh toán và thông tin gas vào hàm checkTransaction, thực hiện kiểm tra giao dịch ở mức độ chi tiết, bao gồm kiểm soát quyền hạn như danh sách trắng hợp đồng gọi, danh sách trắng chức năng, danh sách trắng mục tiêu chuyển tiền, tần suất giao dịch, v.v. Đáng chú ý là, Safe chỉ cung cấp chức năng quản lý Guard và gọi lại, logic kiểm tra giao dịch chữ ký đa được người dùng tự triển khai, an toàn 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, cấu hình một Guardian riêng cho mỗi Vault để chỉ định các địa chỉ mục tiêu và quyền hạn hoạt động được phép, thực hiện ba yếu tố kiểm soát quyền hạn chính là chỉ định hợp đồng được phép, xác định các chức năng được phép và yêu cầu xác minh ACL. Đồng thời, sử dụng cơ chế quản trị tách biệt, Vault Guardian chịu trách nhiệm thực thi, trong khi Governor kiểm soát quyền quản trị, đảm bảo rằng ngay cả khi Guardian gặp vấn đề, vẫn có thể kịp thời áp dụng 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 mô-đun SecurityControlModule của Elytro, mô-đun này sử dụng hàm preExecute để chặn các hoạt động quan trọng và sử dụng cơ chế danh sách trắng để kiểm soát chi tiết 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, đảm bảo rằng chỉ có các hợp đồng đáng tin cậy mới được thêm vào hệ thống, mang lại sự bảo vệ an toàn lâu dài cho ví. Trong chuỗi tấn công sự kiện Bybit, nếu hợp đồng Safe được triển khai với cơ chế Guard được cấu hình hợp lý, các hành vi ác ý của kẻ tấn công thông qua việc gọi execTransaction sẽ bị chặn ở giai đoạn kiểm tra trước: Hàm checkTransaction của Guard đầu tiên sẽ nhận ra loại hoạt động delegatecall và kích hoạt quy tắc cấm (chẳng hạn như bắt buộc operation chỉ là cuộc gọi thông thường), sau đó phân tích trường data và phát hiện ra địa chỉ hợp đồng không thông thường (0x4622...7242) và hàm chọn lọc nguy hiểm, thông qua chiến lược danh sách trắng hợp đồng và danh sách đen hàm được thiết lập trước, trực tiếp hủy bỏ giao dịch, cuối cùng hình thành hệ thống phòng vệ "chặn chiến lược → chặn logic" để hoàn toàn ngăn chặn đường dẫn thay đổi dữ liệu lưu trữ và chuyển tiền. Tóm lại, Safe chỉ cung cấp chức năng Guard từ phiên bản 1.3.0 trở lên, mặc dù Guard có thể cung cấp kiểm tra giao dịch chữ ký đa ở mức độ chi tiết, nhưng người dùng khi sử dụng chức năng Guard có ngưỡng khá cao. Họ cần tự triển khai logic kiểm tra Guard, việc triển khai Guard sơ sài 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, do đó việc kiểm toán an ninh cho triển khai Guard là cần thiết. Không nghi ngờ gì, việc triển khai Guard an toàn và phù hợp có thể tăng cường đáng kể an toàn của ví Safe. Kết luận và triển vọng: Sự kiện Bybit bị tấn công 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. Bybit đang sử dụng phiên bản 1.1.1 (<1.3.0) của hợp đồng Safe, có nghĩa là họ không thể sử dụng tính năng an ninh then chốt là cơ chế Guard. Nếu Bybit nâng cấp lên phiên bản Safe 1.3.0 hoặc cao hơn và triển khai cơ chế Guard phù hợp, chẳng hạn như chỉ định địa chỉ nhận tiền trong danh sách trắng và thực hiện kiểm tra ACL chức năng hợp đồng nghiêm ngặt, có thể đã tránh được thiệt hại này. Mặc dù đây chỉ là giả định, nhưng nó cung cấp một hướng quan trọng cho quản lý an toàn 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 sắt 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 triển khai. Đố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: Xây dựng cơ chế xác minh giao dịch tự động - Điều chỉnh chiến lược động: Điều chỉnh chiến lược an ninh theo thông tin đe dọa thời gian thực - Phòng vệ nhiều lớp: Kết hợp nhiều cơ chế an ninh để xây dựng hệ thống phòng vệ sâu - Kiểm toán liên tục: Tiến hành kiểm toán an ninh định kỳ cho triển khai Guard Quản lý tài sản kỹ thuật số trong tương lai sẽ là quá trình đồng tiến hóa giữa các cơ chế an niện hợp đồng thông minh và diễn biến liên tục của cuộc tấn công và phòng thủ. Chỉ khi đưa ý niệm an ninh vào mỗi khâu, chúng ta mới có thể xây dựng được bức tường an ninh thực sự giữa "mũi nhọn" của hacker và "lá chắn" của những người bảo vệ.

Nguồn
Tuyên bố từ chối trách nhiệm: Nội dung trên chỉ là ý kiến của tác giả, không đại diện cho bất kỳ lập trường nào của Followin, không nhằm mục đích và sẽ không được hiểu hay hiểu là lời khuyên đầu tư từ Followin.
Thích
Thêm vào Yêu thích
Bình luận
Followin logo