Tại sao lại có nhiều vụ tai nạn cấp độ thấp trên cầu xuyên chuỗi?

Tiêu đề gốc: "Tại sao lại có nhiều tai nạn trên cầu xuyên xích?" 》

Tác giả gốc: Nhóm 0xScope

Lời nói đầu

Tần suất gần đây Các vấn đề bảo mật chuỗi chéo xuất hiện đã 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 độc giả biết lý do tại sao có rất nhiều vấn đề về bảo mật sản phẩm trong hướng này. Cần lưu ý rằng các vấn đề được chỉ ra trong bài viết không tồn tại ở mọi dự án, hầu hết các vấn đề đều đã có chiến lược ứng phó phù hợp trong quá trình thiết kế. Mục đích chính của bài viết này là hy vọng rằng nhiều người có thể hiểu được đường đi phức tạp này.

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

1: Một giải pháp chuỗi chéo không thay đổi

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

(1) Chuỗi bên

Tính bảo mật của sơ đồ chuỗi bên giữa ba sơ đồ này Cao nhất, chẳng hạn như các parachain cuộn tròn và chấm bi khác nhau. Bảo mật được chia sẻ giữa chuỗi chính và chuỗi bên.

Tuy nhiên, các giải pháp chuỗi bên 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 kịch bản áp dụng hơn nhiều. Đây cũng là lý do tại sao V God đồng ý với multi-chain nhưng không tán thành cross-chain, bởi vì các giải pháp cross-chain không thể chia sẻ bảo mật thì quá rắc rối.

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

Giải pháp này được biết đến như là giải pháp điểm tới tốt nhất -point Solution: Một giải pháp chuỗi chéo không đồng nhất tập trung, 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 thấp. Và khi chúng ta 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 ta 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 hiện là chuỗi chéo không đồng nhất được sử dụng phổ biến nhất Giải pháp cầu nối, 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 xuất xứ, gần như không có sự khác biệt về mặt thiết kế sản phẩm. Sự khác biệt chính có thể tập trung vào 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. Sự khác biệt về trải nghiệm sử dụng và độ an toàn cũng không lớn. Vì vậy, nhìn từ góc độ bảo mật, những rủi ro bảo mật gặp phải cũng có nhiều điểm tương đồng.

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

2: Quy trình logic sản phẩm của cơ chế công chứng

Hiểu được những thách thức mà công chứng viên phải đối mặt cơ chế Trước khi thảo luận về các rủi ro khác nhau, trước tiên chúng ta cần hiểu logic thiết kế chính của loại giải pháp này từ góc độ sản phẩm.

(1) Mô tả ngắn gọn

Từ góc độ triết lý thiết kế, giải pháp này thực chất là rất đơn giản. Khi chúng ta đối mặt với nhu cầu về tài sản không đồng nhất trên chuỗi chéo, 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 phải di chuyển nội dung về mặt vật lý hoặc phát hành lại chúng trên Fantom (điều mà chúng tôi không thể làm). Thay vào đó, ETH của người dùng A trước tiên được lưu trữ ở một địa chỉ không thể di chuyển và sau đó tài sản được ánh xạ 1: 1 tương ứng sẽ được phát hành trên Fantom dựa trên 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ạ thể hiện quyền sử dụng của những ETH đó trên chuỗi Ethereum ban đầu. Nhờ tỷ lệ 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 chuỗi chéo đơn giản nhất

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

Sẽ có nhiều vấn đề ở đây, trong đó lớn nhất là việc quản lý ví đa chữ ký, vì ETH được gửi khi chuyển từ Ethereum sang Fantom và nếu người dùng A muốn chuyển trở lại Điều đó 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 những khó khăn lớn nhất.

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

2: Ai sẽ khởi xướng nó?

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

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

5: Làm thế nào để xác nhận rằng tiền của người dùng thực sự là số tiền mà 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 giao dịch thất bại?

8: Người quản lý có nhiều chữ ký phạm tội thì phải làm sao?

9: Tôi nên làm gì nếu có thời gian ngừng hoạt động?

Tôi không dám nghĩ tới, càng nghĩ càng thấy phức tạp. Công nghệ cầu nối chuỗi chéo không chỉ liên quan đến việc ký nhiều chữ ký mà còn liên quan đến việc 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 sự hiểu biết của người dùng, tôi sẽ giải thích toàn bộ quy trình chuỗi chéo thành hai phần: gửi tiền và rút tiền. Để giúp mọi người hiểu rõ hơn:

(3) Tinh chỉnh thêm quy trình 

1: Gửi tiền

Trước hết xin khẳng định rằng quy trình vẽ trong hình bên dưới chỉ là suy luận của riêng tôi thiết kế. Kế hoạch chưa được chứng minh cẩn thận. Mục đích là để khám phá các vấn đề an toàn có thể xảy ra trong logic thiết kế. Nó không thể được thông qua như một kế hoạch hoàn chỉnh. Tất cả đều vô nghĩa.

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

(1) Người dùng Nạp tiền vào địa chỉ ký quỹ

