Không chỉ dừng lại ở 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 khâu.

Báo cáo bảo mật 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. Đáng chú ý hơn, các cuộc tấn công này không tập trung vào một đường dẫn tấn công duy nhất, mà bao phủ lỗ hổng 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 vào duy nhất thành 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 rốt cuộc có còn an toàn không?

1. Ngoài private key, tầm quan trọng của triển khai chữ ký cấp thấp trong ví

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

SecondFi tiền thân là ví Yoroi của 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ó khả năng 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ự việc này là những người dùng bị ảnh hưởng không chủ động giao seed phrase cho kẻ tấn công. Vấn đề nằm ở triển khai chữ ký cấp thấp của ví. Theo phân tích của công ty bảo mật BlockSec, lỗi xuất phát từ việc suy luận nonce chữ ký từ thông tin giao dịch công khai trên chuỗi một cách sai lầm, thiếu prefix nonce bí mật theo yêu cầu của triển khai tiêu chuẩn.

Điều này có nghĩa là 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 phát hành lên chuỗi sẽ tiết lộ đủ thông tin để suy ra private key 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 seed phrase, chỉ cần phân tích dữ liệu trên chuỗi công khai là có thể khôi phục private key 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ì seed phrase không bị lộ qua pop-up, mật khẩu không bị crack, 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 ra private key chữ ký của địa chỉ đó.

Nói tóm lại, bảo mật ví còn phụ thuộc vào việc private key có được tạo đúng cách hay không, chữ ký có được hoàn thành theo đúng tiêu chuẩn mật mã học hay không, và 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 cũng là lý do tại sao các thành phần ví cốt lõi nên được duy trì mã nguồn mở.

Tất nhiên, đây là lỗi triển khai của một phiên bản ví cụ thể, không phải vấn đề phổ biến của tất cả ví tự quản lý. 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 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 chủ quan, 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: 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 tra, thay vì chỉ 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 như vậy tương ứng với một số nguyên tắc bảo mật 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à 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 có thể được lưu trữ bằng 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 DApp.

Quan trọng hơn, một khi nhà phát triển ví xác nhận lỗ hổng ở cấp độ tạo khóa hoặc triển khai chữ ký, chỉ cần nhập seed phrase 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 seed phrase vào ví khác, các địa chỉ và private key đã 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 từng ký qua phiên bản lỗi. Đối với người dùng thông thường, cách 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à seed phrase hoàn toàn mới, sau đó hoàn tất di chuyển tài sản, thay vì tự nhập lại hoặc thao tác với địa chỉ cũ.

2. 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ự kiện trong tháng 6 cũng 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 triển khai Rollup phiên bản cũ liên quan đến Aztec lần lượt bị tấn công, tổng thiệt hại khoảng 4,35 triệu USD.

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

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

Sự kiện khác bắt nguồn từ việc thiếu ràng buộc trong mạch zero-knowledge proof. Hệ thống xác thực một proof có hình thức hợp lệ, nhưng không đảm bảo rằng state tree riêng tư được proof sử dụng hoàn toàn khớp với state root công khai thực tế được sử dụng để thanh toán trên Ethereum. Do đó, kẻ tấn công có thể tạo proof xung quanh một state tree giả mạo và rút tài sản từ hợp đồng L1.

Loại vấn đề này khó có thể được tóm tắt bằng "hợp đồng có một dòng mã lỗ hổng nào 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 theo các quy tắc đã định, nhưng điều kiện tiên quyết là bản thân 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, proof 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 khớp với trạng thái thanh toán thực tế.

Sự cố bảo mật sau đó của 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 proof 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 private key ký SGX enclave 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 prover độc hại làm instance hợp lệ.

Sau đó, kẻ tấn công giả mạo proof 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 tóm lại, nguyên nhân là do key dùng để ký môi trường thực thi đáng tin cậy (enclave) bị lộ, và quy tắc xác thực từ xa không kiểm tra đầy đủ các thuộc tính môi trường chạy, cuối cùng khiến một proof "đã đượ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 block trên mainnet liên tục từ ngày 25 đến 26 tháng 6. 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 block: một giao dịch thực thi thất bại không dọn dẹp đúng trạng thái đã ghi trước đó, khiến các giao dịch tiếp theo bị tính Gas sai và tạo ra block chứa chuyển đổi trạng thái không hợp lệ. Vì các node khác không thể chấp nhận block đó, 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 lỗi kỹ thuật ảnh hưởng đến khả năng sẵn sàng và phục hồi của mạng. Tuy nhiên, từ góc độ bảo mật rộng hơn, khả năng sẵn sàng tự nó 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 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 block có thể được sản xuất liên tục hay không, cầu nối cross-chain có hoạt động bình thường hay không, node có thể phục hồi nhanh hay không, và khi hệ thống gặp sự cố, người dùng có 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 tránh lưu trữ lâu dài 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 sử dụng cầu chính thức và 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 gặp sự cố mạng ngừng sản xuất block, cross-chain bất thường hoặ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.

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

