Hướng dẫn bảo mật hệ sinh thái Cosmos: Giải mã các kịch bản bảo mật của các thành phần khác nhau của Hệ sinh thái Cosmos

Bài viết này không chỉ phân tích các lỗ hổng bảo mật lớn trước đây trong hệ sinh thái Cosmos mà còn phân loại một số lỗ hổng bảo mật phổ biến theo nguyên nhân, tác động, vị trí mã, v.v., để cung cấp hướng dẫn bảo mật cho các nhà phát triển hệ sinh thái Cosmos ở mức độ lớn nhất , đồng thời cung cấp kiến thức và hướng dẫn cho người kiểm tra bảo mật.Kiểm tra dữ liệu chỉ mục về các vấn đề bảo mật của Cosmos.

**Tiêu đề gốc: “CertiK Độc quyền: Giải mã an ninh sinh thái vũ trụ và tạo điều kiện thuận lợi cho hành trình giữa các vì sao Web3” **

Người viết: CertiK

*Là một trong những hệ sinh thái blockchain lớn nhất và nổi tiếng nhất trên thế giới, Cosmos tập trung vào việc cải thiện khả năng tương tác của blockchain và đạt được khả năng tương tác hiệu quả giữa các blockchain khác nhau. Một loạt dự án chính bao gồm Celestia và dYdX v4 được xây dựng dựa trên giao thức Cosmos SDK và IBC. *

*Vì các thành phần phát triển của Cosmos được nhiều nhà phát triển ưa chuộng hơn nên các vấn đề bảo mật trong hệ sinh thái Cosmos chắc chắn sẽ có tác động rộng hơn. Ví dụ: lỗ hổng Dragonfruit trong Cosmos SDK trước đây đã ảnh hưởng đến hoạt động bình thường của nhiều chuỗi công khai chính thống. Do tính chất phi tập trung của các thành phần cơ bản của hệ sinh thái Cosmos nên các nhà phát triển cần sử dụng hoặc mở rộng các thành phần khác nhau tùy theo yêu cầu chức năng khác nhau, dẫn đến vấn đề bảo mật trong hệ sinh thái Cosmos cũng phân tán và đa dạng. Một nghiên cứu giúp các nhà phát triển hiểu rõ về mặt cấu trúc hiện trạng và các biện pháp đối phó với an ninh sinh thái Cosmos là rất cần thiết. *

“Hướng dẫn bảo mật hệ sinh thái Cosmos” do nhóm CertiK phát hành độc quyền nêu chi tiết các kịch bản bảo mật của các thành phần khác nhau của hệ sinh thái Cosmos thông qua các phân loại thân thiện với người đọc*. Báo cáo này không chỉ bao gồm việc phân tích các lỗ hổng bảo mật lớn trước đây trong hệ sinh thái Cosmos mà còn phân loại một số lỗ hổng bảo mật phổ biến theo nguyên nhân, hậu quả, vị trí mã, v.v. để cung cấp hướng dẫn bảo mật cho các nhà phát triển hệ sinh thái Cosmos ở mức độ lớn nhất, và cung cấp kiến thức cũng như hướng dẫn cho người kiểm tra bảo mật.Kiểm tra dữ liệu chỉ mục về các vấn đề bảo mật của Cosmos. *

*Nhóm CertiK đã và đang giúp cải thiện an ninh sinh thái của Cosmos và toàn bộ Web3 thông qua nghiên cứu và khai thác liên tục. Chúng tôi sẽ thường xuyên mang đến cho bạn các báo cáo an toàn dự án và nghiên cứu kỹ thuật khác nhau, vui lòng tiếp tục chú ý! Nếu bạn có bất kỳ câu hỏi nào, bạn có thể liên hệ với chúng tôi bất cứ lúc nào. *

*Sau đây là toàn văn của "Hướng dẫn An ninh Sinh thái Vũ trụ"👇. *

Tổng quan

Cosmos là một mạng chuỗi chuỗi khối mã nguồn mở, mở, có khả năng mở rộng cao và là một trong những hệ sinh thái chuỗi khối nổi tiếng nhất trên thế giới. Cosmos là một mạng không đồng nhất được ra mắt bởi CometBFT (trước đây là nhóm Tendermint) hỗ trợ tương tác xuyên chuỗi. Nó bao gồm nhiều chuỗi khối độc lập và song song để tạo thành một mạng phi tập trung. Tầm nhìn của nó là phá vỡ hiệu ứng đảo của thông tin và hiện thực hóa các khối khác nhau Khả năng tương tác giữa các chuỗi. Trong kỷ nguyên đa chuỗi hiện nay, việc hiện thực hóa sự tương tác giữa các chuỗi đã trở thành một nhu cầu cấp thiết trong ngành công nghiệp blockchain.

Cosmos cung cấp mô hình chuỗi chéo hiệu quả, đặc biệt phù hợp cho các chuỗi công khai tập trung vào các lĩnh vực dọc cụ thể. Bằng cách cung cấp cơ sở hạ tầng blockchain mô-đun, Cosmos mang đến sự thuận tiện cho các nhà phát triển ứng dụng trong việc lựa chọn và sử dụng chuỗi công khai đáp ứng nhu cầu của họ.

Các ứng dụng và giao thức trong hệ sinh thái Cosmos được kết nối bằng IBC (Giao thức liên lạc giữa các chuỗi khối), cho phép tương tác chuỗi chéo giữa các chuỗi khối độc lập, cho phép tài sản và dữ liệu được lưu chuyển tự do. Tầm nhìn của Cosmos là xây dựng một mạng lưới các chuỗi khối cung cấp khả năng cho một số lượng lớn các chuỗi khối tự trị, dễ phát triển để mở rộng quy mô và tương tác.

Trong một thời gian dài, CertiK luôn quan tâm và nghiên cứu đầy đủ về môi trường sinh thái Cosmos. Chúng tôi đã tích lũy đủ kinh nghiệm về các vấn đề an ninh sinh thái Cosmos. Trong báo cáo nghiên cứu này, chúng tôi sẽ giới thiệu kết quả thăm dò và nghiên cứu về bảo mật hệ sinh thái Cosmos, chủ yếu tập trung vào bảo mật Cosmos SDK, bảo mật giao thức IBC và bảo mật CometBFT. Và bốn hướng của bảo mật CosmWasm, đối tượng thảo luận sẽ mở rộng từ các thành phần cơ bản của Cosmos đến chuỗi cơ bản hoặc chuỗi ứng dụng của Cosmos. Thông qua việc phân tích và mở rộng các vấn đề tương tự, chúng tôi sẽ giới thiệu cho độc giả về hệ sinh thái Cosmos theo cách từ dưới lên cách thức.Các điểm bảo mật liên quan đến chính chuỗi đó.

Do tính phức tạp và đa dạng của hệ sinh thái Cosmos nên các vấn đề bảo mật hiện tại cũng có những đặc điểm đa dạng nên báo cáo nghiên cứu này không đề cập hết tất cả các loại lỗ hổng bảo mật ** Nó chỉ đề cập đến những đặc điểm điển hình hơn và sự tồn tại của hệ sinh thái Cosmos chain. Nhiều lỗ hổng nguy hiểm hơn**. Nếu bạn muốn biết thêm chi tiết về các vấn đề bảo mật khác, vui lòng liên hệ với các kỹ sư bảo mật của CertiK để thảo luận.

lý lịch

• CometBFT: Nền tảng của khả năng mở rộng chuỗi chéo

CometBFT là một thuật toán đồng thuận sáng tạo, bao gồm hai thành phần chính: công cụ đồng thuận cơ bản (CometBFT Core) và giao diện chuỗi khối ứng dụng phổ quát (ABCI). Thuật toán đồng thuận của nó áp dụng cơ chế đồng thuận lai PBFT+Bonded PoS để đảm bảo rằng các nút ghi lại các giao dịch một cách đồng bộ. Là thành phần cốt lõi của khả năng mở rộng của Interchain, CometBFT duy trì tính bảo mật, phân cấp và tính toàn vẹn của hệ sinh thái Interchain thông qua sự đồng thuận của người xác thực.

• Cosmos SDK: Tính mô đun và các tính năng mới

Cosmos SDK là bộ công cụ giúp các nhà phát triển đẩy nhanh quá trình phát triển và cung cấp các tính năng mô-đun và có thể cắm được. Sử dụng Cosmos SDK, các nhà phát triển có thể xây dựng chuỗi khối hoặc các thành phần chức năng của riêng mình dựa trên thuật toán đồng thuận CometBFT. Đạt được sự phát triển thuận tiện và rút ngắn thời gian phát triển xe đạp. Nó hiện được áp dụng trong nhiều dự án blockchain như Cronos, Kava và dYdX V4 mới ra mắt gần đây. Các kế hoạch phát triển trong tương lai sẽ tập trung vào mô-đun hóa và giới thiệu các tính năng mới để cho phép các nhà phát triển tạo ra các ứng dụng mô-đun phức tạp hơn và phát triển một hệ sinh thái rộng hơn và mạnh mẽ hơn.