(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 chữ ký của Tính chính xác của BP

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

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

(6) BP xác nhận giao dịch gửi tiền

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

Điều quan trọng cần lưu ý là quy trình này được thiết kế để thảo luận về các chuỗi chéo không đồng nhất nói chung, do đó, so với bất kỳ giải pháp trao đổi nào và các giải pháp khác, có 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 chuỗi không đồng nhất khác nhau mang thông tin khác nhau gắn liền với các giao dịch. Để xử lý nó một cách thống nhất, trước tiên hãy để người dùng liên kết mối quan hệ ánh xạ.

Nếu tất cả giao dịch trên chuỗi EVM đã được xử lý thì không cần thực hiện bước này mà chỉ cần đính kèm địa chỉ chuỗi mục tiêu khi bắt đầu giao dịch.

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

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

(1) Sau khi giám sát giao dịch, hãy xác minh nguồn gốc của tài sản Xác minh các giao dịch trong chuỗi mục tiêu được ánh xạ và chuyển giao cho người dùng A

(2) Bắt đầu giao dịch trong 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 đề về nạp tiền giả, cũng như các vấn đề xử lý đặc biệt cần thiết khi gọi các mã thông báo khác nhau. Để tóm tắt rõ hơn những rủi ro bảo mật có thể phát sinh trong tương lai, trước tiên 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 được chứng minh Đó là logic của việc trao đổi tài sản được ánh xạ của chuỗi mục tiêu trở lại tài sản của chuỗi ban đầu. Điều quan trọng cần lưu ý là nhiều mã thông báo hiện có phiên bản của nhiều chuỗi, có nghĩa là nhiều mã thông báo có mã thông báo gốc trên nhiều chuỗi. Vì vậy, một số dự án cầu thường thiết lập nhóm tài sản. Khi nguồn vốn đủ, người dùng sẽ không cảm nhận được sự tồn tại của các tài sản được ánh xạ như AnyDAI mà sẽ trực tiếp chuyển sang phiên bản chuỗi mục tiêu của mã thông báo, nhưng điều này không ảnh hưởng đến logic tổng thể. Vì vậy, quá trình phân tích tiếp tục:

Như hình: quy trình giao dịch rút coin từ chuỗi mục tiêu về chuỗi ban đầu như sau:

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

(2) Xác minh danh tính của BP và một BP nhất định sẽ bắt đầu một giao dịch yêu cầu rút tiền

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

(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ó vấn đề như lỗi xác minh nút hoặc thời gian ngừng hoạt động, nó cần được khôi phục và khởi tạo lại

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

(1) Xác minh việc khởi tạo và chữ ký quyền

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

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

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

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

(1) Gửi tiền

a)  Lỗ hổng cấp phép trong hợp đồng đặt cọc khiến số tiền gửi được chuyển trực tiếp. Đây là một vấn đề ngu ngốc mà hầu hết 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 không xác minh tính xác thực của chuỗi chéo Mã thông báo. Xác minh giới tính 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ả. Các tài sản gốc như ETH khác với hợp đồng ERC20. Nhiều cuộc tấn công là do xử lý ETH không đúng cách, dẫn đến ETH giả -> ETH thật. Đây là lý do tại sao các tài sản được bao bọc như vậy vì WETH rất phổ biến. (thorchain)

d) Mặc dù các Token khác nhau đều là tiêu chuẩn ERC20, nhưng phương pháp triển khai cụ thể của chúng là khác nhau hoặc chúng 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 thích ứng. Ví dụ (WETH, PERI, OMT, WBNB, MATIC, AVAX), v.v., sau khi quá trình chuyển hoàn tất, chức năng dự phòng tùy chỉnh của người gửi sẽ được gọi tới thực hiện các hoạt động bổ sung, tăng cường Loại bỏ sự phức tạp của việc phán đoán cầu nối chuỗi chéo (anyswap 2022.1.18)

(2) Chuỗi chéo chuyển tin nhắn

Sau khi hoàn tất việc gửi tiền của chuỗi A và trước khi tài sản của chuỗi B đến, cầu nối chuỗi chéo sẽ được xử lý giống như một hệ thống blockchain độc lập, nghĩa là cần có cơ chế đồng thuận, thường sử dụng dpos. Sau đây là những vấn đề cần được xem xét nếu sử dụng dpos, 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 tin nhắn gửi tiền, ai sẽ là người đầu tiên khởi xướng đề xuất xử lý chuỗi chéo, ngẫu nhiên? Hoặc thay phiên nhau? Hoặc tuân theo thứ tự sản xuất khối ở lớp đồng thuận giữa?

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

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

i. Cầu nối chuỗi chéo không bắt đầu xử lý

ii. Cầu nối chuỗi chéo không bắt đầu xử lý

ii. Cầu nối chuỗi chéo không bắt đầu xử lý cầu nối 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. Xác minh cầu nối chuỗi chéo đã được thông qua nhưng không có giao dịch nào được bắt đầu trên chuỗi b