3. Hợp đồng không bị tấn công, dịch vụ bên thứ ba cũng có thể mang tấn công đến người dùng

Nếu các vấn đề về ví và L2 vẫn xảy ra ở các thành phần kỹ thuật cấp thấp hơn, thì sự kiện của Polymarket cho thấy giao diện web front-end gần nhất với người dùng cũng có thể trở thành điểm vào của tiề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, và kẻ tấn công đã lợi dụng điều này để tiêm mã script độc hại vào front-end Polymarket mà một số người dùng truy cập.

Theo thống kê từ các công ty bảo mật và nhà phân tích on-chain, sự kiện đã gây thiệt hại khoảng 3 triệu USD tài sản người dùng, liên quan đến khoảng 11 ví. Số tiền bị đánh cắp sau đó đã được cross-chain từ Polygon sang Ethereum và đổi thành khoảng 1.893 ETH. Tuy nhiên, sau đó Polymarket cho biết đã loại bỏ dependency bị ảnh hưởng và sẽ hoàn trả đầy đủ 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 có thể vẫn truy cập đúng tên miền Polymarket, và các tiết lộ hiện tại cũng không chỉ ra lỗ hổng hợp đồng thông minh cốt lõi của Polymarket. Vấn đề chính nằm ở dependency front-end bên thứ ba được tải bởi trang web.

Đây cũng là một tấm gương: Ngày nay, hầu hết các ứng dụng Web3 không chạy hoàn toàn trên chuỗi. Trang web mà người dùng nhìn thấy, chẳng hạn như giao diện giao dịch, vẫn phụ thuộc 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ỳ dependency nào trong số đó bị tấn công cũng có thể khiến trang web hợp pháp hiển thị thông tin sai lệch cho người dùng, thay thế địa chỉ nhận tiền hoặc dụ ví ký giao dịch độc hại.

Vì vậy, "URL là thật" không nhất thiết bằng "tất cả mã được tải lúc này đều an toàn", và "hợp đồng đã được kiểm toán" không có nghĩa là toàn bộ đường dẫn 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 front-end và chuỗi cung ứng như vậy, người dùng thông thường khó có thể tự kiểm tra từng đoạn mã được tải trên trang web, nhưng vẫn có thể hạn chế tổn thất tiềm ẩn bằng cách giảm quyền tương tác của mỗi lần:

• Sử dụng ví tương tác DApp riêng: Ví tiết kiệm dài hạn cố gắng không 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í tương tác hàng ngày chỉ lưu trữ số tiền dự định sử dụng trong thời gian ngắn. Ngay cả khi front-end hoặc ủy quyền có vấn đề, phạm vi ảnh hưởng cũng tương đối hạn chế.
• Trước khi ký, hãy chú ý đến hành động thực tế, không chỉ nhìn vào nút trên trang web: Trang web 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à cùng một việc.
• Khi trang web có dấu hiệu bất thường, đừng tiếp tục thao tác theo quán tính: Trang web đột nhiên yêu cầu nhập lại seed phrase, tải thêm plugin, hoặc nội dung giao dịch hiển thị không khớp với mô tả trên trang web, hãy 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 thu hồi các ủy quyền cũ 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ỉ là một công cụ lưu private key và bật lên 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ị thay đổi tài sản và đưa ra cảnh báo đủ rõ ràng trước khi các tương tác rủi ro cao xảy ra.

Nhưng ví cũng không thể loại bỏ mọi rủi ro cho người dùng. Mô hình bảo mật 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ì đổ hết trách nhiệm cho bất kỳ bên nào.

Lời kết

Trước đây, người ta thường nói, ai nắm private key, người đó nắm tài sản trên chuỗi.

Câu nói đó vẫn đúng, nhưng nó không bao phủ toàn bộ quá trình từ "hình thành ý định giao dịch" đến "hoàn tất thanh toán trên chuỗi" của tài sản người dùng. Ngày nay, bảo mật Web3 không chỉ là bảo vệ một bộ seed phrase, mà là bảo vệ toàn bộ đường dẫn từ ví tạo khóa, hiển thị giao dịch, thực hiện chữ ký, đến xác thực 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 mọi tương tác trên chuỗi. Đối với người dùng, thói quen bảo mật thực sự hiệu quả có nghĩa là cần phân tách quản lý mục đích sử dụng tài sản, mức độ rủi ro và bối cảnh tương tác: tài sản dài hạn thì cách ly mạnh, tương tác hàng ngày với số lượng nhỏ, DApp lạ thì ủy quyền thấp, thao tác rủi ro cao thì xác minh nhiều lần.

Rốt cuộc, khi rủi ro bảo mật 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ừ bảo vệ private key thành một bộ thói quen hoàn chỉnh.

Xin chia sẻ cùng mọi người.