Tại sao những cây cầu xuyên chuỗi lại có nhiều vụ tai nạn cấp thấp như vậy?

lời tựa

Các vấn đề bảo mật chuỗi chéo thường xuyên xảy ra gần đây đã thu hút sự chú ý rộng rãi từ thị trường.Bài viết này hy vọng sẽ bắt đầu từ góc độ thiết kế sản phẩm và cho người đọc biết lý do tại sao có quá nhiều vấn đề bảo mật sản phẩm trên đường đua này. Cần phải tuyên bố rằng các vấn đề được chỉ ra trong bài viết không tồn tại trong mọi dự án, hầu hết các vấn đề đã được thiết kế với các chiến lược đối phó có liên quan, mục đích của bài viết này chủ yếu là hy vọng rằng nhiều người có thể hiểu được bài hát này. .

Logic viết của bài báo là: trước tiên giải thích rõ ràng cách thiết kế các cầu xuyên chuỗi chung, giúp người đọc hiểu sâu hơn về các cầu xuyên chuỗi, sau đó tóm tắt các vấn đề bảo mật mà các cầu xuyên chuỗi này có thể gặp phải.

1: Một giải pháp xuyên chuỗi luôn thay đổi

Báo cáo nghiên cứu trước đây đã thực sự giải thích cho mọi người một số loại giải pháp chuỗi thông tin khác nhau, bất kể bài thuyết trình cuối cùng là gì, từ góc độ thiết kế sản phẩm, chỉ có chuỗi bên (chuỗi bên theo nghĩa rộng, trong văn bản) Phát biểu của rollup, nó cũng có thể được tóm tắt thành ba cơ chế: chuỗi bên, khóa thời gian băm và công chứng.

(1) Chuỗi bên

Trong số ba sơ đồ, sơ đồ sidechain có tính bảo mật cao nhất, chẳng hạn như các parachains rollup và polkadot khác nhau. Bảo mật được chia sẻ giữa chuỗi chính và chuỗi bên.

Tuy nhiên, sơ đồ sidechain thường yêu cầu chuỗi ban đầu và chuỗi mục tiêu phải đẳng cấu, do đó, có ít trường hợp áp dụng hơn rất nhiều. Đây cũng là lý do tại sao Vitalik đồng ý với đa chuỗi, nhưng không phải chuỗi chéo, vì có quá nhiều vấn đề với các giải pháp chuỗi chéo không thể chia sẻ bảo mật.

(2) Khóa thời gian băm

Giải pháp này tuyên bố là giải pháp xuyên chuỗi hỗn hợp ngang hàng phi tập trung nhất, nhưng chi phí cao và thời gian chờ đợi của người dùng quá lâu, dẫn đến tỷ lệ chấp nhận hiện tại không cao. Và khi chúng tôi vẫn cần một bên thứ ba đóng vai trò là nút trung gian để trao đổi tiền tệ, chúng tôi cũng cần cái gọi là lớp đồng thuận trung gian để đáp ứng các yêu cầu về bảo mật và phân cấp.

(3) Cơ chế công chứng

Đây là giải pháp cầu nối chéo không đồng nhất được sử dụng 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ó nguồn gốc giống nhau, nhìn từ góc độ thiết kế sản phẩm hầu như không có sự khác biệt. Sự khác biệt chính có thể tập trung vào phương pháp và các bước xác minh thông tin, thuật toán đồng thuận của công chứng viên, thuật toán chữ ký của ví ký quỹ, v.v. Không có nhiều khác biệt về trải nghiệm người dùng và độ an toàn. Do đó, từ quan điểm bảo mật, các rủi ro bảo mật gặp phải cũng có nhiều đặc điểm chung.

Bài viết này sẽ tập trung vào việc tóm tắt và phân tích một số rủi ro bảo mật phổ biến mà cầu nối liên chuỗi của cơ chế công chứng phải đối mặt.

Hai là: Sản phẩm logic quy trình của cơ chế công chứng

Trước khi hiểu các rủi ro khác nhau mà cơ chế công chứng phải đối mặt, chúng ta cần hiểu logic thiết kế của loại giải pháp này từ quan điểm sản phẩm.

(1) Giới thiệu tóm tắt