iv.  Đã có một giao dịch trên chuỗi b nhưng không thành công (không đủ tiền hoặc các lý do khác)

iv.p>

(3) Multi- vấn đề xác minh chữ ký

Vấn đề Hầu hết các lĩnh vực bị ảnh hưởng nặng nề nhất là vấn đề logic mã

a) 3/5 chữ ký, tôi tạo ngẫu nhiên một chữ ký không có trong danh sách nhiều chữ ký, nó cũng được tính là +1 (chainswap).

b) Vấn đề tập trung hóa tên thì có nhiều chữ ký nhưng thực chất nó nằm trong tay của bên dự án nên dẫn đến rủi ro tập trung rất lớn .

c) Phương thức xác minh chữ ký, mô hình phát triển trên các chuỗi khác nhau là khác nhau, dẫn đến việc nhà phát triển không tránh khỏi thiếu sót khi kết nối, ví dụ về lỗ sâu: solana Chữ ký xác minh chức năng bật là một chức năng trong hợp đồng hệ thống. Thông thường, nên gọi hợp đồng hệ thống. Địa chỉ của hợp đồng hệ thống phải được mã hóa cứng trong mã. Ở đây, chúng chuyển địa chỉ hợp đồng hệ thống dưới dạng tham số, thông số này được truyền khi hacker rút tiền. Với địa chỉ hợp đồng hệ thống giả, xác minh chữ ký đã được bỏ qua và tiền đã được rút thành công.

(4) Hoàn tiền

a) Như đã thảo luận trong (2)-c, có nhiều khả năng cho trạng thái chuỗi chéo. Trong mọi trường hợp, người dùng cần được cung cấp phương thức hoàn tiền. Ví dụ: Anyswap sẽ gửi tiền trước tiên vào chuỗi nguồn khi gửi tiền coins. Gửi AnyToken cho người dùng, sau đó gửi AnyToken cho người dùng trên chuỗi mục tiêu và sau đó ghi AnyToken từ 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 mà anh ta nắm giữ đang nắm giữ bất kỳToken nào. Có 3 chuỗi (nguồn, đích, cầu nối chuỗi) và 4 nội dung (Token/anyToken gốc 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) Thorchain đã công bố tin tức vào ngày 23/7/2021 Sơ hở, hacker đã lợi dụng vấn đề logic mã để tạo ra một khoản nạp tiền giả khổng lồ, cầu nối chuỗi chéo không thể xử lý được nên logic hoàn tiền đã nhập vào khiến hacker nhận được số tiền hoàn lại khổng lồ.

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

Tuy nhiên , những vấn đề có thể hiển thị qua quy trình logic chỉ là những vấn đề logic nghiệp vụ chứ không phải tất cả.

Từ góc độ bảo mật, chúng ta cũng nên xem xét ba khía cạnh khác của rủi ro:

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

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

Nhưng ví dụ: rollup, lớp 2 chia sẻ bảo mật với Ethereum, sẽ không gặp phải vấn đề này.

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

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

b) Tấn công Xss, còn được gọi là tấn công tập lệnh chéo trang, là một cuộc tấn công tiêm mã, chẳng hạn như www.xxxx.finance/?params=hackerscode12345, Mặc dù URL thực sự là URL chính thức nhưng mã của hacker vẫn được mang trong URL. Nếu người phát triển front-end không chú ý Để ngăn chặn XSS, mã này sẽ xuất hiện trên trang, khi thực thi vào, người dùng sẽ ủy quyền chữ ký cho giao dịch chuyển tiền của hacker, do đó không nên mở các liên kết từ nguồn không xác định.

c) Cors Tấn công dịch vụ chéo trang, trong chính sách xuất xứ nghiêm ngặt, trình duyệt chỉ cho phép tải nội dung từ trang này, tức là www.xxxx.finance Tất cả nội dung hiển thị trên trang web và các giao diện được gọi phải đến từ xxxx. Finance tên miền nhưng hiện tại hầu hết các dự án đều cho phép gọi cross-site, tức là front end xxxx có thể gọi giao diện quickswap và ngược lại, điều này mang lại sự thuận tiện cho việc phát triển nhưng cũng mang lại rủi ro:

Giả sử tôi truy cập xxxx.finance và 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 URL độc hại. Nếu chính sách cùng nguồn gốc của xxxx không có hạn chế, thì URL độc hại này có thể tự do lấy dữ liệu của xxxx được lưu trữ trong bộ đệm.

(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 lệnh gọi hợp đồng x trên chuỗi b trên chuỗi a. Cầu nối chuỗi chéo trực tiếp gọi hợp đồng x bất kể nó là gì. Thật bất ngờ, hợp đồng x đã bị chéo -chain. Hợp đồng nhiều chữ ký của cây cầu trên chuỗi b. Cuộc gọi này nhằm thay đổi tài khoản nhiều 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, hacker có thể tự do kiểm soát số tiền của cầu nối chuỗi trên chuỗi b (mạng đa ).

Ba: Kết luận

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

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

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia