Không chỉ là khóa riêng: Bảo vệ ranh giới an toàn của Web3 từ ví, L2 đến chuỗi cung ứng như thế nào?

Khi rủi ro an ninh mở rộng từ một điểm thành một chuỗi, sự phòng thủ của người dùng cũng phải nâng cấp từ việc bảo vệ khóa riêng thành một bộ thói quen hoàn chỉnh.

Tác giả: imToken

Vào tháng 6 vừa qua, thế giới tiền điện tử đã trải qua một loạt sự kiện an ninh trải dài qua nhiều khía cạnh.

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 40 vụ tấn công hacker nghiêm trọng, tổng thiệt hại lên tới 75,87 triệu USD. Điều đáng lo ngại hơn là những cuộc tấn công này không tập trung vào một loại hình tấn công nào, mà ngược lại bao phủ các lỗ hổng trong việc ký ví, lỗ hổng giao thức L2, và 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 bại trong cùng một tháng.

Khi rủi ro an ninh Web3 mở rộng từ một điểm truy cập đơn lẻ đến toàn bộ chuỗi tương tác, mỗi người dùng đều 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 thực hiện ký ví ở cấp độ cơ sở

Sự kiện an ninh xảy ra trên ví SecondFi trong hệ sinh thái Cardano vào tháng 6 là một ví dụ rất rõ ràng.

SecondFi là tiền thân của ví Yoroi trong 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í, theo giá vào thời điểm xảy ra sự việc, tương đương khoảng 2,4 triệu USD. Sau đó, SecondFi cho biết đã thực hiện các biện pháp khẩn cấp để bảo vệ khoảng 129 triệu ADA có thể bị ảnh hưởng.

Điều đặc biệt nhất của sự kiện này là người dùng bị ảnh hưởng không chủ động cung cấp cụm từ khôi phục cho kẻ tấn công, vấn đề nằm ở việc thực hiện ký ở cấp độ cơ sở của ví, theo phân tích của tổ chức an ninh BlockSec, đã sai lầm trong việc suy diễn nonce ký từ thông điệp giao dịch công khai, bỏ sót tiền tố nonce bí mật mà tiêu chuẩn yêu cầu.

Điều này khiến cho mỗi khi người dùng sử dụng phiên bản ví bị ảnh hưởng để ký giao dịch, dữ liệu ký công khai được phát hành lên chuỗi sẽ tiết lộ thông tin đủ để suy diễn khóa riêng của địa chỉ, vì vậy kẻ tấn công không cần xâm nhập vào điện thoại của người dùng, cũng không cần có cụm từ khôi phục, 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 ký riêng của địa chỉ tương ứng.

Từ góc độ của người dùng, ví vẫn hoạt động bình thường, vì cụm từ khôi phục không bị rò rỉ qua cửa sổ pop-up, mật khẩu không bị bẻ khóa, giao dịch thực sự được thực hiện bởi chính họ, nhưng từ góc độ mật mã, chỉ cần địa chỉ người dùng đã tạo ra một số chữ ký hợp lệ 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 diễn khóa ký riêng của địa chỉ đó.

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

Tất nhiên, đây là một lỗ hổng trong việc thực hiện của một phiên bản ví cụ thể, không phải là vấn đề chung của tất cả các ví tự quản. Lấy TokenCore của imToken làm ví dụ, kho mã cốt lõi của nó được lưu trữ công khai trên GitHub, bao gồm quản lý khóa, phát sinh địa chỉ và các chức năng ví cơ sở khác.

Mặc dù mã nguồn mở không có nghĩa là mã 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 từ bỏ sự cảnh giác, nhưng đối với các thành phần mật mã và 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 an ninh, nhà phát triển và cộng đồng có thể kiểm tra mã, tái hiện vấn đề và tiếp tục thử nghiệm, 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ự kiện này cũng tương ứng với một số nguyên tắc an ninh thực tế hơn.

• Đầu tiên, ví nên luôn đượ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à kịp thời cập nhật phiên bản an toàn;
• Thứ hai, không nên để tất cả tài sản trong cùng một ví giao dịch hàng ngày, tài sản lớn và dài hạn có thể được lưu trữ trong ví phần cứng hoặc ví lạnh độc lập, tách biệt 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 trong việc tạo khóa hoặc thực hiện ký, chỉ đơn giản là nhập cụm từ khôi phục vào một ví khác thường không thể giải quyết vấn đề;

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

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

Ngoài ví, nhiều sự kiện trong tháng 6 còn chỉ ra rằng 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 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 lưu ý rằng, những triển khai cũ như Aztec Connect đã vào trạng thái di sản không tương đương với việc mạng chính Aztec Network hiện tại bị tấn công, nhưng hai sự kiện này đã phơi bày những vấn đề có ý nghĩa cảnh báo cho toàn bộ lĩnh vực ZK Rollup.

Trong một trong những sự kiện đó, 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 thực tế xử lý, khiến hệ thống ghi nhận một khoản tiền gửi trong chứng minh nội bộ, nhưng đã bỏ qua quy trình trừ số dư tương ứng trên L1.