• Giao thức IBC: Khả năng tương tác và mở rộng nâng cao

Giao thức IBC (Giao thức truyền thông liên chuỗi khối) cho phép truyền dữ liệu an toàn, phi tập trung và không cần cấp phép giữa các chuỗi khối. Vì Cosmos là một mạng lưới phi tập trung bao gồm nhiều chuỗi khối độc lập và song song, đồng thời sử dụng công nghệ chuyển tiếp để hiện thực hóa các chuỗi chéo giữa các chuỗi khối khác nhau, nên có thể nói IBC là phần cốt lõi của toàn bộ dự án. Quỹ Interchain hiện đang tập trung vào hai chủ đề: khả năng mở rộng và khả năng sử dụng. Bằng cách cải thiện khả năng mở rộng và khả năng tương tác của IBC, Cosmos sẽ nâng cao hơn nữa năng lực của hệ sinh thái của mình, cho phép tương tác liền mạch giữa các chuỗi khối, ứng dụng và hợp đồng thông minh.

• CosmWasm: Mở khóa hoạt động triển khai phi tập trung, không cần cấp phép

CosmWasm (Cosmos WebAssembly) là khung hợp đồng thông minh dựa trên WebAssembly được thiết kế dành riêng cho hệ sinh thái Cosmos. Nó cho phép các nhà phát triển triển khai các ứng dụng phi tập trung mà không cần yêu cầu cấp phép, đồng thời cho phép các nhà phát triển blockchain tách chu trình phát triển sản phẩm của họ khỏi phát triển blockchain, từ đó giảm chi phí nâng cấp trình xác nhận. Ngoài ra, nó còn có kiến trúc mô-đun, tích hợp Cosmos SDK, giao tiếp chuỗi chéo và các tính năng khác.

Tính đến thời điểm hiện tại, Cosmos SDK và giao thức IBC đã tương đối hoàn thiện và được sử dụng rộng rãi nhất trong hệ sinh thái Cosmos hiện tại.

Từ quan điểm của các nhà phát triển chuỗi, hầu hết các chức năng tùy chỉnh mà chuỗi sinh thái hiện tại trên Cosmos yêu cầu đều có thể được hoàn thành bằng cách dựa vào Cosmos SDK để đạt được một số hoạt động đặc biệt trong quy trình vận hành chuỗi chéo hoặc nhằm mục đích tối ưu hóa hiệu suất, v.v., các nhà phát triển chuỗi sẽ tùy chỉnh các mô-đun IBC của riêng họ. Ngoài ra, một số ít chuỗi sẽ sửa đổi và tùy chỉnh các công cụ cơ bản như CometBFT Core. Do hạn chế về không gian, báo cáo nghiên cứu này sẽ không được thực hiện trong thời gian này Báo cáo nghiên cứu này sẽ tập trung phân tích các điểm kỹ thuật và vấn đề bảo mật của Cosmos SDK và giao thức IBC.

Hướng dẫn bảo mật Cosmos SDK

SDK Cosmos là một khuôn khổ mạnh mẽ và linh hoạt để xây dựng các ứng dụng blockchain và các giao thức phi tập trung. Được phát triển bởi Interchain Foundation, nó là thành phần cốt lõi của Mạng Cosmos, một mạng lưới phi tập trung gồm các chuỗi khối được kết nối với nhau.

SDK Cosmos được thiết kế để đơn giản hóa việc phát triển các ứng dụng blockchain tùy chỉnh và cho phép khả năng tương tác liền mạch giữa các blockchain khác nhau. Cosmos SDK chủ yếu có các tính năng sau: Kiến trúc mô-đun, khả năng tùy chỉnh, dựa trên CometBFT, triển khai giao diện tương ứng IBC và thân thiện với nhà phát triển. Cosmos SDK đảm bảo tính bảo mật mạnh mẽ bằng cách tận dụng công cụ đồng thuận cơ bản CometBFT Core để bảo vệ mạng khỏi các cuộc tấn công độc hại và cung cấp sự bảo vệ cho tài sản và dữ liệu của người dùng. Ngoài ra, tính mô-đun của nó cho phép người dùng dễ dàng thiết kế các mô-đun tùy chỉnh. Bất chấp những ưu điểm này, các lỗ hổng bảo mật vẫn có thể tồn tại khi các nhà phát triển sử dụng Cosmos SDK để triển khai các ứng dụng của riêng họ.

Từ góc độ kiểm tra bảo mật, chúng ta cần phải toàn diện trong các mục tiêu kiểm tra và xem xét đầy đủ các rủi ro bảo mật từ mọi góc độ. Tuy nhiên, từ góc độ nghiên cứu bảo mật, chúng ta cần chú ý hơn đến các lỗ hổng bảo mật có thể gây ra tác động đáng kể. thời gian Tránh những mối nguy hiểm an toàn lớn nhất càng nhiều càng tốt trong một khoảng thời gian nhất định và cung cấp trợ giúp hiệu quả hơn cho nhà cung cấp dịch vụ tích hợp. Từ góc độ này, việc phân loại một số lỗ hổng có mức độ nguy hiểm cao, tác động lớn và phân tích các mô hình lỗ hổng của chúng** là rất cần thiết và có giá trị.

Trong số các giao diện ABCI trên toàn bộ hệ sinh thái Cosmos, chúng tôi tập trung vào bốn giao diện BeginBlock, EndBlock, CheckTx và DeliverTx. Hai giao diện đầu tiên liên quan trực tiếp đến logic thực thi của một khối duy nhất, trong khi hai giao diện sau liên quan đến việc thực thi sdk.Msg ( Hệ sinh thái vũ trụ Việc xử lý cụ thể cấu trúc dữ liệu cơ bản để truyền thông điệp).

Do logic triển khai của các chuỗi ứng dụng khác nhau trong hệ sinh thái Cosmos có thể dựa trên các mô-đun và mẫu tương tự như trong Cosmos SDK, nên khi phân tích và tìm hiểu các lỗ hổng bảo mật bên dưới, bạn cần có khái niệm cơ bản về quy trình chạy mô-đun của SDK vũ trụ.

Trong hệ sinh thái Cosmos, các giao dịch ban đầu được tạo trong tác nhân người dùng, sau đó được ký và phát đến các nút trong chuỗi khối. Các nút sử dụng phương thức CheckTx để xác minh các chi tiết giao dịch khác nhau như chữ ký, số dư của người gửi, trình tự giao dịch và lượng gas được cung cấp. Nếu giao dịch vượt qua quá trình xác minh, nó sẽ được thêm vào mempool, chờ được đưa vào một khối. Ngoài ra, nếu giao dịch không được xác minh, một thông báo lỗi sẽ được gửi đến người dùng khiến giao dịch bị từ chối. Trong quá trình thực thi khối, các giao dịch sẽ được kiểm tra thêm, được thực hiện thông qua phương thức DeliverTx, để đảm bảo tính nhất quán và tính hữu hạn.

Trong Cosmos SDK, vòng đời của một giao dịch có thể được mô tả ngắn gọn như quy trình sau:

**1. Tạo giao dịch: **Giao dịch được tạo ở phía khách hàng bằng nhiều công cụ khác nhau, CLI hoặc ở giao diện người dùng.

2. Thêm vào nhóm bộ nhớ: Giao dịch được thêm vào nhóm bộ nhớ nơi nút gửi thông báo ABCI -CheckTx đến lớp ứng dụng để kiểm tra tính hợp lệ và nhận kết quả abci.ResponseCheckTx. Trong CheckTx, giao dịch được giải mã từ định dạng byte sang định dạng Tx, sau đó ValidateBasic() được gọi trên mỗi sdk.Msg của Tx để thực hiện kiểm tra tính hợp lệ không trạng thái sơ bộ. Nếu ứng dụng có anteHandler tương ứng, trước tiên nó sẽ thực thi logic bên trong, sau đó gọi hàm runTx và cuối cùng gọi hàm RunMsgs() để xử lý nội dung cụ thể của sdk.Msg. Nếu CheckTx thành công, tin nhắn sẽ được thêm vào nhóm bộ nhớ cục bộ làm ứng cử viên cho khối tiếp theo và sẽ được phát tới các nút ngang hàng thông qua P2P.

**3 Bao gồm trong khối đề xuất: **Khi bắt đầu mỗi vòng, người đề xuất tạo một khối chứa giao dịch mới nhất và cuối cùng nút đầy đủ chịu trách nhiệm về trình xác thực đồng thuận, đồng ý chấp nhận khối hoặc bỏ phiếu cho giao dịch trống mảnh vùng.

**4. Thay đổi trạng thái: **DeliverTx được gọi để lặp lại các giao dịch trong khối, tương tự như CheckTx, nhưng nó gọi runTx ở chế độ Phân phối và thực hiện các thay đổi trạng thái. MsgServiceRouter được gọi để định tuyến các tin nhắn khác nhau trong giao dịch đến các mô-đun khác nhau, sau đó thực thi từng tin nhắn tương ứng trong Msg Server. Sau đó, quá trình kiểm tra sẽ được thực hiện sau khi thực hiện thông báo và nếu có lỗi, trạng thái sẽ được khôi phục. Trong quá trình thực hiện, hãy sử dụng đồng hồ đo Gas để theo dõi lượng nhiên liệu (gas) đã sử dụng. Nếu xảy ra bất kỳ lỗi nhiên liệu nào (ví dụ: nhiên liệu thấp), các thay đổi trạng thái sẽ được hoàn nguyên với hậu quả tương tự như sau khi thực thi không thành công.