Giải pháp này thực sự rất đơn giản từ góc độ triết lý thiết kế. Khi chúng ta đối mặt với nhu cầu của các tài sản không đồng nhất xuyên chuỗi, giải pháp trực quan nhất thực sự là "lập bản đồ". Ánh xạ có nghĩa là khi người dùng A chuyển ETH từ Ethereum sang Fantom. Chúng tôi không cần chuyển nội dung về mặt vật lý hoặc phát hành lại nội dung đó trên Fantom (không thể). Thay vào đó, trước tiên hãy lưu trữ ETH của người dùng A trong một địa chỉ không thể di chuyển, sau đó phát hành tài sản được ánh xạ 1:1 tương ứng trên Fantom theo số lượng ETH của người dùng A được lưu trữ trong địa chỉ này. Các tài sản được ánh xạ đại diện cho quyền sử dụng các ETH đó trên chuỗi Ethereum ban đầu. Do neo 1:1, người dùng trên Fantom cũng nhận ra giá trị của tài sản này.

Quy trình xuyên chuỗi đơn giản nhất

(2) Khó khăn trong thiết kế

Sẽ có nhiều vấn đề trong việc này, vấn đề lớn nhất là việc quản lý ví đa chữ ký, vì ETH chuyển từ Ethereum sang Fantom là một khoản tiền gửi và nếu người dùng A muốn chuyển ngược lại thì sẽ liên quan đến vấn đề rút tiền.

Việc phân cấp và bảo mật tiền gửi và rút tiền đã trở thành khó khăn lớn nhất.

1: Ai sẽ quản lý tiền?

2: Ai sẽ bắt đầu?

3: Ai sẽ giám sát giao dịch?

4: Làm cách nào để xác nhận rằng thực sự có người dùng chuyển tiền vào?

5: Làm thế nào để xác nhận rằng tiền của người dùng thực sự là chính người dùng muốn rút?

6: Làm thế nào để ngăn chặn các cuộc tấn công lặp lại?

7: Làm thế nào để gửi lại một giao dịch không thành công?

8: Điều gì sẽ xảy ra nếu người quản lý nhiều chữ ký làm điều ác?

9: Tôi nên làm gì nếu có thời gian chết?

Tôi không dám nghĩ tới, càng nghĩ càng cảm thấy phức tạp. Công nghệ cầu nối chuỗi chéo không chỉ liên quan đến đa chữ ký mà còn liên quan đến phát hành tài sản, giám sát chuỗi chéo, xác minh không đồng bộ và thậm chí cần phát hành lớp đồng thuận trung gian độc lập (chuỗi mới).

Do đó, để đơn giản hóa hơn nữa khó khăn cho người dùng hiểu, tôi sẽ chia toàn bộ quy trình xuyên chuỗi thành hai phần: gửi và rút tiền. Để giúp bạn tìm hiểu thêm về:

(3) Hoàn thiện hơn nữa quy trình

1: Gửi tiền xu

Trước hết, tôi xin tuyên bố rằng quy trình được vẽ trong hình bên dưới chỉ là kế hoạch thiết kế do tôi suy luận mà không có sự tranh luận cẩn thận. Mục đích là để khám phá các vấn đề bảo mật có thể xảy ra trong logic thiết kế và không thể áp dụng nó như một kế hoạch hoàn thiện. Đó là Tất cả đều nhảm nhí.

Như thể hiện trong hình: một giao dịch gửi tiền từ chuỗi ban đầu sang chuỗi mục tiêu về nguyên tắc sẽ bao gồm các bước sau:

(1) Người dùng nạp tiền vào địa chỉ lưu trữ

(2) Sau khi người nghe giám sát giao dịch, BP (nút đồng thuận cũng là quản trị viên đa chữ ký) sẽ bắt đầu giao dịch

(3) Hợp đồng xác minh tính chính xác của chữ ký BP

(4) Có cơ chế chịu lỗi nút hay không

(5) Nếu không có cuộc gọi lại, nếu có, hãy nạp lại địa chỉ chuỗi đích theo mối quan hệ của địa chỉ được ánh xạ

(6) BP xác nhận giao dịch nạp tiền

(7) Chuyển mã thông báo ánh xạ đến địa chỉ của người dùng trên chuỗi mục tiêu sau khi chuyển qua Byzantium

Cần lưu ý rằng quy trình này nhằm mục đích thảo luận về các chuỗi chéo không đồng nhất nói chung, do đó, so với anyswap và các giải pháp khác, nó bổ sung thêm một bước cho phép người dùng liên kết các mối quan hệ địa chỉ trên lớp đồng thuận trung gian. Điều này chủ yếu là do các cách khác nhau để đính kèm thông tin vào các giao dịch chuỗi không đồng nhất khác nhau, để giải quyết nó một cách thống nhất, tốt hơn hết là để người dùng ràng buộc mối quan hệ ánh xạ trước.

