Không chỉ là private key: Từ ví, L2 đến chuỗi cung ứng, làm thế nào để bảo vệ ranh giới an toàn của Web3?

Tháng 6 vừa qua, thế giới tiền mã hóa đã trải qua một loạt sự cố bảo mật trải dài trên nhiều lĩnh vực.

Báo cáo an ninh hàng tháng mới nhất của PeckShield cho thấy, trong tháng 6 đã xảy ra tổng cộng 40 vụ tấn công mạng lớn, tổng thiệt hại lên tới 75,87 triệu USD. Đáng báo động hơn, các cuộc tấn công này không tập trung vào một con đường tấn công duy nhất, mà đã bao trùm các lỗ hổng trong triển khai chữ ký ví, lỗ hổng giao thức L2, tấn công chuỗi cung ứng dịch vụ bên thứ ba, nhiều tuyến phòng thủ đã lần lượt thất thủ trong cùng một tháng.

Khi rủi ro bảo mật Web3 mở rộng từ một điểm truy cập duy nhất sang toàn bộ đường dẫn tương tác trên chuỗi, mỗi người dùng buộc phải suy nghĩ lại một câu hỏi: Tài sản Crypto của tôi, liệu có còn an toàn không?

I. Ngoài khóa riêng, tầm quan trọng của việc triển khai chữ ký cấp thấp trong ví

Sự cố bảo mật xảy ra trên ví SecondFi thuộc hệ sinh thái Cardano vào tháng 6 là một ví dụ trực quan nhất.

Tiền thân của SecondFi là ví Yoroi thuộc hệ sinh thái Cardano. Từ ngày 21 đến 23 tháng 6, kẻ tấn công đã chuyển khoảng 16 triệu ADA từ một số địa chỉ người dùng SecondFi, liên quan đến khoảng 374 ví, trị giá khoảng 2,4 triệu USD theo giá tại thời điểm xảy ra sự việc. SecondFi sau đó cho biết đã bảo vệ thêm khoảng 129 triệu ADA có thể bị ảnh hưởng thông qua các biện pháp khẩn cấp.

Điểm đặc biệt nhất của sự cố này là người dùng bị ảnh hưởng không chủ động giao cụm từ hạt giống (seed phrase) cho kẻ tấn công; vấn đề nằm ở việc triển khai chữ ký cấp thấp của ví. Theo phân tích của tổ chức bảo mật BlockSec, đã xảy ra lỗi trong việc suy luận nonce chữ ký từ thông tin giao dịch công khai, bỏ qua tiền tố nonce bí mật (secret nonce prefix) theo yêu cầu của triển khai tiêu chuẩn.

Điều này khiến mỗi khi người dùng ký một giao dịch bằng phiên bản ví bị ảnh hưởng, dữ liệu chữ ký công khai được đưa lên chuỗi sẽ làm lộ thông tin đủ để suy luận khóa riêng của địa chỉ. Do đó, kẻ tấn công không cần xâm nhập điện thoại của người dùng, cũng không cần lấy được cụm từ hạt giống, chỉ cần phân tích dữ liệu công khai trên chuỗi là có thể khôi phục khóa riêng chữ ký của địa chỉ tương ứng.

Từ góc nhìn của người dùng, ví vẫn hoạt động bình thường, vì cụm từ hạt giống không bị lộ qua pop-up, mật khẩu không bị giải mã, và giao dịch thực sự do chính họ khởi tạo. Nhưng từ góc độ mật mã học, chỉ cần địa chỉ của người dùng từng tạo ra một số chữ ký hợp lệ thông qua phiên bản bị ảnh hưởng, dữ liệu giao dịch và chữ ký công khai đó có thể giúp kẻ tấn công suy luận ra khóa riêng chữ ký của địa chỉ.

Nói tóm lại, bảo mật ví còn phải xem xét liệu khóa riêng có được tạo ra một cách chính xác hay không, liệu chữ ký có được hoàn thành theo đúng tiêu chuẩn mật mã hay không, và liệu những đoạn mã quan trọng này có thể được kiểm tra và xác minh từ bên ngoài hay không. Đây chính là tầm quan trọng của việc duy trì mã nguồn mở cho các thành phần cốt lõi của ví.