5 Gửi khối: Khi một nút nhận đủ phiếu bầu của người xác thực, nó sẽ gửi một khối mới để được thêm vào chuỗi khối và hoàn tất quá trình chuyển đổi trạng thái trong lớp ứng dụng.

Sơ đồ vòng đời giao dịch trên hệ sinh thái Cosmos

Sau đây là logic thực thi cụ thể của Cosmos SDK, bạn có thể dễ dàng đọc và hiểu logic này khi phân tích đường dẫn kích hoạt lỗ hổng bên dưới:

Cosmos SDK tập trung vào logic thực thi cụ thể của ABCI

Phân loại lỗ hổng phổ biến

Trước khi hiểu cách phân loại lỗ hổng, chúng ta cần có sự phân loại cơ bản về mức độ dễ bị tổn thương, điều này sẽ giúp xác định tốt hơn các lỗ hổng bảo mật nguy hiểm và tránh được những rủi ro bảo mật tiềm ẩn một cách tối đa.

Xem xét mức độ nguy hiểm và phạm vi ảnh hưởng, chúng tôi chủ yếu tập trung vào các lỗ hổng bảo mật nghiêm trọng và được xếp hạng nghiêm trọng, thường có thể gây ra những rủi ro sau:

1. Dây chuyền ngừng chạy

2. Mất tiền

3. Ảnh hưởng đến trạng thái hệ thống hoặc hoạt động bình thường

Nguyên nhân của những nguy hiểm này thường là do các loại lỗ hổng bảo mật sau:

1. Từ chối dịch vụ

2. Cài đặt trạng thái sai

3. Thiếu xác minh hoặc không hợp lý

4. Vấn đề duy nhất

5. Vấn đề về thuật toán đồng thuận

6. Những lỗ hổng logic trong triển khai

7. Vấn đề đặc điểm ngôn ngữ

Phân tích lỗ hổng

Do tính đặc thù của mô-đun sinh thái Cosmos, có một số lượng lớn các trường hợp các mô-đun sử dụng lẫn nhau và gọi nhau trong các mô-đun trong các triển khai chuỗi khác nhau. Do đó, có những trường hợp đường dẫn kích hoạt lỗ hổng không nhất quán với đường dẫn có thể kiểm soát được của biến vị trí kích hoạt lỗ hổng. Chúng tôi đang phân tích lỗ hổng Khi xem xét các lý do kích hoạt cụ thể, chúng ta không chỉ nên tập trung vào đường dẫn kích hoạt mà còn vào đường dẫn có thể kiểm soát của các biến chính của lỗ hổng. Điều này có thể giúp chúng tôi xác định rõ hơn mô hình dễ bị tổn thương

Chuỗi ngừng chạy

Trong hầu hết các trường hợp, thủ phạm khiến chuỗi ngừng chạy là do sự cố trong quá trình thực thi một khối, tuy nhiên trong lịch sử phát triển của Cosmos cũng xuất hiện những lỗ hổng bảo mật đồng thuận khiến chuỗi phải chủ động dừng lại để sửa chữa. , do đó, tác động ở đây Các lỗ hổng bảo mật kiểu đồng thuận cũng được thảo luận về tác động khiến chuỗi ngừng chạy. Chúng ta sẽ thảo luận riêng về hai loại vấn đề này.

Loại tình huống đầu tiên là các lỗ hổng từ chối loại dịch vụ phổ biến. Các lý do cụ thể chủ yếu là do việc xử lý sự cố và hoạt động truyền tải không đúng cách trong đó ranh giới vòng lặp có thể bị ảnh hưởng bởi người dùng. Những lỗ hổng như vậy thường khiến chuỗi tạm dừng hoặc hoạt động chậm lại.

Như đã đề cập trong bài viết trước, Cosmos SDK và CometBFT là những cơ sở hạ tầng quan trọng trong hệ sinh thái Cosmos, không chỉ được sử dụng bởi chuỗi cơ bản trong Cosmos mà còn các chuỗi ứng dụng khác nhau cũng triển khai logic riêng dựa trên kiến trúc của chúng nên tất cả đều tuân thủ giao diện ABCI của CometBFT. Các quy tắc, Trọng tâm của bề mặt tấn công của nó cũng là trên giao diện ABCI và hầu hết các lỗ hổng bảo mật có thể gây ra Chain Halt đều là những vấn đề có thể ảnh hưởng trực tiếp đến việc thực thi mã khối, vì vậy đường dẫn xuất hiện của chúng về cơ bản có thể được truy tìm đến các giao diện BeginBlock và EndBlock.

Loại tình huống thứ hai là các lỗ hổng ảnh hưởng đến sự đồng thuận và thường liên quan đến việc triển khai các chuỗi khác nhau, hiện được biết là phổ biến trong một số vấn đề xác minh xử lý logic, hiệu chỉnh thời gian và tính ngẫu nhiên. Những lỗ hổng như vậy về cơ bản sẽ ảnh hưởng đến nguyên tắc phân cấp của blockchain, về mặt trực quan, chúng có thể không có nhiều tác động nhưng nếu được thiết kế độc hại thì vẫn sẽ gây ra rủi ro bảo mật lớn hơn.

Loại 1

• Trường hợp 1: Dự án SuperNova

Nền tảng lỗ hổng: Thiếu xác minh địa chỉ trong hoạt động phân phối tiền xu, dẫn đến lỗi hoạt động và mất tiền. Trong mô-đun đúc, mỗi lần đúc mã thông báo phụ thuộc vào số tiền đặt cược. Tuy nhiên, nếu nhóm không tồn tại hoặc địa chỉ hợp đồng được nhập không chính xác, hành vi không mong muốn có thể xảy ra trong mô-đun đúc tiền, khiến chuỗi khối ngừng hoạt động. Trong mô-đun nhóm phần thưởng, địa chỉ hợp đồng nhóm không được xác minh. Nếu hoạt động phân phối không thành công, chuỗi sẽ ngừng hoạt động.

Vị trí dễ bị tổn thương:

Đoạn mã dễ bị tổn thương:

Đường dẫn kích hoạt lỗ hổng:

BeginBlocker (/x/mint/keeper/abci.go)

Keeper.DistributeMintedCoin

Keeper.distributeLPIncentivePools

PoolIncentiveKeeper.GetAllIncentivePool (/x/mint/keeper/keeper.go)

Bản vá lỗ hổng:

Bản vá nằm trong mô-đun xử lý tin nhắn của poolincentive (x/poolincentive/types/msgs.go), không phải mô-đun mint.

Việc xác minh địa chỉ được thực hiện trên thông báo khi xử lý MsgCreateCandidatePool (nghĩa là tạo nhóm), nhằm loại trừ khả năng địa chỉ không chính xác từ nguyên nhân gốc rễ.

• Trường hợp 2: Dự án bảo mật Cosmos Interchain

địa chỉ dự án:

Nền tảng lỗ hổng bảo mật: Trình xác thực có thể làm chậm chuỗi cung cấp bằng cách gửi nhiều thông báoAssConsumerKey trong cùng một khối. Hàm Chỉ địnhConsumerKey được xác định trong x/ccv/provider/keeper/key_signment.go cho phép người xác thực chỉ định các ConsumerKey khác nhau cho chuỗi tiêu dùng đã được phê duyệt. Để thực hiện việc này, ConsumerAddrsToPrune addressList thêm một phần tử. Vì Danh sách địa chỉ này được duyệt qua EndBlocker trong x/ccv/provider/keeper/relay.go nên kẻ tấn công có thể sử dụng nó để làm chậm chuỗi nhà cung cấp. Để thực hiện cuộc tấn công này, kẻ tấn công độc hại có thể tạo các giao dịch với nhiều thông báoAssConsumerKey và gửi các giao dịch này đến chuỗi nhà cung cấp. Cơ sở của ConsumerAddrsToPrune addressList sẽ giống với thông báo GánConsumerKey được gửi. Kết quả là việc thực thi EndBlocker sẽ tốn nhiều thời gian và tài nguyên hơn dự kiến, khiến chuỗi cung cấp bị chậm lại hoặc thậm chí dừng lại.

Vị trí lỗ hổng:/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/provider/keeper/key_signment.go#L378

Đoạn mã dễ bị tổn thương:

Đường dẫn kích hoạt lỗ hổng:

msgServer.AssignConsumerKey

Keeper.AssignConsumerKey

AppModule.EndBlock

Cuối KhốiCIS

HandleLeadingVSCMatureGói

Xử lýVSCMatureGói

PruneKeyBài tập

• Trường hợp 3: Mô-đun Airdrop dự án Quicksilver