Nếu bạn đang xử lý các giao dịch trên chuỗi EVM, bạn không cần bước này, chỉ cần đính kèm địa chỉ của chuỗi mục tiêu khi bắt đầu giao dịch.

Quay lại chủ đề: Từ quy trình trên, chúng ta có thể thấy rằng bắt đầu từ bước thứ hai, chúng ta sẽ gặp phải nhiều vấn đề xác minh logic và các vấn đề xử lý trong các tình huống khác nhau.

Logic xác minh chính bao gồm:

(1) Sau khi lắng nghe giao dịch, hãy xác minh giao dịch khởi tạo ánh xạ nội dung và chuyển đến chuỗi mục tiêu của người dùng A

(2) Bắt đầu giao dịch chuỗi mục tiêu và xác minh kết quả giao dịch

Tất nhiên, ngoài logic xác minh được rút ra trong quy trình của tôi, nó cũng phải bao gồm việc xác minh các vấn đề nạp tiền giả, cũng như các vấn đề xử lý đặc biệt cần được thực hiện khi gọi các mã thông báo khác nhau. Để tóm tắt rõ hơn các mối nguy hiểm an toàn tiềm ẩn có thể phát sinh trong tương lai, chúng ta hãy tiếp tục tìm hiểu quy trình rút tiền.

2: Rút xu

Quá trình được thể hiện bằng việc rút tiền xu là logic trao đổi tài sản chuỗi mục tiêu trở lại tài sản chuỗi ban đầu. Điều quan trọng cần lưu ý là nhiều mã thông báo hiện có nhiều phiên bản chuỗi, có nghĩa là nhiều mã thông báo trên nhiều chuỗi sở hữu mã thông báo gốc. Do đó, một số dự án cầu thường thiết lập nhóm tài sản. Trong trường hợp có đủ quỹ, người dùng sẽ không cảm thấy sự tồn tại của các tài sản được ánh xạ như anyDAI mà thay thế trực tiếp chúng bằng mã thông báo của phiên bản chuỗi mục tiêu, nhưng điều này không ảnh hưởng đến logic tổng thể. Vì vậy, phân tích tiếp tục:

Như thể hiện trong hình: một luồng giao dịch từ chuỗi mục tiêu sang chuỗi ban đầu như sau:

(1) Người dùng bắt đầu giao dịch (chuyển cùng một lượng tài sản được ánh xạ sang ví ký quỹ trên chuỗi mục tiêu)

(2) Xác minh danh tính BP và BP bắt đầu yêu cầu rút tiền

(3) Xác nhận thẩm quyền rút tiền và chữ ký

(4) Hoàn thành yêu cầu rút tiền trên chuỗi ban đầu sau khi vượt qua Byzantium và chuyển tiền từ ví lưu ký của chuỗi ban đầu cho người dùng A

(5) Nếu có lỗi xác minh nút hoặc thời gian ngừng hoạt động ở giữa, nút đó cần được khôi phục và bắt đầu lại

Như có thể thấy từ quy trình trên, logic xác minh chính liên quan ở đây là:

(1) Xác minh quyền bắt đầu và chữ ký

(2) Cơ chế chịu lỗi sau khi sự cố xảy ra

(4) Rủi ro bảo mật

1: Vấn đề bảo mật trong logic thiết kế

Sau khi hiểu kỹ hơn về thiết kế của cầu xuyên chuỗi, chúng ta có thể thấy rằng có rất nhiều thách thức trong logic thiết kế của cầu xuyên chuỗi. Tóm lại, có ba vấn đề chính (các trường hợp bị đánh cắp có liên quan được đánh dấu tại cuối câu hỏi)

(1) Đặt cọc

a) Có lỗ hổng trong thẩm quyền của hợp đồng nạp xu, dẫn đến việc chuyển trực tiếp số tiền đã nạp. Đây là một câu hỏi ngớ ngẩn mà hầu như tất cả các dự án hợp đồng sẽ gặp phải,

b) Vấn đề nạp tiền giả, một số dự án chưa xác minh tính xác thực của Token chuỗi chéo, dẫn đến fakeTOKEN -> realTOKEN (anyswap), thành thật mà nói, điều này hơi ngu ngốc.

c) Vấn đề nạp tiền giả, tài sản bản địa như ETH khác với hợp đồng ERC20 và nhiều cuộc tấn công là do xử lý ETH không đúng cách, dẫn đến fakeETH -> realETH, đó là lý do tại sao các tài sản được bao bọc như WETH lại phổ biến . (chuỗi ngực)