Sự kiện khác xuất phát từ việc thiếu ràng buộc trong mạch chứng minh không kiến thức, hệ thống đã xác minh một chứng minh hình thức hợp lệ, nhưng không đảm bảo rằng cây trạng thái riêng được sử dụng trong chứng minh đó hoàn toàn nhất quán với gốc trạng thái công khai thực sự được sử dụng để thanh toán trên Ethereum, do đó kẻ tấn công có thể tạo ra chứng minh xung quanh một cây trạng thái giả mạo và rút tài sản từ hợp đồng L1.

Những vấn đề này rất khó để tóm tắt bằng cách sử dụng cách tiếp cận truyền thống “hợp đồng có tồn tại một dòng mã lỗ hổng nào đó”. Dù sao thì chứng minh không kiến thức có thể chứng minh một quá trình tính toán tuân thủ các quy tắc đã định, nhưng điều kiện tiên quyết là các quy tắc đó phải đúng và đầy đủ, nếu nhà phát triển quên ràng buộc một biến quan trọng nào đó, chứng minh vẫn có thể hợp lệ về mặt toán học, nhưng lại chứng minh một kết quả không nhất quán với trạng thái thanh toán thực tế.

Sự kiện an ninh xảy ra sau đó tại Taiko đã phơi bày một loại rủi ro niềm tin L2 khác.

Vào ngày 22 tháng 6, quy trình xác minh chứng minh dựa trên SGX của Taiko đã bị lợi dụng, 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 SGX enclave đã từng được gửi đến kho GitHub công khai, đồng thời lợi dụng lỗ hổng của hợp đồng xác minh trên chuỗi không từ chối chế độ DEBUG, đăng ký kẻ 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 chứng minh 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, cuối cùng rút tài sản từ quỹ cầu nối, nói cho cùng, là do khóa được sử dụng để ký môi trường thực thi đáng tin cậy đã bị công khai, quy tắc xác thực từ xa lại không kiểm tra đầy đủ thuộc tính môi trường thực thi, cuối cùng khiến một chứng minh “được xác thực” mất đi ý nghĩa đáng tin cậy vốn có.

Trong khi đó, Base đã gặp phải tình trạng ngừng sản xuất khối trên mạng chính từ ngày 25 đến 26 tháng 6, sau khi xem xét lại, Base cho biết hai lần ngừng hoạt động này xuất phát từ cùng một lỗi logic xây dựng khối: một giao dịch thực hiện không thành công không được làm sạch đúng cách trạng thái đã ghi trước đó, dẫn đế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ệ. Do 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, trong thời gian xảy ra sự cố, tính toàn vẹn của chuỗi không bị phá hủy, và tài sản của người dùng luôn an toàn.

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

Bởi vì đối với người dùng, một chuỗi 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ể liên tục được sản xuất, cầu nối có thể hoạt động bình thường, các nút có thể phục hồi nhanh chóng, và khi hệ thống gặp sự cố, người dùng có còn có lối thoát khả thi hay không.

Vì vậy, khi sử dụng L2, người dùng cũ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ế an ninh vẫn đang thay đổi nhanh chóng, nên tránh việc lưu trữ tài sản lớn vượt quá nhu cầu sử dụng thực tế trong thời gian dài; trước khi chuyển giao, nên xác nhận rằng cầu nối đang sử dụng là chính thức và 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 gặp phải tình trạng ngừng sản xuất khối, bất thường trong cầu nối hoặc cảnh báo an ninh từ chính thức, không nên lặp đi lặp lại việc gửi giao dịch hoặc tiếp tục cầu nối tài sản.

Cách làm an toàn hơn là phân tán quản lý tài sản theo các mục đích và mức độ rủi ro khác nhau, thay vì đặt toàn bộ tính thanh khoản vào cùng một L2, cùng một cầu nối hoặc cùng một cơ chế thoát.

III. Hợp đồng không bị tấn công, nhưng dịch vụ bên thứ ba cũng có thể mang lại rủi ro cho người dùng

Nếu vấn đề của ví và L2 vẫn xảy ra trong các thành phần kỹ thuật ở mức thấp hơn, thì sự kiện của Polymarket cho thấy, giao diện web gần gũi nhất với người dùng cũng có thể trở thành cổng vào tài sản.

Vào ngày 25 tháng 6, Polymarket cho biết, một nhà cung cấp bên thứ ba mà họ sử dụng đã bị xâm nhập, kẻ tấn công đã lợi dụng điều này để tiêm mã độc vào giao diện Polymarket mà một số người dùng truy cập.

Theo thống kê của các tổ chức an ninh và các nhà phân tích trên chuỗi, sự kiện này đã gây thiệt hại khoảng 3 triệu USD tài sản của người dùng, liên quan đến khoảng 11 ví. Tài sản bị đánh cắp sau đó đã được chuyển từ Polygon sang Ethereum và được đổi thành khoảng 1893 ETH, tuy nhiên sau đó Polymarket cho biết đã loại bỏ các phụ thuộc bị ảnh hưởng và sẽ hoàn trả toàn bộ cho người dùng bị ảnh hưởng.