Bối cảnh lỗ hổng: BeginBlocker và EndBlocker là các phương pháp tùy chọn mà nhà phát triển mô-đun có thể triển khai trong mô-đun của họ. Chúng được kích hoạt ở đầu và cuối mỗi khối tương ứng. Việc sử dụng các sự cố để xử lý lỗi trong phương thức BeginBlock và EndBlock có thể khiến chuỗi bị dừng khi xảy ra lỗi. EndBlocker đã thanh lý các airdrop chưa hoàn thành mà không xem xét liệu mô-đun có đủ mã thông báo hay không để gây ra sự cố, khiến chuỗi ngừng chạy.

Vị trí lỗ hổng: ‍60f4047e2f2f403d67701b030e/x/airdrop/keeper/abci.go#L15

Đoạn mã dễ bị tổn thương:

Đường dẫn kích hoạt lỗ hổng:

AppModule.EndBlock

Keeper.EndBlocker

Keeper.EndZoneDrop

Bản vá lỗ hổng:

Mã xử lý hoảng loạn đã được loại bỏ trực tiếp và thay thế bằng ghi nhật ký lỗi.

• Trường hợp 4: Dự án bảo mật Cosmos Interchain

địa chỉ dự án:

Nền tảng lỗ hổng: Kẻ tấn công có thể thực hiện cuộc tấn công từ chối dịch vụ bằng cách gửi nhiều mã thông báo đến địa chỉ phần thưởng của chuỗi cung cấp.

Trong quy trình thực thi EndBlocker của chuỗi người tiêu dùng, hàm SendRewardsToProvider được xác định trong x/ccv/consumer/keeper/distribution.go lấy số dư của tất cả các mã thông báo trong tstProviderAddr và gửi chúng đến chuỗi nhà cung cấp. Để đạt được điều này, nó phải lặp qua tất cả các mã thông báo được tìm thấy trong địa chỉ phần thưởng và gửi chúng lần lượt đến chuỗi cung cấp thông qua IBC. Vì bất kỳ ai cũng có thể gửi mã thông báo đến địa chỉ phần thưởng, kẻ tấn công có thể tạo và gửi một số lượng lớn mã thông báo có mệnh giá khác nhau, ví dụ: sử dụng chuỗi có mô-đun nhà máy mã thông báo, để khởi động cuộc tấn công từ chối dịch vụ. Do đó, việc thực thi EndBlocker sẽ tốn nhiều thời gian và tài nguyên hơn dự kiến, khiến chuỗi tiêu thụ bị chậm lại, thậm chí dừng hẳn.

Vị trí lỗ hổng:/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/consumer/keeper/distribution.go#L103

Đoạn mã dễ bị tổn thương:

Đường dẫn kích hoạt lỗ hổng:

AppModule.EndBlock

Khối cuối

EndBlockRD

Gửi phần thưởng tới nhà cung cấp

Loại tình huống thứ hai

Loại vấn đề đồng thuận này có thể không mang lại tác hại nghiêm trọng về mặt trực quan, nhưng nếu chúng ta xem xét các nguyên tắc và hệ thống thiết yếu của toàn bộ chuỗi khối hoặc xem xét các lỗ hổng này từ các tình huống cụ thể, thì tác động và tác hại mà chúng mang lại không hẳn là rõ ràng. hơn các lỗ hổng thông thường khác.Ngoài ra, loại lỗ hổng này cũng có điểm chung.

• Trường hợp số một

Nền tảng lỗ hổng: Tư vấn bảo mật Cosmos SDK Mít

Hành vi không xác định của phương thức ValidateBasic trong mô-đun x/authz của Cosmos SDK có thể dễ dàng khiến sự đồng thuận bị dừng lại. Cấu trúc thông báo MsgGrant của mô-đun x/authz chứa trường Grant bao gồm thời gian hết hạn cho ủy quyền do người dùng xác định được cấp. Trong quy trình xác minh ValidateBasic() của cấu trúc Grant, hãy so sánh thông tin thời gian của nó với thông tin thời gian cục bộ của nút thay vì thông tin thời gian khối. Vì giờ địa phương là không xác định nên dấu thời gian của mỗi nút có thể khác nhau, điều này sẽ dẫn đến các vấn đề đồng thuận.

Thông báo về lỗ hổng:

Đoạn mã dễ bị tổn thương:

Bản vá lỗ hổng:

Các vấn đề như dấu thời gian không chỉ xuất hiện trong các thành phần cơ bản như Cosmos SDK mà các lỗ hổng tương tự cũng xuất hiện trong nhiều chuỗi ứng dụng khác nhau.

• Trường hợp 2

Nền tảng lỗ hổng: SuperNova, dự án nova

địa chỉ dự án:

Sử dụng time.Now() để trả về dấu thời gian của hệ điều hành. Giờ địa phương là chủ quan và do đó không xác định. Vì có thể có những khác biệt nhỏ về dấu thời gian của từng nút riêng lẻ nên chuỗi có thể không đạt được sự đồng thuận. Trong mô-đun ICAControl, chức năng gửi giao dịch sử dụng time.Now() để lấy dấu thời gian.

Vị trí lỗ hổng: _msgs.go#L14

Đoạn mã dễ bị tổn thương:

Bản vá lỗ hổng:

Đã thay đổi từ sử dụng dấu thời gian cục bộ sang sử dụng thời gian khối.

timeoutTimestamp := time.Now().Add(time.Minute * 10).UnixNano() _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, ConnectionId, portID, packetData, uint64(timeoutTimestamp))

timeoutTimestamp := uint64(ctx.BlockTime().UnixNano() + 10*time.Minute.Nanoseconds()) _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, ConnectionId, portID, packetData, uint64(timeoutTimestamp ))

• Trường hợp 3

Nền tảng lỗ hổng: Mô-đun Oracle của dự án BandChain

địa chỉ dự án:

Các nhận xét trong cơ sở mã chỉ ra rằng mô-đun oracle phải được thực thi trước khi đặt cược để thực hiện các hình phạt đối với những người vi phạm giao thức oracle. Thứ tự xuất hiện trong mã là: trong hàm SetOrderEndBlockers, mô-đun cam kết chạy trước mô-đun oracle. Nếu mô-đun đặt cược được thực thi trước mô-đun oracle thì sẽ không thể phạt người xác nhận vì hành vi đặt cược, v.v. dựa trên xác minh được thực hiện trong mô-đun oracle.

Vị trí dễ bị tổn thương:

Đoạn mã dễ bị tổn thương:

Có thể thấy rằng việc triển khai cụ thể lỗ hổng và chú thích lỗ hổng hoàn toàn bị đảo ngược và mô-đun oracle phải được xếp hạng trước mô-đun cam kết.

• Trường hợp 4

Nền tảng lỗ hổng: mô-đun kiểm soát truy cập của dự án Sei Cosmos

địa chỉ dự án:

Trong nhiều phiên bản của các cơ sở mã Cosmos khác nhau, phép lặp bản đồ sử dụng loại bản đồ của ngôn ngữ cờ vây và lặp lại trên nó. Vì việc lặp lại bản đồ ngôn ngữ Go là không xác định nên điều này sẽ khiến các nút đạt đến các trạng thái khác nhau, điều này có thể gây ra các vấn đề về đồng thuận và khiến chuỗi ngừng chạy. Một cách tiếp cận thích hợp hơn là sắp xếp các khóa bản đồ thành một lát và lặp lại các khóa đã sắp xếp. Loại vấn đề này tương đối phổ biến và xảy ra do việc áp dụng các tính năng của ngôn ngữ.

Khi triển khai BuildDependencyDag trong x/accesscontrol/keeper/keeper.go, nút sẽ lặp lại trên anteDepSet. Do hành vi không xác định của việc lặp lại bản đồ trong Go, ValidateAccessOp có thể có hai loại lỗi khác nhau, có thể khiến sự đồng thuận không thành công.

Vị trí lỗ hổng:/blob/afe957cab74dd05c213d082d50cae02dd4cb6b73/x/accesscontrol/keeper/keeper.go#L314C9-L314C9

Đoạn mã dễ bị tổn thương:

Theo những trường hợp này, có thể thấy rằng các lỗ hổng khiến chuỗi ngừng chạy một cách thụ động thường có hại nhất và mối quan hệ logic giữa các nguyên nhân gây ra lỗ hổng có thể bắt nguồn từ quá trình thực thi ảnh hưởng trực tiếp đến hoạt động của một chuỗi. khối duy nhất trong chuỗi khối. Đối với một số lỗ hổng bảo mật đồng thuận, chuỗi thường ngừng chạy để sửa chữa chúng. Mối quan hệ logic giữa các nguyên nhân gây ra lỗ hổng có thể bắt nguồn từ quy trình vận hành tổng thể và trạng thái của chuỗi khối. Khác với trọng tâm của lỗ hổng gây mất vốn mà chúng ta sẽ thảo luận tiếp theo, lỗ hổng gây mất vốn thường không đánh giá tác động nguy hiểm cụ thể của nó dựa trên diễn biến logic của vấn đề mà quan tâm nhiều hơn đến chủ sở hữu quỹ. , Số tiền, phạm vi ảnh hưởng đến quỹ và cách thức ảnh hưởng đến quỹ, v.v.

