SlowMist: Một tình huống tiến Safe, liệu Guard có thể tái thiết lại hợp đồng Tháp Babel 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 văn bản:

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ị chảy mất một cách lặng lẽ thông qua một giao dịch "ký hợp pháp". Sau đó, phân tích trên chuỗi cho thấy, kẻ tấn công đã sử dụng một cuộc tấn công kỹ thuật xã hội tinh vi để giành được quyền đa chữ ký, sau đó lợi 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à trường hợp 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 cuộc 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 sự kiện tấn công 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.

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 bộ hệ thống, đặc biệt là ở khâu xác minh giao dịch ở phía trước. Điều này thúc đẩy chúng ta cần suy nghĩ: Làm thế nào để thông qua các biện pháp an toàn bổ sung của Safe để tăng cường khả năng bảo vệ của ví tiền đa chữ ký?

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 ngừa các hành vi xấu của một quản trị viên 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ý quỹ 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ấ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 cùng xác nhận giao dịch mới có thể thực hiện, từ đó hiệu quả ngăn ngừa sai sót hoặc hành vi xấu ở một điểm, đả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, 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 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, 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 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 tốn 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钩 nội bộ ảo, đượ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 hàm chọn 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 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 đến thực hiện giao dịch, trở thành công cụ quản lý an toàn 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ó hiệu ứng hiển thị dữ liệu cấu trúc kém, dễ dẫn đế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, từ đó có nguy cơ "ký mù". Ngoài việc cải thiện phần cứng và hiệu ứ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ý để tiếp tục giảm thiểu các lỗ hổng bảo mật do "ký mù" gây ra.

Safe Guard

Hợp đồng Safe đã giới thiệu một tính năng an toàn quan trọng trong phiên bản 1.3.0 -

Trong 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 bảo mật của hợp đồng ví đa chữ ký. Các nhà cung cấp ví phần cứng như KeyStone, OneKey, RigSec liên tục kêu gọi tăng cường khả năng phân tích và bảo vệ hợp đồng Safe, nhằm 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 đó, không thiếu những ứ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í đa chữ ký Safe, cung cấp thêm bảo vệ an ninh cho tài sản cơ sở 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 đa chữ ký Safe, cách gọi, dữ liệu thực thi, thông tin chữ ký của 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 đa chữ ký thực tế do người dùng tự triển khai, an ninh 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 chức năng được phép và yêu cầu ACL.

Đồng thời, áp dụng cơ chế quản trị tách biệt, 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 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 chặt chẽ các hoạt động rủi ro cao như cài đặt mô-đun, thiết lập钩子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 ninh lâu dài cho ví.

Trong chuỗi tấn công Bybit, nếu hợp đồng Safe được triển khai với cấu hình Guard hợp lý, các cuộc tấn công ác ý thông qua execTransaction sẽ bị chặn trong giai đoạn kiểm tra trước: Hàm checkTransaction của Guard trước 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 bất 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 giao dịch, cuối cùng hình thành hệ thống phòng thủ "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 đa chữ ký ở mức độ chi tiết, nhưng người dùng khi sử dụng chức năng Guard vẫn phải vượt qua rào cản lớn. 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 ninh 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 ninh của ví Safe.

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

Vụ tấn công vào Bybit 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 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 ninh tài sản trong tương lai.

Cơ chế Guard của Safe 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 pháp 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 chính sách động: Điều chỉnh chiến lược an ninh theo thời gian dựa trên thông tin tình báo đe dọa

· Phòng thủ nhiều lớp: Kết hợp nhiều cơ chế an ninh để xây dựng hệ thống phòng thủ 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 tiến hóa chung giữa cơ chế an ninh 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ự trong cuộc chơi "lưỡi giáo" của hacker và "khiên" của những người bảo vệ.

Liên kết bài gốc

Hãy tham gia vào nhóm chính thức của BlockBeats:

Nhóm đăng ký Telegram: https://t.me/theblockbeats

Nhóm thảo luận Telegram: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia

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