Hack liên chuỗi một lần nữa: Phân tích sâu logic thiết kế lĩnh vực liên chuỗi từ góc độ sản phẩm
Tuyển chọn TechFlowTuyển chọn TechFlow
Hack liên chuỗi một lần nữa: Phân tích sâu logic thiết kế lĩnh vực liên chuỗi từ góc độ sản phẩm
Các vấn đề an ninh liên quan đến cross-chain gần đây xảy ra thường xuyên, thu hút sự quan tâm rộng rãi của thị trường. Bài viết này hy vọng sẽ phân tích từ góc độ thiết kế sản phẩm, giúp người đọc hiểu rõ vì sao lĩnh vực này lại tồn tại nhiều vấn đề an toàn đến vậy.
Chuyên sâu báo cáo Web3Tác giả: 0xOar
Xuất bản bởi: Seer Labs
Lời mở đầu:
Gần đây, các vấn đề an ninh liên chuỗi xảy ra thường xuyên đã thu hút sự chú ý rộng rãi của thị trường. Bài viết này hy vọng sẽ giải thích vì sao lĩnh vực này lại gặp nhiều sự cố an toàn từ góc độ thiết kế sản phẩm. Cần làm rõ rằng, những vấn đề được nêu trong bài viết không phải dự án nào cũng mắc phải; phần lớn các vấn đề này đều đã có chiến lược xử lý tương ứng ngay từ khâu thiết kế. Mục đích chính là giúp nhiều người hiểu rõ hơn về mức độ phức tạp của lĩnh vực này.
Chúng tôi sẽ giúp bạn trước tiên tìm hiểu cách thức thiết kế của các cầu nối liên chuỗi phổ thông, sau đó chỉ ra những rủi ro an ninh mà các cầu nối này có thể gặp phải.
01 Các phương án liên chuỗi muôn hình vạn trạng nhưng không rời khỏi cốt lõi
Các báo cáo trước đây thực tế đã trình bày với mọi người vài loại phương án chuyển tiếp thông tin liên chuỗi khác nhau. Bất kể hình thức cuối cùng như thế nào, xét về mặt thiết kế sản phẩm, chỉ tồn tại ba cơ chế: chuỗi bên (sidechain - ở nghĩa rộng, trong bài viết này rollup cũng được xếp vào sidechain, đừng cãi), khóa thời gian băm (hash time lock) và cơ chế người chứng thực (notary).
(1) Chuỗi bên
Trong ba phương án này, phương án chuỗi bên có độ an toàn cao nhất, ví dụ như đủ loại rollup và các parachain của Polkadot.
Chuỗi chính và chuỗi bên chia sẻ chung tính bảo mật. Tuy nhiên, phương án chuỗi bên thường yêu cầu chuỗi nguồn và chuỗi đích phải đồng cấu (isomorphic), do đó phạm vi áp dụng bị hạn chế rất nhiều. Đây cũng là lý do Vitalik Buterin ủng hộ đa chuỗi nhưng không công nhận liên chuỗi, bởi vì các phương án liên chuỗi không thể chia sẻ tính bảo mật quả thực quá nhiều vấn đề.
(2) Khóa thời gian băm (Hash Time Lock)
Phương án này được mệnh danh là phương án liên chuỗi dị cấu (heterogeneous) phi tập trung điểm-điểm tối ưu, tuy nhiên chi phí cao và thời gian chờ đợi của người dùng dài, dẫn đến tỷ lệ áp dụng hiện tại không cao. Hơn nữa, khi chúng ta vẫn cần một bên thứ ba đóng vai trò nút trung gian đổi tiền, thì cũng cần một lớp đồng thuận trung gian để đáp ứng yêu cầu về tính bảo mật và phi tập trung.
(3) Cơ chế người chứng thực (Notary)
Đây là phương án cầu nối liên chuỗi dị cấu phổ biến nhất hiện nay. Hầu hết các sản phẩm trên thị trường về cơ bản đều có cùng nguồn gốc, về mặt thiết kế sản phẩm gần như không có sự khác biệt. Những điểm khác biệt chủ yếu nằm ở cách thức xác minh thông tin, thuật toán đồng thuận của người chứng thực, thuật toán ký kết ví lưu ký, v.v. Sự khác biệt về trải nghiệm sử dụng và độ an toàn cũng không lớn lắm. Do đó, xét về mặt an ninh, các rủi ro an toàn mà họ đối mặt cũng mang nhiều điểm chung.
Bài viết này sẽ tập trung tổng kết và phân tích một số rủi ro an toàn phổ biến mà các cầu nối theo cơ chế người chứng thực đang phải đối mặt.
02 Luồng logic sản phẩm của cơ chế người chứng thực
Trước khi tìm hiểu các rủi ro khác nhau mà cơ chế người chứng thực phải đối mặt, chúng ta cần hiểu rõ hơn về logic thiết kế chính của loại phương án này dưới góc nhìn sản phẩm.
(1) Giới thiệu sơ lược
Xét về triết lý thiết kế, phương án này thực ra rất đơn giản. Khi đối diện nhu cầu chuyển tài sản giữa các chuỗi dị cấu, giải pháp trực quan nhất thực chất là "ánh xạ" (mapping). Ý nghĩa của ánh xạ là khi người dùng A muốn chuyển ETH từ Ethereum sang Fantom, chúng ta không cần thực sự di chuyển tài sản hay phát hành lại trên Fantom (cũng không thể làm vậy). Thay vào đó, trước tiên ta gửi ETH của người dùng A vào một địa chỉ không thể di chuyển, sau đó dựa trên lượng ETH của người dùng A tồn tại tại địa chỉ này để phát hành tài sản ánh xạ tương ứng 1:1 trên Fantom. Tài sản ánh xạ đại diện cho quyền sử dụng ETH trên chuỗi gốc Ethereum. Vì được neo tỷ giá 1:1, người dùng trên Fantom cũng công nhận giá trị của tài sản này.
Quy trình liên chuỗi đơn giản hóa nhất:
(2) Những khó khăn trong thiết kế
Ở đây sẽ xuất hiện rất nhiều vấn đề, trong đó lớn nhất là quản lý ví đa ký (multi-sig wallet), vì việc ETH từ Ethereum chuyển sang Fantom là nạp tiền, còn nếu người dùng A muốn chuyển ngược lại thì sẽ liên quan đến rút tiền.
Tính phi tập trung và an toàn của việc nạp và rút tiền trở thành thách thức lớn nhất.
1. Ai quản lý tiền? 2. Ai khởi tạo giao dịch? 3. Ai lắng nghe giao dịch? 4. Làm sao xác nhận đúng là người dùng đã gửi tiền vào? 5. Làm sao xác nhận đúng là người dùng thực sự muốn rút tiền? 6. Làm sao ngăn chặn tấn công replay? 7. Giao dịch thất bại thì nộp lại như thế nào? 8. Nếu người quản lý đa ký làm điều xấu thì sao? 9. Nếu hệ thống sập thì sao?
Không dám nghĩ, càng nghĩ càng thấy phức tạp. Công nghệ cầu nối liên chuỗi không chỉ liên quan đến đa ký, mà còn liên quan đến phát hành tài sản, giám sát liên chuỗi, xác minh bất đồng bộ, thậm chí cần phát hành một lớp đồng thuận trung gian độc lập (một chuỗi mới).
Do đó, để đơn giản hóa việc người dùng hiểu hơn, tôi sẽ chia toàn bộ quy trình liên chuỗi thành hai phần: nạp tiền và rút tiền để giải thích. Nhằm giúp mọi người hiểu sâu hơn.
(3) Chi tiết hóa thêm quy trình
1. Nạp tiền
Trước tiên xin nói rõ, quy trình được vẽ trong hình dưới đây chỉ là thiết kế mà tôi suy luận ra, chưa qua kiểm chứng kỹ lưỡng, mục đích nhằm khám phá các vấn đề an toàn có thể xuất hiện trong logic thiết kế, không thể coi là phương án hoàn chỉnh để áp dụng, hoàn toàn là nói bừa.
Như hình vẽ: Về nguyên tắc, một giao dịch nạp tiền từ chuỗi nguồn đến chuỗi đích sẽ bao gồm các bước sau:
(1) Người dùng nạp vào địa chỉ lưu ký
(2) Bộ giám sát phát hiện giao dịch này, sau đó do BP (nút đồng thuận cũng là quản trị viên đa ký) khởi tạo giao dịch
(3) Hợp đồng xác minh tính đúng đắn của chữ ký BP
(4) Có vượt qua cơ chế dung sai nút hay không
(5) Nếu không thì trả lại, nếu có thì nạp tiền cho địa chỉ người dùng trên chuỗi đích theo mối quan hệ địa chỉ ánh xạ
(6) BP xác nhận giao dịch nạp tiền này
(7) Sau khi đạt đồng thuận Byzantine, chuyển token ánh xạ đến địa chỉ người dùng trên chuỗi đích
Lưu ý đặc biệt: Quy trình này nhằm thảo luận cầu nối liên chuỗi dị cấu nói chung, nên so với các phương án như anyswap, tăng thêm một bước người dùng ràng buộc mối quan hệ địa chỉ trên lớp đồng thuận trung gian. Điều này chủ yếu do các chuỗi dị cấu khác nhau có cách đính kèm thông tin giao dịch khác nhau, để xử lý thống nhất, tốt nhất là để người dùng ràng buộc sẵn mối quan hệ ánh xạ. Nếu xử lý giao dịch giữa các chuỗi EVM thì không cần bước này, chỉ cần đính kèm địa chỉ chuỗi đích khi khởi tạo giao dịch.
Quay lại chủ đề chính, từ quy trình trên có thể thấy, bắt đầu từ bước thứ hai, sẽ gặp đủ loại vấn đề xác minh logic và xử lý trong các tình huống khác nhau.
Các logic xác minh chính bao gồm:
(1) Sau khi phát hiện giao dịch, xác minh việc khởi tạo ánh xạ tài sản và giao dịch chuyển đến địa chỉ người dùng A trên chuỗi đích
(2) Việc khởi tạo giao dịch trên chuỗi đích và xác minh kết quả giao dịch. Ngoài các logic xác minh được vẽ trong quy trình của tôi, còn nên bao gồm cả việc kiểm tra nạp tiền bằng token giả, cũng như các xử lý đặc biệt cần thiết khi gọi các token khác nhau.
Để sau này có thể tổng kết tốt hơn các nguy cơ an ninh có thể xảy ra, chúng ta hãy tiếp tục tìm hiểu quy trình rút tiền.
2. Rút tiền
Quy trình rút tiền mô tả logic đổi lại tài sản ánh xạ trên chuỗi đích thành tài sản trên chuỗi nguồn. Cần lưu ý đặc biệt rằng, hiện nay nhiều token đã phát hành phiên bản trên nhiều chuỗi, tức là nhiều token có token gốc trên nhiều chuỗi khác nhau. Do đó, một số dự án cầu nối thường thiết lập các bể thanh khoản (pool). Khi bể vốn dồi dào, người dùng hầu như không cảm nhận được sự tồn tại của các tài sản ánh xạ kiểu anyDAI, mà trực tiếp đổi lấy token phiên bản trên chuỗi đích. Nhưng điều này không ảnh hưởng đến logic tổng thể. Tiếp tục phân tích.
Như hình vẽ, quy trình giao dịch rút tiền từ chuỗi đích về chuỗi nguồn như sau: (1) Người dùng khởi tạo giao dịch (chuyển lượng tài sản ánh xạ tương đương vào ví lưu ký trên chuỗi đích) (2) Xác minh danh tính BP, do một BP nào đó khởi tạo yêu cầu rút tiền (3) Xác nhận quyền rút và chữ ký (4) Sau khi đạt đồng thuận Byzantine, hoàn tất yêu cầu rút tiền trên chuỗi nguồn, chuyển tiền từ ví lưu ký trên chuỗi nguồn ra cho người dùng A (5) Nếu trong quá trình này xảy ra lỗi xác minh nút hoặc sập máy, cần hoàn tác và khởi tạo lại. Từ quy trình trên có thể thấy, các logic xác minh chính ở đây bao gồm: (1) Xác minh quyền khởi tạo và ký kết (2) Cơ chế dung sai khi xảy ra sự cố
(4) Rủi ro an ninh
1. Vấn đề an ninh trong logic thiết kế
Sau khi tìm hiểu kỹ hơn về thiết kế cầu nối liên chuỗi, chúng ta có thể thấy rằng về mặt logic thiết kế, cầu nối liên chuỗi đối mặt với rất nhiều thách thức. Tổng kết lại, chủ yếu gồm ba khía cạnh vấn đề (các vụ bị đánh cắp liên quan được ghi chú cuối mỗi vấn đề)
(1) Nạp tiền
a) Lỗ hổng quyền hạn hợp đồng nạp tiền, khiến tiền nạp vào bị chuyển đi ngay lập tức. Đây là một vấn đề ngớ ngẩn mà gần như mọi dự án hợp đồng đều có thể gặp phải. b) Vấn đề nạp token giả: một số dự án không xác minh tính xác thực của token liên chuỗi, dẫn đến fakeTOKEN → realTOKEN (anyswap), thật sự hơi ngốc. d) Vấn đề nạp token giả: tài sản gốc như ETH khác với token ERC20, nhiều cuộc tấn công xảy ra do xử lý không đúng ETH, dẫn đến fakeETH → realETH, đây cũng là lý do WETH và các tài sản wrapped khác trở nên phổ biến (thorchain). c) Dù các token đều là chuẩn ERC20, nhưng cách triển khai cụ thể khác nhau, hoặc có logic bổ sung (rebase, fallback...), nhà phát triển không nghiên cứu kỹ khi tích hợp, ví dụ như (WETH, PERI, OMT, WBNB, MATIC, AVAX) sau khi chuyển tiền xong vẫn gọi hàm fallback tùy chỉnh của sender để thực hiện thao tác bổ sung, làm tăng độ phức tạp trong việc xác định của cầu nối liên chuỗi (anyswap 2022.1.18)
(2) Chuyển tiếp tin nhắn liên chuỗi
Sau khi hoàn tất nạp tiền trên chuỗi A, trước khi tài sản đến tài khoản trên chuỗi B, xử lý của cầu nối liên chuỗi giống như một hệ thống blockchain độc lập, tức là cần một cơ chế đồng thuận, thường dùng DPoS. Dưới đây đều là các vấn đề cần cân nhắc giả sử dùng DPoS, nhưng tôi nghi ngờ tất cả các nút đều thuộc về đội dự án, trước tiên đã tiềm ẩn rủi ro tập trung. a) Giám sát tin nhắn nạp tiền: ai là người đầu tiên khởi tạo đề xuất xử lý liên chuỗi, ngẫu nhiên? luân phiên? hay theo thứ tự khối của lớp đồng thuận trung gian? b) Nhiều người chứng thực xác minh tính đúng đắn của việc nạp tiền như thế nào, nếu nguồn dữ liệu đều đến từ các nhà cung cấp như Infura, thì Infura trở thành điểm rủi ro đơn lẻ, ổn nhất là mỗi bên tự vận hành nút, nhưng chi phí rất lớn. c) Làm sao xác nhận việc xử lý liên chuỗi đã hoàn tất (tài sản đã đến B), nếu chưa hoàn tất có vài trường hợp: i. Cầu nối liên chuỗi chưa khởi tạo xử lý ii. Cầu nối đã khởi tạo xử lý nhưng xác minh & đồng thuận chưa qua iii. Cầu nối đã xác minh qua nhưng chưa khởi tạo giao dịch trên chuỗi B iv. Trên chuỗi B có giao dịch nhưng thất bại (thiếu phí hoặc tình huống khác)
(3) Vấn đề xác minh chữ ký đa ký
Khu vực tai nạn thường xuyên, phần lớn đều là vấn đề logic mã nguồn. a) 3/5 chữ ký, tôi tùy tiện tạo chữ ký không nằm trong danh sách đa ký, cũng tính +1 (chainswap). b) Vấn đề tập trung: về danh nghĩa là đa ký, thực tế nằm trong tay đội dự án, rủi ro tập trung cực lớn. c) Phương pháp xác minh chữ ký: mô hình phát triển trên các chuỗi khác nhau khác nhau, khiến nhà phát triển dễ bỏ sót khi tích hợp. Ví dụ wormhole: hàm xác minh chữ ký trên Solana là một hàm trong hợp đồng hệ thống, bình thường nên gọi đến hợp đồng hệ thống, địa chỉ hợp đồng hệ thống nên được hardcode trong mã nguồn, nhưng họ lại truyền địa chỉ hợp đồng hệ thống như một tham số, hacker khi rút tiền truyền một địa chỉ hợp đồng hệ thống giả, từ đó bypass xác minh chữ ký, rút tiền thành công.
(4) Hoàn tiền
a) Như đã thảo luận ở (2)-c, trạng thái liên chuỗi có nhiều khả năng, trong mọi trường hợp đều cần cung cấp cho người dùng cách hoàn tiền. Ví dụ anyswap khi nạp tiền sẽ trước tiên phát anyToken cho người dùng trên chuỗi nguồn, sau đó phát anyToken cho người dùng trên chuỗi đích, rồi burn anyToken trên chuỗi nguồn. Mục đích là dù vấn đề xảy ra ở đâu, người dùng đều có thể dùng việc sở hữu anyToken để biểu thị tài sản của mình. Trong quá trình này có 3 chuỗi (nguồn, đích, cầu nối liên chuỗi) và 4 tài sản (token gốc và anyToken trên chuỗi nguồn và đích), rất dễ xảy ra lỗi logic mã nguồn. b) Lỗ hổng bị lộ của Thorchain ngày 23.7.2021, hacker lợi dụng lỗi logic mã nguồn, tạo ra một giao dịch nạp giả số lượng lớn, cầu nối liên chuỗi không xử lý được, rơi vào logic hoàn tiền, khiến hacker nhận được khoản hoàn tiền khổng lồ.
2. Các rủi ro an ninh khác
Tuy nhiên, các vấn đề có thể hiển thị qua luồng logic chỉ là những vấn đề logic nghiệp vụ, không phải tất cả. Xét về mặt an ninh, chúng ta còn nên cân nhắc thêm ba khía cạnh rủi ro:
(1) Rủi ro hệ thống
Ví dụ, ban đầu nạp tiền trên chuỗi nguồn thành công, nhưng sau đó bị rollback – đây là một vấn đề lớn. Vitalik từng thảo luận, tài sản từ Solana chuyển sang Ethereum, sau khi hoàn tất liên chuỗi thì Solana rollback, khiến tài sản người dùng nhân đôi, không có cách giải quyết nào. Nhưng ví dụ như rollup, layer2 chia sẻ tính bảo mật với Ethereum, sẽ không có vấn đề này.
(2) Rủi ro giao diện người dùng (frontend)
a) Website giả mạo, ví dụ oxdao.fi, 0xdao.fi, oxdai.fi, v.v. b) Tấn công XSS (Cross-Site Scripting), một dạng tấn công tiêm mã, ví dụ www.xxxx.finance/?params=hackerscode12345, dù địa chỉ website đúng là chính thức, nhưng URL chứa mã của hacker. Nếu lập trình frontend không chú ý phòng chống XSS, đoạn mã này sẽ được thực thi trên trang, khiến người dùng ký ủy quyền chuyển tiền cho hacker. Vì vậy, đừng mở các liên kết không rõ nguồn gốc. c) Tấn công dịch vụ liên miền (Cors), trong chiến lược cùng nguồn nghiêm ngặt, trình duyệt chỉ cho phép tải nội dung từ trang hiện tại, tức là mọi nội dung hiển thị và giao diện được gọi từ trang www.xxxx.finance đều phải đến từ tên miền xxxx.finance. Nhưng hiện nay phần lớn dự án đều cho phép gọi liên miền, tức là frontend xxxx có thể gọi giao diện của quickswap, ngược lại cũng vậy. Điều này thuận tiện cho phát triển nhưng cũng mang rủi ro. Giả sử tôi truy cập xxxx.finance, lưu một số dữ liệu nhạy cảm trong bộ nhớ cache trình duyệt, sau đó truy cập một website độc hại, nếu chiến lược cùng nguồn của xxxx không giới hạn, website độc hại có thể tự do lấy dữ liệu cache mà xxxx lưu trữ.
(3) Rủi ro chức năng bổ sung
Một số dự án cầu nối liên chuỗi không chỉ cung cấp chuyển tài sản liên chuỗi, mà còn cung cấp gọi hợp đồng liên chuỗi, điều này mang lại độ phức tạp bổ sung. Kẻ tấn công khởi tạo một giao dịch trên chuỗi A gọi hợp đồng X trên chuỗi B, cầu nối liên chuỗi không kiểm tra X là gì mà gọi thẳng, không ngờ X lại là hợp đồng đa ký của chính cầu nối trên chuỗi B, giao dịch này đổi địa chỉ ví đa ký thành địa chỉ của chính hacker. Sau khi thực thi thành công, hacker có thể tự do điều phối toàn bộ tài sản của cầu nối liên chuỗi trên chuỗi B (poly network).
03 Kết luận
1. Mục đích báo cáo này là giúp người dùng hiểu rõ hơn về các rủi ro an ninh của cầu nối liên chuỗi, chứ không phải cố tình thổi phồng rằng cầu nối liên chuỗi dễ bị tấn công đến mức nào.
2. Xét về hiện tại, phương án cầu nối liên chuỗi theo cơ chế người chứng thực ít nhất là phương án có trải nghiệm tốt nhất, phạm vi áp dụng rộng nhất và chi phí thấp nhất. Và mọi sản phẩm đều trải qua quá trình từ đầy vết thương đến trưởng thành. Các cuộc tấn công vào sản phẩm blockchain thường đều là “vấn đề logic”. Những vấn đề này chắc chắn sẽ ngày càng được cải thiện theo thời gian và tích lũy kinh nghiệm.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