Mất quỹ

Vấn đề mất vốn là vấn đề thường gặp trong quá trình xử lý logic các tin nhắn sdk.Msg và IBC. Tất nhiên, cũng có một số sơ hở có thể khiến chuỗi ngừng chạy. Tác động cụ thể tùy thuộc vào tác động. Về sơ hở cụ thể, chúng tôi tập trung vào trước đây ở đây. Ngoài ra, vì IBC là một phần rất quan trọng của hệ sinh thái Cosmos nên chắc chắn sẽ liên quan đến một số lỗ hổng của IBC, chúng ta sẽ thảo luận về bề mặt tấn công cụ thể và các lỗ hổng tương ứng của IBC trong chương tiếp theo.

Mất tiền thường xảy ra trong các tình huống logic như tiêu thụ gas, tiền bị khóa và không thể rút, tiền bị mất trong quá trình truyền, lỗi logic tính toán gây mất tiền và ID lưu trữ quỹ không đảm bảo tính duy nhất.

Ở đây chúng tôi lấy dự án SuperNova làm ví dụ để phân tích ba lỗ hổng liên quan đến nó.

• Nền tảng về lỗ hổng: Dự án SuperNova

địa chỉ dự án:

Nếu chữ số thập phân của vùng cao hơn 18, tiền có thể bị khóa. Trong mã dự án này, không có giới hạn trên về số vị trí thập phân cho một khu vực và có thể vượt quá 18 chữ số. Trong ClaimSnMesssage, ClaimShareToken được sử dụng khi người dùng muốn yêu cầu mã thông báo chia sẻ của họ. Tuy nhiên, nếu vị trí thập phân của vùng cao hơn 18 thì quá trình chuyển đổi sẽ không thành công và không thể trích xuất nội dung khỏi hệ thống. Do đó, bằng cách kiểm soát số lượng vị trí thập phân trong khu vực, lỗi giao dịch có thể trực tiếp được kích hoạt.

Vị trí lỗ hổng:/blob/v0.6.3/x/gal/keeper/claim.go#L167

Đoạn mã dễ bị tổn thương:

Đường dẫn kích hoạt lỗ hổng:

msgServer.ClaimSnAsset

Keeper.ClaimShareToken

Keeper.ConvertWAssetToSnAssetDecimal

độ chính xácMultiplier

• Nền tảng về lỗ hổng: Dự án SuperNova

địa chỉ dự án:/

Tính duy nhất của khu vực không được xác minh. Trên các khu vực đã đăng ký, hãy sử dụng ID khu vực để kiểm tra tính duy nhất của mã thông báo cơ sở (BaseDenom). BaseDenom của mỗi khu vực phải là duy nhất. Nếu giá trị của mã thông báo cơ sở được đặt không chính xác, điều này sẽ dẫn đến mất tiền. Trước khi đặt mã thông báo cơ sở trong RegisterZone, dự án đã không đảm bảo rằng BaseDenom là duy nhất trong tất cả các vùng chính. Nếu không, sẽ có khả năng người dùng lưu trữ tiền trong một vùng độc hại khác có cùng BaseDenom, dẫn đến mất tiền.

Vị trí lỗ hổng:/blob/v0.6.3/x/icacontrol/keeper/msg_server.go#L99

Đoạn mã dễ bị tổn thương:

Bản vá lỗ hổng: Đã thêm kiểm tra DenomDuplicateCheck

Ngoài ra, trường hợp đầu tiên dây chuyền ngừng chạy là do gặp sự cố dẫn đến việc đúc tiền không thành công cũng là một dạng mất vốn.

• Nền tảng về lỗ hổng: Dự án Supernova

địa chỉ dự án:/

Thiếu cập nhật trạng thái. Trong phương thức IcaWithdraw(), nếu giao dịch không thành công và trạng thái phiên bản không được sửa đổi, WithdrawRecord sẽ không thể truy cập được và số tiền tương ứng không thể rút được. Một cách hiểu phổ biến hơn là trạng thái được đặt trước SendTx và trạng thái không được sửa đổi sau khi thất bại, dẫn đến việc rút tiền không thành công và không thể rút lại vào lần tiếp theo.

Vị trí lỗ hổng:/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/gal/keeper/msg_server.go#L356

Đoạn mã dễ bị tổn thương:

Theo phần này của các trường hợp, có thể thấy rằng logic thực hiện các hoạt động liên quan đến quỹ chủ yếu phụ thuộc vào việc xử lý các thông báo khác nhau. Tất nhiên, cũng có những trường hợp như loại trường hợp đầu tiên - hoạt động đúc tiền liên quan đến quá trình thực thi BeginBlock. Việc thất bại trong các hoạt động này cũng có thể dẫn đến mất tiền. Nhìn chung, bằng cách tập trung kiểm tra các mô-đun mã liên quan đến hoạt động của quỹ, chúng tôi có thể tăng đáng kể khả năng phát hiện ra những lỗ hổng như vậy.

Ảnh hưởng đến trạng thái hệ thống hoặc hoạt động bình thường

Phạm vi của loại vấn đề này tương đối rộng, hai mối nguy hiểm đầu tiên vừa thảo luận thực sự có thể được coi là một tập hợp con của các loại lỗ hổng ảnh hưởng đến trạng thái hoặc hoạt động bình thường của hệ thống. Ngoài ra, nguy hiểm hơn là một số loại lỗ hổng logic. Ở mức độ lớn, các lỗ hổng như vậy sẽ tạo ra các rủi ro bảo mật khác nhau tùy theo logic nghiệp vụ của dự án, nhưng do cấu trúc thành phần Cosmos SDK Do chúng tính tương đồng và tính mô-đun, những lỗi tương tự thường mắc phải khi triển khai các mã cụ thể.Dưới đây là các loại lỗ hổng phổ biến:

Xác minh biến chưa hoàn chỉnh trong loại sdk.Msg

Do nhiều dự án khác nhau đã triển khai nhiều loại dẫn xuất khác nhau dựa trên sdk.Msg, Cosmos SDK không thực sự phát hiện các phần tử của tất cả các loại hiện có tương ứng, dẫn đến việc bỏ sót một số phát hiện biến nhúng chính, do đó có một số rủi ro bảo mật nhất định.

• Trường hợp 1: Barberry tư vấn bảo mật SDK Cosmos

Nền tảng lỗ hổng: MsgCreatePeriodicVestingAccount.ValidateBasic Cơ chế xác minh thiếu khả năng phán đoán về trạng thái của tài khoản, chẳng hạn như sự tồn tại. Với PeriodicVestingAccount được xác định trong x/auth, kẻ tấn công có thể khởi tạo tài khoản của nạn nhân dưới dạng tài khoản được phân bổ độc hại, cho phép gửi tiền nhưng không thể rút tiền. Khi người dùng gửi tiền vào tài khoản của họ, số tiền này sẽ bị khóa vĩnh viễn và người dùng không thể rút được.

Bản vá lỗ hổng:

Đoạn mã dễ bị tổn thương:

Ngoài ra, Cố vấn bảo mật Cosmos-SDK Elderflower và Cố vấn bảo mật Cosmos-SDK Mít thực sự là những sự cố xảy ra trong liên kết ValidateBasic. Cái trước trực tiếp thiếu lệnh gọi đến ValidateBasic và cái sau là về biến dấu thời gian bên trong thông báo. . Trong các chuỗi ứng dụng, những vấn đề như vậy thậm chí còn phổ biến hơn. Các dự án như ethermint, pstake-native và quicksilver đều gặp phải các lỗ hổng bảo mật tương tự trong các biện pháp xác minh được sử dụng để xử lý tin nhắn.

Ngoài loại xác minh, trong logic xử lý của sdk.Msg, bạn cũng sẽ gặp phải các hoạt động vòng lặp liên quan đến lượng tiêu thụ gas lớn, xử lý sự cố không hợp lý, v.v. Vì chuỗi xử lý tin nhắn có cơ chế khôi phục tương ứng nên mức độ của chúng rủi ro sẽ thấp hơn so với khi chuỗi ngừng hoạt động, nhưng nó vẫn có thể ảnh hưởng đến hoạt động bình thường của hệ thống hoặc gây thất thoát tiền trên chuỗi.

Các loại lỗ hổng phổ biến

Ngoài các lỗ hổng bảo mật chỉ dành cho hoạt động kinh doanh dự án, còn có một số mô hình lỗ hổng phổ biến hơn, chẳng hạn như trường hợp mất vốn thứ ba là một hoạt động thay đổi trạng thái trước khi gửi tin nhắn. Loại lỗ hổng này rất giống với các lỗ hổng trong hợp đồng thông minh. Khi chuyển tiền, việc thay đổi trạng thái của chính mình trước đây thường dẫn đến các vấn đề như trạng thái lỗi cũ hoặc lỗi cũ. Các tình huống trong đó cài đặt trạng thái và truyền thông báo được kết hợp chặt chẽ thực sự rất phổ biến trong blockchain và nhiều lỗ hổng gây ra những mối nguy hiểm lớn, tất cả đều xuất phát từ những vấn đề như vậy. Ngoài ra, còn có một số lỗ hổng bảo mật tính toán như lỗ hổng chia cho 0, bỏ qua tiêu thụ gas, sử dụng các phiên bản dễ bị tấn công, v.v. Các lỗ hổng như vậy sẽ ảnh hưởng đến trạng thái hệ thống hoặc hoạt động bình thường của hệ thống.