Điểm mấu chốt của sự kiện này là, người dùng truy cập có thể vẫn là tên miền Polymarket chính xác, các thông tin hiện có cũng không chỉ ra lỗ hổng trong hợp đồng thông minh cốt lõi của Polymarket, vấn đề chủ yếu nằm ở các phụ thuộc bên thứ ba được tải trên trang web.

Đây cũng là một tấm gương, hiện nay hầu hết các ứng dụng Web3 không hoàn toàn chạy trên chuỗi, những gì người dùng thấy trên trang web, như giao diện giao dịch, vẫn phụ thuộc rất nhiều vào cơ sở hạ tầng Internet truyền thống và các gói phần mềm bên thứ ba, bất kỳ phụ thuộc nào bị tấn công đều có thể khiến trang web hợp pháp hiển thị thông tin sai lệch, thay thế địa chỉ nhận tiền, hoặc dụ dỗ ví ký các giao dịch độc hại.

Do đó, “địa chỉ là thật” không nhất thiết có nghĩa là “tất cả mã được tải ngay lúc này đều an toàn”, “hợp đồng đã qua kiểm toán” cũng không có nghĩa là toàn bộ con đường tương tác giữa người dùng và hợp đồng đều không có rủi ro, đối mặt với các cuộc tấn công từ phía trước và chuỗi cung ứng như vậy, người dùng thông thường rất khó để kiểm tra độc lập từng đoạn mã được tải trên trang web, nhưng vẫn có thể giảm thiểu quyền truy cập trong mỗi lần tương tác, hạn chế thiệt hại tiềm tàng:

• Sử dụng ví tương tác DApp độc lập: ví tiết kiệm lâu dài không nên kết nối trực tiếp với các trang web DeFi, NFT, thị trường dự đoán và airdrop, ví giao dịch hàng ngày chỉ nên lưu trữ số tiền chuẩn bị sử dụng trong thời gian gần, ngay cả khi giao diện hoặc ủy quyền gặp vấn đề, phạm vi ảnh hưởng cũng tương đối hạn chế;
• Chú ý đến thao tác thực tế trước khi ký, thay vì chỉ nhìn nút trên trang web: trang web có thể ghi “Đăng nhập”, “Nhận” hoặc “Xác nhận đơn hàng”, nhưng không có nghĩa là chữ ký bật lên trong ví cũng là một việc tương tự;
• Khi trang web xuất hiện bất thường, không nên dựa vào thói quen để tiếp tục thao tác: nếu trang web đột nhiên yêu cầu nhập lại cụm từ khôi phục, tải xuống plugin bổ sung, hoặc nội dung giao dịch hiển thị không nhất quán với mô tả trên trang web, nên tạm dừng tương tác, xác nhận tình hình qua nhiều kênh chính thức của dự án, và kiểm tra hoặc hủy bỏ các ủy quyền lịch sử không còn sử dụng;

Từ góc độ sản phẩm ví, điều này cũng có nghĩa là vai trò của ví đang thay đổi.

Nó không chỉ nên là một công cụ lưu trữ khóa riêng và hiển thị cửa sổ ký, mà còn cần giúp người dùng hiểu ý định giao dịch, nhận diện ủy quyền bất thường, hiển thị sự thay đổi tài sản, và cung cấp cảnh báo rõ ràng trước khi xảy ra các tương tác có rủi ro cao.

Nhưng ví cũng không thể loại bỏ tất cả rủi ro cho người dùng. Mô hình an ninh thực tế hơn là ví, giao thức, L2, nhà cung cấp dịch vụ bên thứ ba và người dùng cùng nhau thu hẹp bề mặt tấn công, thay vì đổ toàn bộ trách nhiệm cho bất kỳ bên nào.

Viết ở cuối

Trong quá khứ, người ta thường nói, ai nắm giữ khóa riêng, người đó nắm giữ tài sản trên chuỗi.

Câu nói này vẫn đúng, nhưng không bao trùm toàn bộ quá trình tài sản của người dùng từ “tạo ý định giao dịch” đến “hoàn thành thanh toán trên chuỗi”, an ninh Web3 ngày nay không chỉ là bảo vệ một nhóm cụm từ khôi phục, mà là bảo vệ toàn bộ con đường từ việc ví tạo khóa, hiển thị giao dịch, thực hiện ký, đến xác minh mạng và thanh toán cuối cùng.

Tất nhiên, điều này không có nghĩa là người dùng cần tránh xa tất cả các tương tác trên chuỗi, đối với người dùng, thói quen an ninh thực sự hiệu quả có nghĩa là cần quản lý tách biệt mục đích tài sản, mức độ rủi ro và tình huống tương tác: tài sản dài hạn cần được cách ly, giao dịch hàng ngày với số tiền nhỏ, DApp lạ với quyền hạn thấp, và các thao tác rủi ro cao cần nhiều xác minh.

Dù sao đi nữa, khi rủi ro an ninh mở rộng từ một điểm thành một chuỗi, sự phòng thủ của người dùng cũng phải nâng cấp từ việc bảo vệ khóa riêng thành một bộ thói quen hoàn chỉnh.

Cùng nhau cố gắng.