Tất nhiên, đây là một lỗ hổng triển khai của một phiên bản ví cụ thể, không phải là vấn đề phổ biến của tất cả các ví tự quản lý. Lấy TokenCore của imToken làm ví dụ, kho mã nguồn cốt lõi của nó được lưu trữ công khai trên GitHub, bao gồm các chức năng ví cấp thấp như quản lý khóa, dẫn xuất địa chỉ và ký giao dịch.

Mặc dù mã nguồn mở không có nghĩa là mã chắc chắn không có lỗ hổng, và càng không có nghĩa là người dùng có thể hoàn toàn lơ là cảnh giác, nhưng đối với các thành phần mật mã và chữ ký nhạy cảm nhất trong ví, mã nguồn mở ít nhất cung cấp một tiền đề quan trọng, đó là các nhà nghiên cứu bảo mật, nhà phát triển và cộng đồng có thể kiểm tra mã, tái tạo sự cố và liên tục kiểm thử, thay vì chỉ có thể tin tưởng vào một hộp đen không thể xác minh.

Đối với người dùng thông thường, những sự cố kiểu này cũng tương ứng với một vài nguyên tắc bảo mật thực tế hơn.

• Trước hết, ví luôn phải được tải xuống từ trang web chính thức hoặc cửa hàng ứng dụng chính thức, và cập nhật kịp thời các phiên bản bảo mật;
• Thứ hai, không nên đặt tất cả tài sản vào cùng một ví tương tác hàng ngày. Tài sản lớn dài hạn nên được lưu trữ bằng ví phần cứng hoặc ví lạnh độc lập, cách ly với ví nóng thường xuyên kết nối với DApp.
• Quan trọng hơn, một khi ví chính thức xác nhận có lỗ hổng ở cấp độ tạo khóa hoặc triển khai chữ ký, chỉ việc nhập cụm từ hạt giống cũ vào một ví khác thường không giải quyết được vấn đề;

Bởi vì sau khi nhập cùng một bộ cụm từ hạt giống vào ví khác, các địa chỉ và khóa riêng đã bị lộ trước đó sẽ không thay đổi. Các tài sản bị ảnh hưởng cần được chuyển đến một địa chỉ mới chưa từng được ký bằng phiên bản lỗi. Đối với người dùng thông thường, cách làm an toàn hơn thường là làm theo quy trình khẩn cấp chính thức để tạo một bộ ví và cụm từ hạt giống hoàn toàn mới, sau đó thực hiện di chuyển tài sản, thay vì tự mình nhập lại hoặc thao tác trên các địa chỉ cũ.

II. L2 không chỉ là "Ethereum rẻ hơn", mà còn là một chuỗi tin cậy phức tạp

Ngoài ví, nhiều sự cố trong tháng 6 còn chỉ ra rủi ro đang hướng đến các hệ thống L2 ngày càng phức tạp.

Vào ngày 14 và 18 tháng 6, hai bản triển khai Rollup cũ liên quan đến Aztec đã bị tấn công, tổng thiệt hại khoảng 4,35 triệu USD.

Cần giải thích rõ, các bản triển khai cũ như Aztec Connect đã ở trạng thái ngừng hoạt động (legacy) mới bị tấn công, không đồng nghĩa với việc mạng chính Aztec Network hiện tại bị tấn công. Tuy nhiên, vấn đề mà hai sự cố này phơi bày mang tính cảnh báo cao cho toàn bộ lĩnh vực ZK Rollup.

Trong một sự cố, kẻ tấn công đã lợi dụng sự không nhất quán giữa số lượng giao dịch và dữ liệu xử lý thực tế, khiến hệ thống ghi nhận một khoản tiền gửi vào bên trong bằng chứng (proof), nhưng lại bỏ qua quy trình khấu trừ số dư tương ứng trên L1.

Sự cố khác bắt nguồn từ việc thiếu ràng buộc (constraint) trong mạch zero-knowledge proof. Hệ thống đã xác thực một bằng chứng có hình thức hợp lệ, nhưng không đảm bảo rằng cây trạng thái riêng tư (private state tree) được sử dụng trong bằng chứng đó hoàn toàn khớp với gốc trạng thái công khai (public state root) thực sự được dùng để thanh toán trên Ethereum. Kẻ tấn công do đó có thể tạo ra một bằng chứng dựa trên một cây trạng thái giả mạo và rút tài sản từ hợp đồng L1.