Vấn đề về tính duy nhất

Vì blockchain liên quan đến một số lượng lớn các hoạt động lưu trữ tìm kiếm và đọc nên tính duy nhất của việc đặt tên là rất quan trọng trong việc triển khai một số chức năng nhất định. Ví dụ, trường hợp lỗ vốn 2 nêu trên là vấn đề về tính duy nhất, ngoài ra, một số biến kiểu mảng chuỗi hoặc byte đại diện cho khóa và các yếu tố quan trọng khác đôi khi có những rủi ro nhất định trong thành phần tiền tố của chúng, chẳng hạn như có “/” hay không. Khi kết thúc mỗi lần đặt tên, v.v., một chút bất cẩn có thể khiến tên đó bị giả mạo thành một chuỗi mang ý nghĩa khác, dẫn đến hàng loạt vấn đề như mất vốn, lỗi đồng thuận, v.v.

Vấn đề về tính năng ngôn ngữ

Loại vấn đề này tổng quát hơn, nhưng có nhiều đặc điểm hơn để theo dõi nên dễ tìm hơn, chẳng hạn như vấn đề lặp lại bản đồ của golang, một số vấn đề về cơ chế hoảng loạn trong rỉ sét, v.v. Bản thân các tính năng ngôn ngữ này có thể gây ra sự cố trước đó sử dụng ngôn ngữ tương ứng.Liệt kê các điểm dẫn đến rủi ro tương ứng và chú ý đến từng cá nhân trong quá trình sử dụng hoặc kiểm tra để tránh những sai sót đó ở mức độ lớn nhất.

Bản tóm tắt

Dựa trên khám phá của chúng tôi về các vấn đề bảo mật cơ bản của hệ sinh thái Cosmos, không khó để nhận ra rằng những vấn đề đó không chỉ áp dụng cho hệ sinh thái Cosmos. Có nhiều mô hình dễ bị tổn thương cũng có thể được sử dụng trong các chuỗi sinh thái khác. Sau đây là một số nghiên cứu có liên quan về vấn đề bảo mật của hệ sinh thái Cosmos.

• **Tập trung vào các lỗ hổng cơ sở hạ tầng: **Các thành phần cốt lõi của CometBFT và Cosmos SDK cũng có thể có lỗ hổng nên các thành phần này cần được cập nhật và bảo trì thường xuyên để đảm bảo tính bảo mật.
• Xem xét nhanh chóng các thư viện của bên thứ ba: Các nhà phát triển của Cosmos thường sử dụng thư viện của bên thứ ba để mở rộng chức năng cho ứng dụng của họ. Tuy nhiên, các thư viện này có thể chứa các lỗ hổng tiềm ẩn nên các thư viện này cần được xem xét và cập nhật để giảm thiểu rủi ro.
• Cẩn thận với các cuộc tấn công nút độc hại: Trong hệ sinh thái Cosmos, các nút đồng thuận là thành phần chính của mạng. Thuật toán Dung sai lỗi Byzantine của nút có thể dễ bị tấn công, do đó, các nút cần được bảo mật để ngăn chặn hành vi xấu.
• Chú ý đến bảo mật vật lý: Đối với phần cứng và máy chủ chạy nút Cosmos, cần có các biện pháp bảo mật vật lý để ngăn chặn truy cập trái phép và các cuộc tấn công tiềm ẩn.
• Đánh giá mã bắt buộc: Do tính chất mở của hệ sinh thái Cosmos SDK và CometBFT, nhà phát triển và người đánh giá nên xem lại mã lõi cũng như mã được viết trong mô-đun tùy chỉnh để xác định và khắc phục các vấn đề bảo mật tiềm ẩn.
• Coi chừng các công cụ của hệ sinh thái: Hệ sinh thái Cosmos bao gồm nhiều công cụ và ứng dụng cũng yêu cầu đánh giá bảo mật và cập nhật thường xuyên để đảm bảo tính bảo mật của chúng.

Hướng dẫn bảo mật giao thức IBC

Học phần này sẽ tập trung vào các vấn đề bảo mật liên quan đến giao thức IBC (Giao thức truyền thông liên chuỗi khối). Giao thức IBC là một phần cực kỳ quan trọng của Cosmos. Vai trò của nó là xây dựng một cầu nối tương tác giữa các chuỗi khác nhau. Nếu các loại cầu nối chuỗi khác cung cấp giải pháp cho một số vấn đề tương đối độc lập thì IBC Giao thức có thể nói là cung cấp một giao thức thống nhất giải pháp cơ bản và hỗ trợ kỹ thuật cơ bản cho các vấn đề tương tác giữa các chuỗi. IBC là một giao thức cho phép các chuỗi khối không đồng nhất cung cấp bất kỳ dữ liệu nào theo cách đáng tin cậy, có trật tự và giảm thiểu sự tin cậy.

Kể từ khi Bitcoin ra đời, không gian blockchain đã có sự tăng trưởng bùng nổ. Vô số mạng lưới mới đang nổi lên, mỗi mạng lưới có những đề xuất giá trị riêng, cơ chế đồng thuận, hệ tư tưởng, khu vực bầu cử và lý do tồn tại riêng. Trước khi IBC ra đời, hầu hết các blockchain này hoạt động độc lập, như thể chúng tồn tại trong các thùng kín và không thể giao tiếp với nhau.Tuy nhiên, mô hình khép kín này về cơ bản là không bền vững.

Nếu chúng ta coi blockchain là những quốc gia có dân số ngày càng tăng và có nhiều hoạt động thương mại, một số blockchain giỏi về nông nghiệp, một số thì xuất sắc trong chăn nuôi. Họ đương nhiên muốn thực hiện thương mại và hợp tác cùng có lợi và mỗi blockchain đều phát huy sức mạnh riêng của mình. . Lợi thế. Không quá lời khi nói rằng IBC mở ra một thế giới mới với những khả năng vô hạn, cho phép các chuỗi khối khác nhau ** tương tác, phân phối giá trị, trao đổi tài sản và dịch vụ ** và thiết lập kết nối mà không bị ràng buộc bởi các khu vực quy mô lớn ngày nay. bị hạn chế bởi các vấn đề về khả năng mở rộng vốn có.

Vậy làm thế nào để IBC đáp ứng được những nhu cầu này và đóng vai trò quan trọng? Lý do cơ bản là IBC là:

1. Không đáng tin cậy

2 Có thể hỗ trợ các chuỗi khối không đồng nhất

3. Có thể tùy chỉnh ở lớp ứng dụng

4 Công nghệ đã được chứng minh và chứng minh

Cơ sở của giao thức IBC là các máy khách và bộ chuyển tiếp nhẹ. Chuỗi A và chuỗi B, giao tiếp thông qua IBC, có các khách hàng nhỏ trong sổ cái của nhau. Chuỗi A không cần phải tin tưởng bên thứ ba và có thể đạt được sự đồng thuận về trạng thái của chuỗi B chỉ bằng cách xác minh tiêu đề khối. Các chuỗi tương tác qua IBC (đặc biệt là các mô-đun) không gửi tin nhắn trực tiếp cho nhau. Thay vào đó, chuỗi A đồng bộ hóa một số tin nhắn trong gói về trạng thái của nó. Sau đó, trạm chuyển tiếp sẽ kiểm tra các gói này và chuyển chúng đến chuỗi đích.

Nhìn chung, giao thức IBC có thể được chia thành hai lớp, đó là IBC TAO và IBC APP.

IBC TAO: Các tiêu chuẩn xác định việc truyền, xác thực và sắp xếp các gói dữ liệu, lớp cơ sở hạ tầng. Trong ICS, điều này bao gồm các danh mục cốt lõi, máy khách và chuyển tiếp.

IBC APP: Một tiêu chuẩn xác định các trình xử lý ứng dụng cho các gói được truyền qua lớp vận chuyển. Chúng bao gồm nhưng không giới hạn ở Chuyển mã thông báo có thể thay thế (ICS-20), Chuyển mã thông báo không thể thay thế (ICS-721) và Liên tài khoản chuỗi (ICS-27) ) và có thể được tìm thấy trong ICS trong danh mục Ứng dụng.

Biểu đồ IBC (từ Cổng thông tin nhà phát triển Cosmos)

