Tháng 6 vừa qua, thế giới tiền mã hóa đã trải qua một loạt sự kiện an ninh trải dài qua nhiều khâu.
Báo cáo an ninh tháng mới nhất của PeckShield cho thấy, 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 cảnh giác hơn là 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 cụ thể nào, mà thay vào đó bao trùm 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ủ liên tiếp bị phá vỡ trong cùng một tháng.
Khi rủi ro an ninh Web3 mở rộng từ một điểm vào duy nhất sang toàn bộ con đường tương tác trên chuỗi, mỗi người dùng đều 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 khóa riêng tư, tầm quan trọng của việc triển khai chữ ký cấp thấp trong ví
Sự kiện an ninh xảy ra trên ví SecondFi trong hệ sinh thái Cardano vào tháng 6 là ví dụ trực quan nhất.
Tiền thân của SecondFi là ví Yoroi trong hệ sinh thái Cardano. Từ ngày 21 đến 23 tháng 6, kẻ tấn công đã chuyển đi 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í, ước tính trị giá khoảng 2,4 triệu USD theo giá tại thời điểm xảy ra sự kiện. SecondFi sau đó cho biết đã thông qua các biện pháp khẩn cấp để bảo vệ thêm khoảng 129 triệu ADA có thể bị ảnh hưởng.
Điểm đặ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 giao cụm từ khôi phục 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 cơ quan an ninh BlockSec, đã sai lầm khi suy ra nonce chữ ký từ thông điệp giao dịch công khai, bỏ sót secret nonce prefix mà tiêu chuẩn triển khai yêu cầu.
Điều này dẫn đến việc bất cứ khi nào người dùng sử dụng phiên bản ví bị ảnh hưởng để ký giao dịch, dữ liệu chữ ký công khai được đưa lên chuỗi sẽ tiết lộ thông tin đủ để suy ra khóa riêng tư của địa chỉ, do đó kẻ tấn công không cần xâm nhập điện thoại người dùng, cũng không cần có đượ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, có thể khôi phục khóa chữ ký riêng tư tương ứng.
Từ góc độ người dùng, ví vẫn hoạt động bình thường, xét cho cùng cụm từ khôi phục không hiện pop-up tiết lộ, mật khẩu không bị bẻ khóa, giao dịch cũng thực sự do chính người đó khởi tạo. Nhưng từ góc độ mật mã học, chỉ cần địa chỉ người dù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 khóa chữ ký riêng tư của địa chỉ đó.
Suy cho cùng, an ninh của ví vẫn phụ thuộc vào việc tạo khóa riêng tư có chính xác không, có tuân thủ chặt chẽ tiêu chuẩn mật mã học để hoàn thành chữ ký không, và liệu mã nguồn quan trọng này có thể được kiểm tra và xác minh bên ngoài không. Đây cũng là tầm quan trọng của việc giữ mã nguồn mở cho các thành phần lõi của ví.
Tất nhiên, đây là lỗi triển khai cụ thể của một ví và phiên bản cụ thể, không phải là vấn đề phổ biến của tất cả các ví tự lưu giữ. Lấy TokenCore của imToken làm ví dụ, kho mã nguồn lõi của nó được công khai lưu trữ trên GitHub, bao trù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 tồn tại lỗ hổng, càng không có nghĩa là người dùng có thể hoàn toàn từ bỏ 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 an ninh, nhà phát triển và cộng đồng có thể kiểm tra mã, tái tạo vấn đề và kiểm tra liên tục, 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, loại sự kiện này cũng tương ứng với một vài nguyên tắc an ninh thực tế hơn.
- Trước hết, ví nên luôn được tải xuống qua 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 phiên bản an toàn;
- 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ể sử dụng ví cứng hoặc ví lạnh độc lập để lưu trữ, 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 bên phát triển ví chính thức xác nhận xuất hiện lỗ hổng ở cấp độ tạo khóa hoặc triển khai chữ ký, việc chỉ nhập cụm từ khôi phục 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ừ khôi phục vào ví khác, địa chỉ và khóa riêng tư đã 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 được ký thông 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à tạo một bộ ví và cụm từ khôi phục hoàn toàn mới theo quy trình ứng phó khẩn cấp chính thức, sau đó hoàn tất việc di chuyển tài sản, thay vì tự mình nhập đi nhập lại hoặc thao tác trên địa chỉ cũ.
2. L2 không chỉ là 'Ethereum rẻ hơn', mà còn là cả 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 hướng rủi ro đế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 đặc biệt lưu ý rằng, đối tượng bị tấn công là các triển khai phiên bản cũ như Aztec Connect đã rơi vào trạng thái kế thừa, không tương đương với việc chính mạng chính Aztec Network hiện tại bị tấn công. Tuy nhiên, vấn đề mà hai sự kiện này phơi bày đều mang tính 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 bên trong bằng chứng, nhưng lại bỏ qua quy trình 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 bằng chứng không tiết lộ thông tin (zero-knowledge proof), hệ thống đã xác minh một bằng chứng hợp lệ về mặt hình thức, nhưng không đảm bảo rằng cây trạng thái riêng tư mà bằng chứng đó sử dụng hoàn toàn đồng nhất với gốc trạng thái công khai thực sự được dùng để thanh toán trên Ethereum, do đó kẻ tấn công có thể tạo ra bằng chứng xoay quanh 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 khó có thể tóm tắt bằng cách truyền thống 'hợp đồng có tồn tại dòng mã lỗ hổng cụ thể nào không'. Xét cho cùng, bằng chứng không tiết lộ thông tin có thể chứng minh một quá trình tính toán tuân theo các quy tắc nhất định, nhưng với điều kiện 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 nào đó, bằng chứng vẫn có thể có hiệu lực 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 đó với Taiko, lại phơi bày một loại rủi ro chuỗi niềm tin L2 khác.
Vào ngày 22 tháng 6, quy trình xác minh 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 chữ ký riêng tư của SGX enclave từng được commit lê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 Enclave chế độ DEBUG, để đăng ký trình chứng minh độc hại thành một phiên bản 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, cuối cùng rút tài sản từ quỹ cầu nối. Suy cho cùng, là do khóa dùng để ký vào 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 đủ các thuộc tính 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 đáng tin cậy vốn có.
Đồng thời, Base đã liên tục xuất hiện tình trạng ngừng sản xuất khối trên mạng chính vào ngày 25 và 26 tháng 6. Base trong báo cáo sự cố sau đó cho biết, hai lần gián đoạn 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 chính xác trạng thái đã ghi trước đó, dẫn đến việc tính toán Gas sai cho các giao dịch tiếp theo và tạo ra 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 lưới cuối cùng ngừng tiếp tục tiến triển. Base cho biết, tính toàn vẹn của chuỗi không bị phá vỡ trong thời gian sự cố, tiền của người dùng luôn an toàn.
Đây không phải là một vụ trộm cắp tài sản hoặc 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 sẵn sàng và phục hồi của mạng lưới. Nhưng từ góc nhìn an ninh rộng hơn, bản thân khả năng sẵn sà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 không, mà còn phụ thuộc vào khối có thể tiếp tục được sản xuất không, cầu nối chuỗi chéo có hoạt động bình thường không, nút có thể phục hồi nhanh không, và khi hệ thống xảy ra sự cố, người dùng có vẫn sở hữu đường thoát khả thi 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, hãy tránh lưu trữ lâu dài số tài sản lớn vượt quá nhu cầu sử dụng thực tế; trước khi chuyển chuỗi chéo, nên xác nhận đang sử dụng cầu nối chính thức và tìm hiểu thời gian rút tiền, cơ chế tạm dừng và phương thức thoát khẩn cấp; khi gặp mạng ngừng tạo khối, chuyển chuỗi chéo bất thường hoặc cảnh báo an ninh chính thức, không nên gửi giao dịch lặp đi lặp lại hoặc tiếp tục chuyển tài sản qua cầu nối.
Cách làm an toàn hơn là phân tán quản lý các tài sản có mục đích sử dụng và mức độ rủi ro khác nhau, thay vì đặt tất cả tính thanh khoản vào cùng một L2, cùng một cầu nối chuỗi chéo 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 cho người dùng
Nếu các vấn đề của ví và L2 vẫn xảy ra ở các thành phần kỹ thuật tương đối cấp thấp, thì sự kiện với Polymarket lại cho thấy, giao diện người dùng web gần người dùng nhất cũng có thể trở thành cửa ngõ cho 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, kẻ tấn công nhờ đó đã tiêm mã độc vào giao diện người dùng Polymarket mà một số người dùng truy cập.
Theo thống kê của cơ quan an ninh và nhà phân tích trên chuỗi, sự kiện gây thiệt hại tài sản người dùng khoảng 3 triệu USD, liên quan đến khoảng 11 ví. Số tiền bị đánh cắp sau đó được chuyển chuỗi chéo từ Polygon sang Ethereum và được đổi thành khoảng 1893 ETH, tuy nhiên sau đó Polymarket cho biết đã loại bỏ phần phụ thuộc bị ảnh hưởng và sẽ hoàn trả đầy đủ cho người dùng bị ảnh hưởng.
Điểm then chốt của sự kiện này là, người dùng truy cập vẫn có thể là tên miền Polymarket chính xác, các tiết lộ hiện có cũng không chỉ ra lỗ hổng hợp đồng thông minh lõi của Polymarket, vấn đề chủ yếu nằm ở phần phụ thuộc giao diện người dùng bên thứ ba mà trang web tải.
Đây cũng là một tấm gương, phần lớn ứng dụng Web3 ngày nay không hoàn toàn chạy 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 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ần phụ thuộc nào trong số đó bị tấn công đều có thể khiến trang web hợp pháp hiển thị thông tin sai, thay thế địa chỉ nhận tiền hoặc dụ ví ký vào giao dịch độc hại.
Do đó, 'URL là thật' không nhất thiết đồng nghĩa với 'tất cả mã đang tải tại thời điểm này đều an toàn', 'hợp đồng đã được kiểm toán' cũng không đồng nghĩa với 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 loại tấn công giao diện người dùng và chuỗi cung ứng này, người dùng thông thường khó có thể tự mình kiểm tra từng đoạn mã mà trang web tải, nhưng vẫn có thể hạn chế thiệt hại tiềm ẩn bằng cách giảm quyền tương tác mỗi lần:
- Sử dụng ví tương tác DApp độc lập: 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 khác nhau, 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 gần, ngay cả khi giao diện người dùng hoặc ủy quyền gặp vấn đề, phạm vi ảnh hưởng cũng tương đối hạn chế;
- Trước khi ký, chú ý đến thao tác thực tế, không chỉ nhìn nút trên trang web: Trên trang web viết 'Đăng nhập', 'Nhận' hoặc 'Xác nhận đơn hà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 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: Trang độ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 khớp 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 nhìn của sản phẩm ví, điều này cũng có nghĩa là vai trò mà ví đảm nhận đang thay đổi.
Nó không nên chỉ là một công cụ lưu trữ khóa riêng tư 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 càng nhiều càng tốt, và cung cấp cảnh báo đủ rõ ràng trước khi xảy ra tương tác rủi ro cao.
Nhưng ví cũng không thể thay người dùng loại bỏ mọi rủi ro. 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 mặt tấn công, thay vì đẩy toàn bộ trách nhiệm cho bất kỳ bên nào.
Lời cuối
Trước đây, người ta thường nói, ai nắm giữ khóa riêng tư, 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ừ 'tạo ra ý đị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. An ninh Web3 ngày nay không chỉ là bảo vệ một 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 thi chữ ký, đến việc mạng xác minh 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 an ninh thực sự hiệu quả có nghĩa là cần tách biệt 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 chú trọng cách ly, tương tác hàng ngày với số lượng nhỏ, DApp lạ ủy quyền thấp, thao tác rủi ro cao xác minh nhiều.
Xét cho cùng, 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ệ tốt khóa riêng tư thành một bộ thói quen hoàn chỉnh.
Cùng chia sẻ với mọi người.