d) Mặc dù các Token khác nhau đều là tiêu chuẩn ERC20, nhưng các phương thức triển khai cụ thể khác nhau hoặc có các logic bổ sung (rebase, dự phòng, v.v.), các nhà phát triển đã không nghiên cứu kỹ khi điều chỉnh, chẳng hạn như (WETH, PERI , OMT , WBNB, MATIC, AVAX), v.v. sẽ gọi chức năng dự phòng tùy chỉnh của người gửi để thực hiện các hoạt động bổ sung sau khi quá trình chuyển hoàn tất, điều này làm tăng độ phức tạp của phán đoán cầu nối chuỗi chéo (anyswap 2022.1.18)

(2) Truyền tin nhắn xuyên chuỗi

Sau khi hoàn tất ký gửi chuỗi a và trước khi tài sản chuỗi b đến tài khoản, cầu nối chuỗi chéo được xử lý giống như một hệ thống chuỗi khối độc lập, yêu cầu cơ chế đồng thuận, thường sử dụng dpos và tất cả những điều sau đây được giả định là sử dụng dpos Các vấn đề cần được xem xét, nhưng tôi nghi ngờ rằng tất cả các nút đều thuộc về phía dự án và có nguy cơ tập trung hóa ngay từ đầu.

a) Để giám sát các thông báo gửi tiền xu, ai sẽ là người đầu tiên bắt đầu đề xuất xử lý chuỗi chéo một cách ngẫu nhiên? Hay thay phiên nhau? Hoặc theo thứ tự của các khối được tạo bởi lớp đồng thuận trung gian?

b) Làm thế nào để nhiều công chứng viên xác minh tính chính xác của tiền gửi? Nếu tất cả các nguồn dữ liệu đều từ các nhà cung cấp dữ liệu như infura, thì infura là một điểm rủi ro duy nhất. Điều an toàn nhất là duy trì các nút của riêng họ, việc này tốn rất nhiều chi phí.

c) Cách xác nhận rằng quá trình xử lý chuỗi chéo đã hoàn tất (b đã được tải lên tài khoản) và có một số tình huống trong đó quá trình xử lý chưa hoàn tất:

i. Cầu liên chuỗi không bắt đầu xử lý

ii. Cầu liên chuỗi đã bắt đầu xử lý, nhưng quá trình xác minh và đồng thuận không thành công

iii. Quá trình xác minh cầu xuyên chuỗi được thông qua, nhưng không có giao dịch nào được bắt đầu trên chuỗi b

iv. b Có một giao dịch trên chuỗi nhưng không thành công (không đủ tiền hoặc các trường hợp khác)

(3) Vấn đề xác minh đa chữ ký

Các khu vực bị ảnh hưởng nặng nề nhất với các sự cố thường xuyên, hầu hết là các sự cố logic mã

a) 3/5 chữ ký, mình dựng ngẫu nhiên các chữ ký không có trong danh sách đa chữ ký, nó cũng là +1 (chainswap).

b) Vấn đề tập trung hóa, trên danh nghĩa là đa chữ ký, thực chất nằm trong tay của bên dự án, điều này tiềm ẩn nguy cơ tập trung hóa rất lớn.

c) Phương thức xác minh chữ ký, chế độ phát triển trên các chuỗi khác nhau là khác nhau, điều này chắc chắn sẽ khiến các nhà phát triển bỏ lỡ khi kết nối, ví dụ về lỗ sâu: chức năng xác minh chữ ký trên solana là một chức năng trong hợp đồng hệ thống và hợp đồng hệ thống nên được gọi bình thường , địa chỉ của hợp đồng hệ thống phải được mã hóa cứng trong mã. Tại đây, chúng chuyển địa chỉ hợp đồng hệ thống làm tham số. Khi tin tặc rút tiền, anh ta sẽ chuyển một địa chỉ hợp đồng hệ thống giả, địa chỉ này bỏ qua xác minh chữ ký và rút tiền tiền tệ trơn tru. .

(4) Hoàn tiền

a) Như đã thảo luận trong (2)-c, có nhiều khả năng xảy ra trạng thái chuỗi chéo. Trong mọi trường hợp, cần cung cấp cho người dùng phương thức hoàn tiền. Ví dụ: khi anyswap gửi tiền, trước tiên nó sẽ gửi cho người dùng anyToken , sau đó gửi anyToken cho người dùng trên chuỗi mục tiêu, sau đó ghi bất kỳToken nào của chuỗi nguồn. Mục đích của việc này là bất kể vấn đề ở đâu, người dùng có thể đại diện cho tài sản của chính họ bằng cách nắm giữ anyToken. Có 3 chuỗi (nguồn, đích, cầu nối chuỗi chéo) và 4 tài sản (Mã thông báo gốc/bất kỳToken nào trên chuỗi nguồn và chuỗi đích) trong quá trình này, rất dễ xảy ra các vấn đề về logic mã.