Giao thức IBC là xương sống trong tầm nhìn của Cosmos về Internet của Blockchain. Theo nghĩa này, các lựa chọn thiết kế IBC bị ảnh hưởng bởi đặc tả TCP/IP. Tương tự như cách TCP/IP đặt ra các tiêu chuẩn cho giao tiếp máy tính, IBC chỉ định một tập hợp các khái niệm trừu tượng phổ biến có thể được triển khai để cho phép các chuỗi khối giao tiếp. TCP/IP không đặt ra hạn chế nào về nội dung của các gói được chuyển tiếp qua mạng và IBC cũng vậy. Ngoài ra, tương tự như cách các giao thức ứng dụng như HTTP và SMTP được xây dựng trên TCP/IP, các phiên bản ứng dụng như truyền tài sản đồng nhất/tài sản không đồng nhất hoặc các lệnh gọi hợp đồng thông minh chuỗi chéo cũng sử dụng giao thức IBC làm lớp cơ sở.

Hiện tại, các vấn đề chính nảy sinh trong giao thức IBC đều là về truyền kênh và xử lý gói dữ liệu, tất nhiên cũng có những vấn đề lớn trong việc xác minh bằng chứng và các khía cạnh khác, nhưng những vấn đề đó tương đối ít. Câu hỏi thường gặp. Do thiết kế mô-đun của giao thức IBC, các nhà phát triển ứng dụng IBC không cần phải lo lắng về các chi tiết cấp thấp như ứng dụng khách, kết nối và xác minh bằng chứng. Tuy nhiên, họ cần triển khai giao diện IBCModule và các phương thức xử lý Keeper tương ứng, do đó, nhiều vấn đề liên quan đến giao thức IBC xuất hiện trong đường dẫn mã của giao diện IBCModule để nhận và xử lý các gói dữ liệu (onRecvPacket, OnAcknowmentmentPacket, OnTimeoutPacket, v.v.).

Phân loại lỗ hổng phổ biến

Trong hệ sinh thái Cosmos, giao thức IBC đóng vai trò là trung tâm kết nối.Xét về loại lỗ hổng, các lỗ hổng liên quan đến giao thức IBC nhiều hơn và vị trí của các lỗ hổng cũng phức tạp hơn.Do việc triển khai giao thức và mô-đun IBC có liên quan chẳng hạn như Cosmos-SDK và CometBFT, Do tích hợp chặt chẽ nên việc triển khai một số module khác của hệ sinh thái Cosmos chắc chắn sẽ được đề cập dưới đây. Ngoài ra, IBC hiện được sử dụng chủ yếu trong hệ sinh thái Cosmos nên ngôn ngữ chủ đạo của nó vẫn là Golang, chi tiết vui lòng xem tài liệu liên quan đến ibc-go.

Do giới hạn về không gian, chúng tôi sẽ không tiến hành phân tích chi tiết từng liên kết và thành phần trong giao thức IBC tại đây mà chỉ phân loại và thảo luận về một số lỗ hổng bảo mật hiện có. Nếu bạn muốn biết phân tích chi tiết và toàn diện hơn, vui lòng liên hệ với CertiK của chúng tôi kỹ sư bảo mật Trao đổi, thảo luận.

Các loại lỗ hổng phổ biến:

1. Đặt tên lỗ hổng

① Lỗ hổng xử lý chuỗi

② Lỗ hổng xử lý mã byte

2. Lỗ hổng trong quá trình truyền tải

① Lỗ hổng chuỗi gói

② Lỗ hổng hết thời gian gói

③ Lỗ hổng xác thực gói

④ Các lỗ hổng gói khác

3 lỗ hổng logic

① Lỗ hổng cập nhật trạng thái

② Sự đồng thuận biểu quyết và những sơ hở khác

③ Các lỗ hổng logic khác

4. Lỗ hổng tiêu thụ gas

Giao thức IBC hiện tại có nhiều điểm tương đồng với quy trình kiểm toán của giao thức Web2 trong quá trình kiểm tra và phân tích tính bảo mật của nó, lần này chúng ta sẽ phân tích nó từ góc độ một quá trình hoàn chỉnh về xây dựng, triển khai và mở rộng ứng dụng giao thức. và những rủi ro tiềm ẩn trên giao thức IBC. Do việc xây dựng các giao thức thường được hoàn thành bởi một số ít người và tổ chức, nên đối với các tổ chức blockchain khác nhau, nhiều công việc tập trung vào việc triển khai và mở rộng ứng dụng của các giao thức, vì vậy bài viết này cũng sẽ tập trung thảo luận về cả hai. Điều này là do mức độ bao phủ rộng rãi của các rủi ro bảo mật giao thức IBC, có thể phân chia tốt hơn các loại vấn đề bảo mật khác nhau trên giao thức thành các liên kết và mô-đun tương ứng.

Phân tích lỗ hổng

Xây dựng Thỏa thuận IBC

• Trường hợp 1: Giao thức ICS-07, lỗ hổng logic

Nền tảng lỗ hổng: sử dụng không chính xác thời gian hủy ràng buộc

Các kiểm tra sau tồn tại trong mã:

if currentTimestamp.Sub(consState.Timestamp) >= clientState.UnbondingPeriod {

Theo mô hình bảo mật Tendermint, các trình xác thực trong NextValidators của khối (tiêu đề) tại thời điểm t cần chạy chính xác trước t+TrustingPeriod, sau đó chúng có thể có các hành vi khác. Tuy nhiên, những gì được kiểm tra ở đây là UnbondingPeriod, không phải TrustingPeriod, trong đó UnbondingPeriod>TrustingPeriod. Nếu khoảng thời gian của consState nằm giữa TrustingPeriod và UnbondingPeriod thì tiêu đề đó sẽ được chấp nhận làm cơ sở để xác thực một trong các tiêu đề xung đột cấu thành hành vi sai trái. Trong thời gian này, các trình xác thực trong consState.NextValidators không còn được coi là đáng tin cậy và các trình xác thực trước đây có thái độ thù địch có thể đóng cửa ứng dụng khách mà không gặp bất kỳ rủi ro nào.

địa chỉ dự án:

Vị trí dễ bị tổn thương: #misbehaviour-predicate

_handle.go#L96

Đoạn mã dễ bị tổn thương:

Chức năng định nghĩa giao thức

Mã số

Triển khai giao thức IBC

Liên kết triển khai của giao thức IBC là nơi dễ xảy ra sự cố hơn, vì liên kết này đóng vai trò là liên kết giữa quá khứ và tiếp theo. Cần tránh sự mơ hồ trong các thông số kỹ thuật của giao thức càng nhiều càng tốt, và nó cũng cần cung cấp cơ sở cơ bản và thuận tiện hơn cho ứng dụng và mở rộng giao thức tiếp theo. Do đó, ở đây chúng tôi sẽ phân loại nhỏ các vấn đề chính trong việc triển khai giao thức IBC, cụ thể là:

1. Sự mơ hồ và bất thường trong việc thực hiện Nghị định thư

2. Vấn đề lỗi cài đặt giao thức

Sự mơ hồ và bất thường trong việc thực hiện giao thức

• Trường hợp 1: Giao thức ICS-20, đặt tên lỗ hổng

Nền tảng lỗ hổng: Xung đột địa chỉ lưu trữ. GetEscrowAddress() là SHA256 (ID cổng + ID kênh) được cắt ngắn còn 20 byte. Có ba vấn đề với cách tiếp cận này:

1. Không có sự phân tách miền giữa các cổng và kênh, việc sử dụng nối chuỗi sẽ không phân tách miền của cổng và kênh. Ví dụ: các kết hợp cổng/kênh (“truyền”, “kênh”) và (“trans”, “ferchannel”) sẽ cung cấp cùng một địa chỉ được quản lý, đó là SHA256 (“kênh truyền”) bị cắt ngắn. Lỗ hổng có thể phát sinh nếu một số mô-đun nhất định có chức năng thư viện có thể chọn ID cổng và kênh.

2. Xung đột giữa các địa chỉ tài khoản mô-đun. Sử dụng chuỗi chữ và số tùy ý trong ảnh trước SHA-256, kích thước ảnh sau là 160 bit. Sự kết hợp giữa hình ảnh ngược nhỏ và hàm băm nhanh này khiến cho cuộc tấn công sinh nhật có thể xảy ra vì tính bảo mật của nó chỉ giảm xuống còn 80 bit. Điều này có nghĩa là phải mất khoảng 2^80 lần đoán để tìm ra sự xung đột giữa hai địa chỉ tài khoản ký quỹ khác nhau. Một phân tích chi tiết về chi phí của việc tấn công cắt bớt SHA256 đã được thực hiện trong bối cảnh Tendermint vào năm 2018, chứng minh rằng cuộc tấn công này là khả thi từ góc độ chi phí, nhận thấy rằng xung đột có nghĩa là hai tài khoản lưu trữ khác nhau ánh xạ tới cùng một địa chỉ tài khoản. Điều này có thể dẫn đến nguy cơ tiền bị đánh cắp từ tài khoản ký quỹ, hãy xem miền trước hình ảnh ICS20 GetEscrowAddress chồng chéo với khóa chungT:BUG để biết chi tiết.

3 Xung đột giữa địa chỉ tài khoản mô-đun và không phải mô-đun. Địa chỉ tài khoản công khai được xây dựng giống hệt với SHA-256 20 byte của khóa chung Ed25519. Mặc dù mức độ bảo mật 160 bit là đủ để ngăn chặn các cuộc tấn công va chạm vào các địa chỉ công cộng cụ thể, nhưng chỉ có 80 bit bảo mật có sẵn đối với các cuộc tấn công sinh nhật. Tình huống này giống với kiểu tấn công nửa ngày sinh nhật, trong đó một địa chỉ được tạo bởi SHA-256 nhanh và địa chỉ còn lại được tạo bằng phép tính khóa công khai Ed25519 tương đối chậm. Mặc dù kịch bản này sẽ an toàn hơn nhưng nó vẫn mở ra các cuộc tấn công tiềm tàng vào tài khoản ký quỹ và tài khoản công cộng.

địa chỉ dự án:

Vị trí dễ bị tổn thương:

Đoạn mã dễ bị tổn thương:

Vấn đề về lỗi cài đặt giao thức

• Trường hợp 1: Tư vấn bảo mật IBC Dragonberry, lỗ hổng trong quá trình truyền tải

Nền tảng lỗ hổng: IBC sẽ sử dụng cấu trúc Gói khi xử lý các gói dữ liệu ứng dụng.Theo cơ chế hết thời gian chờ, cơ chế xác nhận đồng bộ và không đồng bộ và quy trình xác minh chứng nhận tương ứng, gói dữ liệu sẽ được chia thành hai quy trình thực thi:

1. Tình huống bình thường: Thành công trong thời gian chờ

2. Tình huống hết thời gian chờ: lỗi hết thời gian chờ

Biểu đồ luồng truyền gói ứng dụng IBC

Khi hết thời gian chờ, điều đó có nghĩa là quá trình truyền không thành công và giao thức IBC sẽ bắt đầu quá trình hoàn tiền. Cần lưu ý rằng IBC có cơ chế hết thời gian chờ do người dùng định cấu hình. Lỗ hổng Dragonberry bắt nguồn từ ICS-23 (IBC), nguyên nhân sâu xa của lỗ hổng này là do người dùng có thể giả mạo bằng chứng không tồn tại trong quá trình xác minh (tức là bằng chứng giả cho thấy không nhận được gói dữ liệu nào), do đó bỏ qua kiểm tra bảo mật. và giả mạo Một tình huống hết thời gian chờ IBC “hợp lý” được sử dụng để đánh lừa giao thức IBC, khiến bộ lặp gửi các gói hết thời gian chờ có chứng chỉ sai và có thể leo thang thành vấn đề chi tiêu gấp đôi ICS-20. Quá trình kích hoạt cụ thể của lỗ hổng có thể là nhìn thấy trong hình dưới đây.

Biểu đồ nguyên tắc về lỗ hổng Dragonberry

địa chỉ dự án:

Vị trí dễ bị tổn thương:

Đoạn mã dễ bị tổn thương:

• Trường hợp 2: Tư vấn bảo mật IBC Huckleberry, lỗ hổng trong quá trình truyền tải

Bối cảnh lỗ hổng: UnreceivedPackets chỉ xây dựng phản hồi bằng cách tìm biên nhận gói tương ứng cho mỗi số thứ tự có trong truy vấn. Điều này chỉ áp dụng cho các kênh không theo thứ tự, vì các kênh được yêu cầu sử dụng nextSequenceRecv thay vì nhận gói. Do đó, trên kênh đặt hàng, truy vấn số sê-ri qua GetPacketReceipt sẽ không tìm thấy biên nhận.

Mức độ nghiêm trọng của sự cố này là không đáng kể vì kênh được truyền bởi ICS-20 FT hầu như không hoạt động và bộ lặp không dựa vào điểm cuối grpc này để xác định gói hết thời gian chờ kích hoạt. Tuy nhiên, nếu có một số lượng lớn gói trong chuỗi mục tiêu và kênh theo thứ tự được định cấu hình để truyền IBC và phản hồi grpc không được phân trang, điều này sẽ tạo ra nguy cơ gây suy giảm hiệu suất hoặc thậm chí làm hỏng nút dịch vụ. Quá trình kích hoạt cụ thể có thể được nhìn thấy trong hình dưới đây.

Biểu đồ nguyên tắc về lỗ hổng Huckleberry

địa chỉ dự án:

Vị trí lỗ hổng:keeper/grpc_query.go#L408

Đoạn mã dễ bị tổn thương:

Ứng dụng và mở rộng giao thức IBC

• Trường hợp 1: lỗ hổng sải bước airdrop, lỗ hổng logic

Nền tảng lỗ hổng: TryUpdateAirdropClaim Chức năng này chuyển đổi địa chỉ người gửi của gói IBC thành địa chỉ Stride có tên senderStrideAddress, đồng thời trích xuất airdropId và địa chỉ airdrop mới newStrideAddress từ siêu dữ liệu gói. Sau đó gọi UpdateAirdropAddress để cập nhật senderStrideAddress và ClaimRecord. Với bản cập nhật ClaimRecord, newStrideAddress sẽ có thể nhận được airdrop. Tuy nhiên, chức năng cập nhật ở đây chỉ xác minh xem địa chỉ mà người gửi yêu cầu có trống hay không và không xác minh NewStrideAddress. Vì ibc cho phép các máy solo kết nối với chuỗi triển khai hỗ trợ IBC nên có khả năng cập nhật bất kỳ tài khoản nào khác địa chỉ làm địa chỉ airdrop.

địa chỉ dự án:

Vị trí lỗ hổng: _ibc.go#L119

Đoạn mã dễ bị tổn thương:

• Trường hợp 2: lỗ hổng mô-đun neutron ibc, lỗ hổng tiêu thụ khí

Nền tảng lỗ hổng: Phí mà hợp đồng thông minh trả cho việc xác nhận/hết thời gian của sự kiện IBC không được xác minh đầy đủ. Hợp đồng thông minh độc hại có thể khai thác điều này để gây ra sự cố ErrorOutOfGas trong quá trình xử lý tin nhắn OnAcknowmentmentPacket và OnTimeoutPacket. Những sự cố này sẽ không được khắc phục bằng cách thực thi outOfGasRecovery, điều đó có nghĩa là các giao dịch sẽ không được đưa vào khối và sẽ khiến rơle IBC gửi tin nhắn liên tục, điều này cuối cùng có thể khiến rơle mất tiền và mạng loại bỏ quá nhiều gói. làm hại.

địa chỉ dự án:

Vị trí dễ bị tổn thương:

x/interchaintxs/keeper/ibc_handlers.go#L62

Đoạn mã dễ bị tổn thương:

Bản tóm tắt

Theo nghiên cứu và phân tích ở trên về các vấn đề bảo mật của giao thức IBC, không khó nhận thấy các vấn đề bảo mật của giao thức IBC được phân bổ rộng rãi và đa dạng, tuy nhiên các vấn đề chính vẫn xảy ra trong quá trình triển khai và mở rộng ứng dụng của giao thức IBC. Giao thức IBC**. Trong khi các chuỗi ứng dụng lớn đang dần làm phong phú và cải thiện chức năng của các mô-đun truyền thống, để đáp ứng nhu cầu kinh doanh của riêng họ và tối ưu hóa hiệu quả vận hành, họ cũng đã thêm các cách triển khai mã khác nhau vào các mô-đun IBC tương ứng.

Ngoài các vấn đề bảo mật trong liên kết IBC nêu trên, các vấn đề bảo mật khác như phần mềm trung gian IBC cũng đang nổi lên, tôi tin rằng trong tương lai, các vấn đề bảo mật trong mô-đun IBC sẽ trở thành một phần quan trọng của an ninh sinh thái Cosmos.

Tóm tắt

Trong quá trình khám phá và nghiên cứu tính bảo mật của hệ sinh thái Cosmos, chúng tôi đã trải qua công việc kiểm tra, tóm tắt và phân loại phức tạp, thảo luận về các vấn đề bảo mật của các giao thức Cosmos SDK và IBC, những giao thức quan trọng nhất trong hệ sinh thái Cosmos và thông qua các giao thức phong phú. kinh nghiệm thực tế, tổng hợp nhiều kinh nghiệm kiểm toán thông thường.

Báo cáo này nêu bật những thách thức phải đối mặt khi đối mặt với các mạng không đồng nhất hỗ trợ tương tác chuỗi chéo. Do tính phức tạp và phân tán của các thành phần cấu thành nên việc thực hiện kiểm tra bảo mật trên các thành phần này cũng không kém phần khó khăn. Chúng tôi không chỉ cần sử dụng các thành phần hiện có kinh nghiệm bảo mật để khắc phục một số rủi ro bảo mật cố hữu, bạn cũng cần liên tục đối mặt với các tình huống bảo mật mới và phân tích các vấn đề bảo mật mới.

Mặc dù vậy, chúng tôi vẫn tin rằng thông qua một số tình huống phổ biến và các vấn đề bảo mật được tóm tắt trong báo cáo này, tính bảo mật tổng thể của hệ sinh thái mạng không đồng nhất Cosmos có thể dần được cải thiện.