Loại vấn đề này rất khó để khái quát bằng khái niệm "hợp đồng có một dòng mã lỗ hổng nào đó hay không". Rốt cuộc, zero-knowledge proof có thể chứng minh một quá trình tính toán tuân thủ các quy tắc nhất định, nhưng điều kiện tiên quyết là bản thân các quy tắc đó phải chính xác và đầy đủ. Nếu nhà phát triển quên ràng buộc một biến quan trọng, bằng chứng vẫn có thể hợp lệ về mặt toán học, nhưng lại chứng minh cho một kết quả không nhất quán với trạng thái thanh toán thực tế.

Sự cố bảo mật xảy ra sau đó với Taiko đã phơi bày một loại rủi ro chuỗi tin cậy L2 khác.

Vào ngày 22 tháng 6, quy trình xác thực bằng chứng dựa trên SGX của Taiko đã bị khai thác, gây thiệt hại khoảng 1,7 triệu USD. Theo phân tích của BlockSec, kẻ tấn công đã sử dụng một khóa riêng ký enclave SGX từng được tải lên kho GitHub công khai, đồng thời lợi dụng lỗ hổng hợp đồng xác thực trên chuỗi không từ chối Enclave ở chế độ DEBUG, để đăng ký một trình chứng minh độc hại như một thực thể hợp pháp.

Kẻ tấn công sau đó đã giả mạo bằng chứng trạng thái L2, khiến hợp đồng trên Ethereum chấp nhận một trạng thái L2 không tồn tại, và cuối cùng rút tài sản từ quỹ cầu nối. Nói tóm lại, nguyên nhân là do khóa dùng để ký môi trường thực thi đáng tin cậy bị công khai, và các quy tắc xác thực từ xa (remote attestation) không kiểm tra đầy đủ các thuộc tính của môi trường chạy, cuối cùng khiến một bằng chứng "đã được xác thực" mất đi ý nghĩa tin cậy vốn có.

Trong khi đó, Base đã gặp sự cố ngừng sản xuất khối trên mạng chính liên tục từ ngày 25 đến 26 tháng 6. Trong bài đánh giá sau sự cố, Base cho biết hai lần gián đoạn đều bắt nguồn từ cùng một lỗ hổng logic xây dựng khối: một giao dịch thực thi thất bại đã không dọn dẹp đúng cách trạng thái đã ghi nhận trước đó, khiến các giao dịch tiếp theo bị tính toán Gas sai và tạo ra các khối chứa chuyển đổi trạng thái không hợp lệ. Vì các nút khác không thể chấp nhận khối này, mạng cuối cùng đã ngừng tiến triển. Base cho biết tính toàn vẹn của chuỗi không bị phá vỡ trong sự cố và tiền của người dùng luôn an toàn.

Đây không phải là một vụ trộm tài sản hay tấn công từ bên ngoài, mà là một sự cố kỹ thuật ảnh hưởng đến khả năng khả dụng và khả năng phục hồi của mạng. Nhưng từ góc nhìn bảo mật rộng hơn, bản thân tính khả dụng cũng là một phần của mô hình bảo mật L2.

Bởi vì đối với người dùng, một blockchain có an toàn hay không không chỉ phụ thuộc vào việc hacker có thể giả mạo tài sản hay không, mà còn phụ thuộc vào việc các khối có thể được sản xuất liên tục hay không, cầu nối cross-chain có thể hoạt động bình thường hay không, các nút có thể phục hồi nhanh chóng hay không, và khi hệ thống gặp sự cố, người dùng có còn lối thoát khả thi hay không.

Vì vậy, khi sử dụng L2, người dùng không nên chỉ so sánh phí giao dịch và kỳ vọng airdrop. Đối với các L2 quy mô nhỏ, mới ra mắt hoặc cơ chế bảo mật đang thay đổi nhanh chóng, hãy cố gắng tránh lưu trữ lâu dài các tài sản lớn vượt quá nhu cầu sử dụng thực tế; trước khi cross-chain, hãy xác nhận đang sử dụng cầu nối chính thức, đồng thời tìm hiểu thời gian rút tiền, cơ chế tạm dừng và cách thoát khẩn cấp; khi mạng ngừng sản xuất khối, cross-chain bất thường hoặc có cảnh báo bảo mật chính thức, đừng liên tục gửi giao dịch hoặc tiếp tục cầu nối tài sản