b) Lỗ hổng của Thorchain được tiết lộ vào ngày 23 tháng 7 năm 2021. Hacker đã sử dụng các vấn đề logic mã để tạo ra một lượng lớn tiền nạp giả mạo, cầu xuyên chuỗi không xử lý được nên đã nhập logic hoàn tiền khiến hacker lấy được một khoản tiền khổng lồ đền bù.

2: Các rủi ro bảo mật khác

Nhưng các vấn đề có thể được hiển thị thông qua quy trình logic chỉ là các vấn đề logic nghiệp vụ, không phải tất cả chúng.

Từ quan điểm bảo mật, chúng ta cũng nên xem xét ba rủi ro khác:

(1) Rủi ro hệ thống

Ví dụ: tiền gửi của chuỗi ban đầu đã thành công ngay từ đầu, sau đó được khôi phục, đây là một vấn đề lớn. V Chúa đã thảo luận rằng tài sản được chuyển từ Solana sang Ethereum, sau khi hoàn thành chuỗi chéo, Solana sẽ khôi phục lại và tài sản của người dùng sẽ tăng gấp đôi.

Nhưng lớp 2, chẳng hạn như rollup, chia sẻ bảo mật với Ethereum, không gặp phải vấn đề này.

(2) Rủi ro từ phía trước

a) URL giả mạo, chẳng hạn như oxdao.fi 0xdao.fi oxdai.fi, v.v.

b) Tấn công xss, tức là tấn công cross- site scripting, là tấn công chèn mã, chẳng hạn như www. Chú ý đề phòng xss, mã này sẽ được thực thi trên trang khiến người dùng ủy quyền cho chữ ký chuyển của tin tặc giao dịch, vì vậy không mở liên kết từ các nguồn không xác định.

c) Tấn công dịch vụ chéo trang Cors.Theo chính sách cùng nguồn gốc nghiêm ngặt, các trình duyệt chỉ được phép tải nội dung từ trang này, nghĩa là tất cả nội dung hiển thị trên trang www.xxxx.finance và giao diện được gọi phải đến từ xxxx .Tài chính tên miền, nhưng hầu hết các dự án hiện tại đều cho phép gọi chéo trang, tức là giao diện người dùng xxxx có thể gọi giao diện hoán đổi nhanh và ngược lại, điều này mang lại sự thuận tiện cho quá trình phát triển nhưng cũng mang lại rủi ro:

Nếu tôi truy cập xxxx.finance, lưu trữ một số dữ liệu nhạy cảm trong bộ đệm của trình duyệt, sau đó tôi truy cập một trang web độc hại, nếu chính sách cùng nguồn gốc của xxxx không bị hạn chế, trang web độc hại này có thể tự do lấy dữ liệu được lưu trữ trong bộ đệm của xxxx .

(3) Rủi ro của các chức năng bổ sung

Một số dự án cầu nối chuỗi chéo không chỉ cung cấp tài sản xuyên chuỗi mà còn cung cấp các lệnh gọi hợp đồng xuyên chuỗi, điều này làm tăng thêm độ phức tạp.

Kẻ tấn công bắt đầu gọi hợp đồng x trên chuỗi b trên chuỗi a và cầu liên chuỗi gọi nó trực tiếp bất kể hợp đồng x. Thật bất ngờ, hợp đồng x là hợp đồng nhiều chữ ký của cầu liên chuỗi trên chuỗi b. Đó là thay đổi tài khoản đa chữ ký thành địa chỉ của chính kẻ tấn công. Sau khi thực hiện thành công, tin tặc có thể tự do kiểm soát tiền của cầu nối chuỗi trên b-chain (mạng poly).

Ba: Kết luận

1: Mục đích của báo cáo này là giúp người dùng hiểu rõ hơn về các rủi ro bảo mật của các cầu nối chuỗi chéo và nó không phải là biểu hiện độc hại về mức độ dễ bị tấn công của các cầu nối chuỗi chéo.

2: Giải pháp bắc cầu xuyên chuỗi của cơ chế công chứng là giải pháp 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 ít nhất cho đến thời điểm hiện tại. Và bất kỳ sản phẩm nào cũng sẽ trải qua quá trình từ sơ khai đến trưởng thành và các cuộc tấn công vào các sản phẩm blockchain thường là "các vấn đề logic". Những câu hỏi này chắc chắn sẽ trở nên tốt hơn theo thời gian và kinh nghiệm.