Hệ sinh thái Cosmos, nổi tiếng toàn cầu là một trong những mạng blockchain lớn nhất và đáng chú ý nhất, ưu tiên khả năng tương tác blockchain. Trọng tâm này là chìa khóa để tạo điều kiện giao tiếp liền mạch giữa các blockchain đa dạng. Hệ sinh thái này là nơi có một số dự án hàng đầu như Celestia và dYdX v4, tất cả đều được phát triển bằng giao thức Cosmos SDK và IBC. Sự ưa thích ngày càng tăng của các nhà phát triển đối với các thành phần của Cosmos đã dẫn đến tác động ngày càng tăng của các vấn đề bảo mật trong hệ sinh thái. Một trường hợp điển hình là lỗ hổng Dragonfruit trong Cosmos SDK, làm gián đoạn hoạt động trong nhiều blockchain công cộng chính thống.

Với sự phân tán của các thành phần cốt lõi của Cosmos, các nhà phát triển thường phải điều chỉnh và mở rộng các thành phần này dựa trên nhu cầu chức năng cụ thể. Điều này dẫn đến việc phân mảnh của thách thức về bảo mật trong hệ sinh thái Cosmos. Do đó, có một nhu cầu cấp bách cho một phương pháp cấu trúc để hiểu và giải quyết những vấn đề bảo mật này. Bài viết này nhằm mục đích cung cấp một phân tích toàn diện về cảnh quan bảo mật hiện tại trong hệ sinh thái Cosmos và để đề ra các chiến lược phản ứng hiệu quả.

Nhóm CertiK tận tụy trong việc tăng cường an ninh cho mạng lưới Cosmos và hệ sinh thái Web3 rộng lớn thông qua nghiên cứu và phát triển liên tục. Chúng tôi rất háo hức chia sẻ các phát hiện và thông tin cùng bạn qua các báo cáo an ninh định kỳ và cập nhật nghiên cứu kỹ thuật. Nếu bạn có bất kỳ yêu cầu nào, nhóm của chúng tôi luôn sẵn sàng để liên hệ.

Đây là toàn bộ văn bản của “Hướng dẫn Bảo mật Hệ sinh thái Cosmos” 👇.

Tổng quan về Cosmos

Được coi là một trong những hệ sinh thái blockchain nổi bật nhất thế giới, Cosmos nổi bật với khả năng mạng mã nguồn mở, có khả năng mở rộng và giao thoa giữa các chuỗi khối. Được phát triển bởi nhóm CometBFT, ban đầu được biết đến với tên gọi là Tendermint, Cosmos nhằm mục tiêu loại bỏ các kho dữ liệu và tạo điều kiện cho khả năng tương tác giữa các chuỗi khối đa dạng. Trong một thời đại mà nhiều mạng blockchain tồn tại song song, nhu cầu về tương tác giữa các chuỗi khối là cấp thiết hơn bao giờ hết.

Cosmos phân biệt bản thân bằng việc cung cấp một mô hình cross-chain hiệu quả, đặc biệt là có lợi cho các chuỗi công cộng với các trọng tâm dọc đứng cụ thể. Cơ sở hạ tầng blockchain modular của nó tạo điều kiện cho các nhà phát triển ứng dụng, cung cấp cho họ sự linh hoạt để lựa chọn và sử dụng các chuỗi công cộng phù hợp với yêu cầu cụ thể của họ.

Tại trung tâm của hệ sinh thái Cosmos là Giao thức Liên-Blockchain (IBC), kết nối ứng dụng và giao thức trên các blockchain độc lập khác nhau. Điều này không chỉ tạo điều kiện cho việc chuyển tài sản và dữ liệu một cách liền mạch mà còn phù hợp với tầm nhìn của Cosmos về việc tạo ra một 'internet của các blockchain.' Khái niệm này mơ ước một mạng lưới rộng lớn các blockchain tự trị và dễ phát triển, được kết nối để mở rộng và tương tác.

Sự Tham Gia và Nghiên Cứu về An Ninh của CertiK trong Cosmos

Trong một khoảng thời gian dài, CertiK đã sâu rộng tham gia nghiên cứu về hệ sinh thái Cosmos. Đội ngũ của chúng tôi đã có được kinh nghiệm đáng kể trong việc đối phó với các thách thức về bảo mật trong môi trường này. Trong báo cáo này, chúng tôi sẽ chia sẻ quan điểm và khám phá của chúng tôi về bảo mật hệ sinh thái Cosmos, tập trung vào bốn lĩnh vực chính: bảo mật Cosmos SDK, bảo mật giao thức IBC, bảo mật CometBFT và bảo mật CosmWasm. Cuộc thảo luận của chúng tôi sẽ bao gồm mọi thứ từ các thành phần cơ bản của hệ sinh thái Cosmos đến chuỗi cơ bản và ứng dụng của nó. Bằng cách xem xét và suy luận các vấn đề liên quan, chúng tôi nhằm trình bày một phân tích toàn diện từ góc nhìn từ dưới lên về các khía cạnh bảo mật quan trọng trong hệ sinh thái Cosmos.

Với sự phức tạp và đa dạng của hệ sinh thái Cosmos, nó đối mặt với một loạt các thách thức về bảo mật. Báo cáo này chủ yếu tập trung vào những mối đe dọa đặc biệt và quan trọng nhất đối với chuỗi sinh thái của Cosmos. Để biết thêm thông tin hoặc thảo luận về các khía cạnh bảo mật khác, chúng tôi khuyến khích bạn liên hệ với các kỹ sư bảo mật của CertiK.

Nền tảng

CometBFT: Nâng cao tính linh hoạt qua chuỗi tại lõi của nó

Ở trái tim của khả năng mở rộng Interchain đặt ở CometBFT, một thuật toán đồng thuận tiên tiến quan trọng để đảm bảo an ninh, phân cấp và tính toàn vẹn của hệ sinh thái Interchain. Thuật toán này là một sự kết hợp của hai thành phần chính: CometBFT Core, làm nhiệm vụ như công cụ đồng thuận cơ bản, và một giao diện chuỗi khối ứng dụng chung (ABCI). Bằng cách kết hợp các yếu tố của PBFT (Tính khả thi của Lỗi Byzantine) và Proof of Stake (PoS) bảo đảm, CometBFT đồng bộ hóa các nút để duy trì các bản ghi giao dịch chính xác, do đó đóng một vai trò quan trọng trong sự đồng thuận của người xác minh trong môi trường Interchain.

Cosmos SDK: Tăng tốc Phát triển Blockchain với tính linh hoạt

Cosmos SDK đứng như một bộ công cụ mạnh mẽ giúp đơn giản hóa và tăng tốc quá trình phát triển blockchain. Thiết kế theo mô-đun và các tính năng có thể cắm được của nó giúp các nhà phát triển xây dựng các blockchain hoặc các thành phần chức năng riêng trên thuật toán đồng thuận CometBFT. Cách tiếp cận này không chỉ giảm bớt quá trình phát triển mà còn rút ngắn đáng kể chu kỳ phát triển. Hiệu quả của SDK được thể hiện thông qua việc áp dụng của nó trong nhiều dự án, bao gồm Cronos, Kava, và dYdX V4 vừa ra mắt gần đây. Nhìn vào tương lai, Cosmos SDK dự định tăng cường tính mô-đun hóa và giới thiệu các tính năng mới, tạo điều kiện cho việc tạo ra các ứng dụng phức tạp và mô-đun hơn, từ đó nuôi dưỡng một hệ sinh thái rộng lớn và mạnh mẽ hơn.

Giao thức IBC: Thúc đẩy Tích hợp và Khả năng Mở rộng qua các chuỗi khối

Giao thức Truyền thông Liên chuỗi (IBC) là yếu tố then chốt trong việc hỗ trợ việc truyền dữ liệu an toàn, phi tập trung và không cần phép giữa các chuỗi khối trong mạng lưới Cosmos. Với việc 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 được kết nối thông qua công nghệ relay, vai trò của giao thức IBC trong việc nâng cao khả năng mở rộng và tương thích là trung tâm. Trong tâm điểm hiện tại của Quỹ Liên chuỗi là việc cải thiện các khía cạnh này của giao thức IBC, nhằm mục đích củng cố sự tương tác liền mạch trên các chuỗi khối, ứng dụng và hợp đồng thông minh trong hệ sinh thái Cosmos.

CosmWasm: Hỗ trợ Triển khai Ứng dụng Phi tập trung

CosmWasm (Cosmos WebAssembly) là một framework hợp đồng thông minh được tùy chỉnh cho hệ sinh thái Cosmos. Dựa trên WebAssembly, nó cho phép các nhà phát triển triển khai ứng dụng phi tập trung mà không cần quyền hạn cụ thể. Framework này cho phép các nhà phát triển blockchain tách sản phẩm phát triển từ phát triển blockchain, giảm gánh nặng về nâng cấp của người xác minh. Các tính năng của CosmWasm bao gồm kiến trúc modular, tích hợp với Cosmos SDK, và khả năng giao tiếp giữa các chuỗi. Cosmos SDK và giao thức IBC, với mức độ chín chắn tương đối, được sử dụng rộng rãi trong hệ sinh thái Cosmos hiện tại.

Tùy chỉnh và Tùy biến trong Hệ sinh thái Cosmos

Đối với các nhà phát triển chuỗi trong hệ sinh thái Cosmos, Cosmos SDK đáp ứng hầu hết các nhu cầu tùy chỉnh. Trong quá trình hoạt động qua chuỗi, các nhà phát triển chuỗi có thể tinh chỉnh các mô-đun IBC của họ cho các hoạt động đặc biệt hoặc tối ưu hiệu suất. Trong khi một số chuỗi điều chỉnh các engine cơ bản như CometBFT Core, hạn chế không gian ngăn cản việc thảo luận chi tiết về những sửa đổi đó trong báo cáo này. Do đó, nghiên cứu này chủ yếu tập trung vào những sự tinh tế kỹ thuật và xem xét về an ninh của Cosmos SDK và giao thức IBC.

Hướng dẫn an ninh Cosmos SDK

Hướng dẫn Bảo mật Cosmos SDK cung cấp cái nhìn tổng quan toàn diện về các khía cạnh bảo mật của Cosmos SDK, một framework tiên tiến cho việc phát triển ứng dụng blockchain và giao thức phi tập trung. Được tạo ra bởi Interchain Foundation, framework này quan trọng đối với mạng lưới Cosmos, một mạng lưới rộng lớn của các blockchain liên kết với nhau.

Ở trung tâm của nó, SDK Cosmos được thiết kế để tối ưu hóa việc tạo ứng dụng blockchain tùy chỉnh trong khi tạo điều kiện tương tác mượt mà giữa các blockchain đa dạng. Các tính năng đáng chú ý của nó bao gồm cấu trúc modular, khả năng tùy chỉnh mở rộng, tích hợp với CometBFT Core cho sự nhất quán, và việc triển khai các giao diện IBC, tất cả đều đóng góp vào sự hấp dẫn của nó đối với các nhà phát triển. Một điểm mạnh quan trọng của SDK Cosmos là sự phụ thuộc vào động cơ nhất quán CometBFT Core, cung cấp các biện pháp bảo mật mạnh mẽ. Động cơ này đóng vai trò quan trọng trong việc bảo vệ mạng lưới khỏi các cuộc tấn công độc hại và bảo vệ tài sản và dữ liệu của người dùng. Tính cấu trúc modular của SDK giúp người dùng tạo ra các module tùy chỉnh một cách dễ dàng. Tuy nhiên, các nhà phát triển phải cảnh giác vì lỗ hổng bảo mật vẫn có thể phát sinh khi triển khai ứng dụng sử dụng SDK Cosmos.

Từ quan điểm của việc kiểm toán an ninh, việc đánh giá kỹ lưỡng các mối đe dọa an ninh tiềm năng từ nhiều góc độ là rất quan trọng. Ngược lại, trong nghiên cứu an ninh, sự tập trung chuyển sang việc xác định những lỗ hổng có thể có hậu quả quan trọng. Cách tiếp cận này nhằm mục tiêu giảm thiểu nguy cơ an ninh lớn ngay lập tức, qua đó cung cấp sự hỗ trợ hiệu quả hơn cho các dịch vụ tích hợp SDK. Việc xác định và xem xét kỹ lưỡng những lỗ hổng đe dọa nghiêm trọng và có tác động lan rộng là rất quan trọng.

Một điểm trọng tâm trong Cosmos SDK là giao diện ABCI, quan trọng đối với hệ sinh thái Cosmos. Giao diện này bao gồm bốn thành phần chính: BeginBlock, EndBlock, CheckTx và DeliverTx. BeginBlock và EndBlock trực tiếp liên quan đến logic thực thi của các khối cá nhân. Ngược lại, CheckTx và DeliverTx liên quan đến xử lý sdk.Msg, cấu trúc dữ liệu cơ bản cho việc truyền tin trong hệ sinh thái Cosmos.

Để hiểu và giải quyết các lỗ hổng bảo mật được đề cập, người ta phải trước tiên nắm vững vòng đời giao dịch trong hệ sinh thái Cosmos. Các giao dịch bắt nguồn từ các tác nhân người dùng, nơi chúng được tạo ra, ký, sau đó được phát sóng đến các nút blockchain. Phương thức CheckTx được sử dụng bởi các nút để xác thực chi tiết giao dịch như chữ ký, số dư của người gửi, chuỗi giao dịch và khí được cung cấp. Các giao dịch hợp lệ được xếp hàng trong mempool, chờ để được bao gồm trong một khối, trong khi những giao dịch không hợp lệ sẽ bị từ chối, với thông báo lỗi được truyền đến người dùng. Trong quá trình xử lý khối, phương thức DeliverTx được áp dụng để đảm bảo tính nhất quán và xác định của giao dịch.

Trong Cosmos SDK, vòng đời giao dịch là quá trình đa giai đoạn, bao gồm việc tạo, xác thực, bao gồm trong một khối, thay đổi trạng thái, và cam kết cuối cùng. Quá trình này có thể được phác thảo trong các bước sau:

1. Tạo giao dịch: Người dùng tạo giao dịch bằng cách sử dụng các công cụ khác nhau như Giao diện Dòng Lệnh (CLI) hoặc các khách hàng giao diện người dùng.

2. Thêm vào Mempool: Sau khi tạo, giao dịch được đưa vào mempool. Tại đây, các nút gửi một thông điệp ABCI (Giao diện Chuỗi khối Ứng dụng), được biết đến là CheckTx, tới tầng ứng dụng để kiểm tra tính hợp lệ. Giao dịch trải qua quá trình giải mã từ định dạng byte sang định dạng Tx. Mỗi sdk.Msg trong giao dịch phải trải qua các kiểm tra trạng thái sơ bộ bởi hàm ValidateBasic(). Ngoài ra, nếu ứng dụng bao gồm một anteHandler, logic của nó được thực thi trước hàm runTx, dẫn đến hàm RunMsgs() để xử lý nội dung sdk.Msg. Kết quả CheckTx thành công dẫn đến việc giao dịch được xếp hàng trong mempool địa phương, sẵn sàng để được bao gồm trong khối tiếp theo, và đồng thời được phát sóng tới các nút đồng đẳng thông qua P2P.

3. Bao gồm trong một Khối Đề Xuất: Khi bắt đầu mỗi vòng, người đề xuất tổ chức một khối chứa giao dịch gần đây. Các máy chủ xác minh, người chịu trách nhiệm duy trì sự nhất quán, có thể chấp nhận khối này hoặc chọn một khối trống.

4. Thay đổi trạng thái: Tương tự như CheckTx, quá trình DeliverTx lặp lại các giao dịch khối. Tuy nhiên, nó hoạt động ở chế độ 'Deliver', thực thi các thay đổi trạng thái. MsgServiceRouter chuyển hướng các tin nhắn giao dịch khác nhau đến các mô-đun tương ứng, nơi mà mỗi tin nhắn được xử lý trong Msg Server. Sau khi thực thi tin nhắn, các kiểm tra tiếp theo đảm bảo tính hợp lệ của giao dịch. Nếu bất kỳ kiểm tra nào thất bại, trạng thái sẽ quay trở lại trạng thái trước đó. Một bộ đếm Gas theo dõi gas đã tiêu thụ trong quá trình thực thi. Các lỗi liên quan đến Gas, như gas không đủ, dẫn đến việc quay trở lại các thay đổi trạng thái, tương tự như việc thực thi thất bại.

5. Cam kết khối: Khi nhận đủ phiếu từ máy chủ xác nhận, một nút sẽ cam kết khối mới vào blockchain. Hành động này hoàn tất các chuyển đổi trạng thái tại lớp ứng dụng, đánh dấu việc hoàn tất quá trình giao dịch.

)

[Phần này bao gồm một biểu đồ mô tả vòng đời của các giao dịch trong hệ sinh thái Cosmos.]

[Phần tiếp theo cung cấp logic thực hiện cụ thể của khóa ABCI trong Cosmos SDK, hữu ích để hiểu và phân tích các lỗ hổng được thảo luận sau này.]

)

Các danh mục lỗ hổng thông thường

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

)

Xét đến mức độ nguy hiểm và phạm vi tác động, chúng tôi chủ yếu tập trung vào các lỗ hổng bảo mật được xếp loại là Critical và Major, mà thường gây ra các rủi ro sau:

1. Hoạt động dừng chuỗi
2. Mất vốn tài chính
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à những loại lỗ hổng bảo mật sau đây:

1. Từ chối Dịch vụ
2. Thiết lập trạng thái không đúng
3. Thiếu hoặc xác minh không hợp lý
4. Vấn đề về sự độc nhất
5. Vấn đề thuật toán đồng thuận
6. Nhược điểm logic trong việc thực thi
7. Vấn đề tính năng ngôn ngữ

Phân tích lỗ hổng trong Hệ sinh thái Cosmos

Hệ sinh thái Cosmos, nổi tiếng với cấu trúc mô-đun của mình, thường gặp sự sử dụng mô-đun và gọi mô-đun trong chuỗi của mình. Sự phức tạp này dẫn đến các tình huống mà con đường kích hoạt sự dễ tổn thương và biến số vị trí không nhất quán. Trong việc hiểu những điểm yếu này, quan trọng không chỉ là xem xét con đường kích hoạt mà còn là con đường có thể kiểm soát của các biến số quan trọng của sự dễ tổn thương. Sự tập trung kép này giúp xác định và phân loại mô hình điểm yếu một cách tốt hơn.

Hoạt động Dừng Chuỗi: Nguyên nhân và Loại hình

Dừng chuỗi thường do các vấn đề gặp phải trong quá trình thực thi của một khối duy nhất. Tuy nhiên, lịch sử của Cosmos bao gồm các trường hợp mà lỗ hổng bảo mật đồng thuận đòi hỏi dừng chuỗi hoạt động để sửa chữa. Những vấn đề này rơi vào hai danh mục khác nhau.

Loại đầu tiên thường xuyên được nhìn thấy trong các Lỗ Hổng Từ Chối Dịch Vụ: Đây thường là kết quả của xử lý sự cố không đủ và các hoạt động ranh giới vòng lặp do người dùng ảnh hưởng. Những lỗ hổng như vậy có thể dẫn đến việc chuỗi tạm dừng hoặc chậm lại đáng kể.

Cosmos SDK và CometBFT, cơ sở hạ tầng chính trong hệ sinh thái Cosmos, không chỉ được sử dụng bởi các chuỗi cơ sở trong Cosmos mà còn bởi các chuỗi ứng dụng khác dựa trên kiến trúc của chúng. Tất cả đều tuân theo các quy tắc giao diện ABCI của CometBFT. Trọng tâm của bề mặt tấn công của họ cũng nằm ở giao diện ABCI của họ, và hầu hết các lỗ hổng bảo mật có thể gây ra sự tạm dừng chuỗi là các vấn đề có thể ảnh hưởng trực tiếp đến việc thực thi mã khối. Do đó, các con đường xảy ra của chúng nói chung có thể được truy vết ngược lại các giao diện BeginBlock và EndBlock.

Loại thứ hai của tình huống liên quan đến Các Lỗ Hổng Ảnh Hưởng Đến Sự Đồng Thuận: Thường liên quan đến việc triển khai trên nhiều chuỗi và bao gồm các vấn đề trong xác nhận xử lý logic, hiệu chỉnh thời gian và ngẫu nhiên. Những lỗ hổng này ảnh hưởng đến trái tim của nguyên tắc phi tập trung của blockchain. Mặc dù ban đầu chúng có vẻ không nghiêm trọng, nhưng trong tay của một đối tác xấu, chúng đều đe doạ một mối đe dọa bảo mật đáng kể.

Ví dụ về loại đầu tiên

Ví dụ 1: Phân Tích Lỗ Hổng Dự Án Siêu Tân Tinh

Lý do của lỗ hổng: Trong quá trình phân phối tiền tệ trong dự án SuperNova, một vấn đề nghiêm trọng xuất phát từ việc thiếu kiểm tra địa chỉ. Sơ suất này có thể dẫn đến thất bại trong hoạt động và sau đó là thiệt hại tài chính. Cụ thể, mô-đun phát hành, quan trọng cho việc tạo mã token, phụ thuộc vào số lượng đã đặt cược. Tuy nhiên, quá trình này dễ bị lỗi. Ví dụ, nếu hồ bơi được chỉ định không tồn tại hoặc nếu có một lỗi nhập địa chỉ hợp đồng, có thể dẫn đến sự cố trong mô-đun phát hành. Những lỗi này có tiềm năng làm ngừng hoạt động toàn bộ blockchain. Ngoài ra, trong mô-đun hồ bơi phần thưởng, không có kiểm tra cho địa chỉ hợp đồng hồ bơi. Sơ suất này có nghĩa là bất kỳ sự cố nào trong hoạt động phân phối có thể gây ra việc tạm ngừng ngay lập tức của blockchain.

Vị trí lỗ hổng: Liên kết GitHub SuperNova

Mẩu mã dễ tấn cô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:

https://github.com/Carina-labs/nova/commit/538abc771dea68e33fd656031cbcf2b8fe006be0

The patch is located in the message handling module of poolincentive (x/poolincentive/types/msgs.go), not the mint module. It added address verification to the MsgCreateCandidatePool message to eliminate the possibility of incorrect addresses from the root.

Ví dụ 2: Dự án An ninh Mạng lưới Cosmos

Địa chỉ dự án: Liên kết GitHub về Bảo mật Liên mạng Cosmos

Lỗ hổng nền: Các bộ 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áo AssignConsumerKey vào cùng một khối. Trong tập tin x/ccv/provider/keeper/key_assignment.go, chức năng AssignConsumerKey cho phép các bộ xác thực gán các consumerKey khác nhau cho các chuỗi người tiêu dùng được phê duyệt. Danh sách địa chỉ consumerAddrsToPrune tăng thêm một phần tử để thực hiện hoạt động này. Vì danh sách này được lặp lại trong EndBlocker trong tập tin x/ccv/provider/keeper/relay.go, các kẻ tấn công có thể lợi dụng để làm chậm chuỗi cung cấp. Đối với cuộc tấn công này, kẻ tấn công độc hại có thể tạo giao dịch với nhiều thông báo AssignConsumerKey và gửi chúng đến chuỗi cung cấp. Số lượng phần tử trong danh sách địa chỉ consumerAddrsToPrune sẽ giống như số lượng thông báo AssignConsumerKey được gửi. Do đó, việc thực thi EndBlocker sẽ mất nhiều thời gian và tài nguyên hơn dự kiến, làm chậm hoặc thậm chí dừng lại chuỗi cung cấp.

Vị trí lỗ hổng: Liên kết GitHub Cosmos Interchain Security

Đoạn Mã Lỗi:

Con đường kích hoạt lỗ hổng:

msgServer.AssignConsumerKey

Keeper.AssignConsumerKey

AppModule.EndBlock

EndBlockCIS

Xử lý các gói đã vượt tuổi VSC chính

Xử lý Gói Đã Trưởng Thành VSC

PruneKeyAssignments

Ví dụ 3: Dự án Quicksilver - Mô-đun Phát quà

Nền tảng lỗ hổng: BeginBlocker và EndBlocker là các phương pháp tùy chọn mà các 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. Sử dụng sự cố để xử lý lỗi trong phương thức BeginBlock và EndBlock có thể khiến chuỗi dừng trong trường hợp có lỗi. EndBlocker đã không xem xét liệu mô-đun có đủ mã thông báo để giải quyết các airdrop chưa hoàn thành hay không, điều này có thể gây ra sự cố và dừng chuỗi.

Vị trí lỗ hổng: Quicksilver GitHub Link

Đoạn mã lỗi lỗ hổng:

Bản vá lỗ hổng: AppModule.EndBlock

Keeper.EndBlocker

Keeper.EndZoneDrop

Bản vá lỗi: https://github.com/quicksilver-zone/quicksilver/blob/20dc658480b1af1cb323b4ab4a8e5925ee79a0ed/x/airdrop/keeper/abci.go#L16

Mã xử lý hoảng loạn đã được loại bỏ và thay thế bằng việc ghi log lỗi.

Ví dụ 4: Dự án An ninh Liên mạng Cosmos

Địa chỉ dự án: Liên kết GitHub về Bảo mật Mạng lưới Cosmos

Lý do cơ bản của lỗ hổng: Kẻ tấn công có thể thực hiện một 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ỉ thưởng của chuỗi cung cấp. Trong luồng 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 thu hồi số dư của tất cả các mã thông báo trong tstProviderAddr và gửi chúng đến chuỗi cung cấp. Để đạt được điều này, nó phải lặp lại qua tất cả các mã thông báo được tìm thấy trong địa chỉ thưởng và gửi mỗi mã thông qua IBC đến chuỗi cung cấp. Vì bất kỳ ai cũng có thể gửi mã thông báo đến địa chỉ thưởng, kẻ tấn công có thể tạo ra và gửi một số lượng lớn các mã thông báo khác nhau, ví dụ, sử dụng một chuỗi với một mô-đun nhà máy mã thông báo, để khởi xướng một cuộc tấn công từ chối dịch vụ. Do đó, việc thực thi EndBlocker sẽ mất nhiều thời gian và tài nguyên hơn dự kiến, làm chậm hoặc thậm chí dừng lại chuỗi người tiêu dùng.

Vị trí lỗ hổng: Liên kết GitHub Bảo mật Mạng lưới Cosmos

Phân đoạn mã lỗ hổng:

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

AppModule.EndBlock

EndBlock

EndBlockRD

GửiPhầnThưởngChoNhàCungCấp

Loại Thứ Hai Của Tình Huống

Vấn đề này về sự nhất trí có thể không gây ra tổn thất nghiêm trọng ngay lập tức, nhưng khi xem xét các nguyên tắc cơ bản và hệ thống của toàn bộ blockchain, hoặc nhìn vào những lỗ hổng này từ các tình huống cụ thể, tác động và tổn thất của chúng có thể không ít hơn so với các lỗ hổng truyền thống khác. Ngoài ra, những lỗ hổng này có những đặc điểm chung.

Ví dụ 1

Antecedentes de vulnerabilidad: Aviso de seguridad de Cosmos SDK Jackfruit

Hành vi không xác định trong phương thức ValidateBasic của mô-đun x/authz trong Cosmos SDK có thể dễ dẫn đến việc dừng đồng thuận. Cấu trúc thông điệp MsgGrant trong mô-đun x/authz bao gồm một trường Grant, chứa thời gian hết hạn được cấp bởi quyền xác định của người dùng. Trong quá trình xác thực của ValidateBasic() trong cấu trúc Grant, nó so sánh thông tin thời gian của mình 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. Khi thời gian cục bộ không xác định, dấu thời gian có thể khác nhau giữa các nút, dẫn đến vấn đề đồng thuận.

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

• Cosmos Forum Link 1

• Liên kết Diễn đàn Cosmos 2

• Liên kết Cảnh báo Bảo mật GitHub của Cosmos SDK

Đoạn Mã Lỗ Hổng:

Vulnerability patch: Liên kết So sánh GitHub Cosmos SDK

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òn đã xảy ra trên các chuỗi ứng dụng khác nhau.

Ví dụ 2

Lý do dẫn đến lỗ hổng: SuperNova, dự án nova

Địa chỉ dự án: Liên kết GitHub SuperNova

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

Vị trí lỗ hổng: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/icacontrol/keeper/send_msgs.go#L14

Đoạn mã lỗi:

Bản vá lỗ hổng:

Đã chuyển từ việc sử dụng timestamp cục bộ sang việc 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)

Case Three:

Vulnerability Background: Oracle Module in the BandChain Project

Địa chỉ dự án: Bảng điều khiển GitHub của BandChain

Các comment trong kho lưu trữ mã nguồn cho biết rằng mô-đun truy vấn phải được thực thi trước khi đặt cược để thực hiện các biện pháp trừng phạt đối với người vi phạm giao thức truy vấn. Tuy nhiên, trong mã nguồn, thứ tự lại bị đảo ngược: trong hàm SetOrderEndBlockers, mô-đun đặt cược chạy trước mô-đun truy vấn. Nếu mô-đun đặt cược được thực thi trước mô-đun truy vấn, sẽ không thể áp dụng các hình phạt dựa trên các xác minh hoàn thành trong mô-đun truy vấn.

Vị trí của lỗ hổng: Đoạn mã GitHub của BandChain

Mã Đoạn Mã Rủi Ro:

Sự yếu đuối nằm ở việc hiện thực hóa thực tế và những bình luận trái ngược, nơi mô-đun truy vấn nên được đặt trước mô-đun đặt cược.

Trường hợp bốn:

Nền tảng Lỗ hổng: Mô-đun Kiểm soát Truy cập trong Dự án Sei Cosmos

Địa chỉ URL dự án: Dự án GitHub của Sei Cosmos

Trong nhiều trường hợp trên các kho lưu trữ mã nguồn liên quan đến Cosmos, có sử dụng kiểu bản đồ của ngôn ngữ Go và lặp lại qua nó. Do tính không xác định của việc lặp qua bản đồ của Go, điều này có thể dẫn đến các nút đạt đến trạng thái khác nhau, tiềm ẩn vấn đề về đồng thuận và sau đó ngừng chuỗi hoạt động. Một phương pháp phù hợp hơn sẽ là sắp xếp các khóa bản đồ vào một slice và lặp qua các khóa đã được sắp xếp. Những vấn đề như vậy rất phổ biến, bắt nguồn từ việc áp dụng các tính năng của ngôn ngữ.

Trong việc thực hiện của BuildDependencyDag trong x/accesscontrol/keeper/keeper.go, có sự lặp lại qua các nút anteDepSet. Do hành vi không xác định của việc lặp qua bản đồ trong Go, ValidateAccessOp có thể dẫn đến hai loại lỗi khác nhau, tiềm ẩn dẫn đến sự thất bại trong việc đạt được sự nhất quán.

Vị trí của lỗ hổng: Mã nguồn GitHub của Sei Cosmos

Đoạn Mã Lỗi:

Từ những trường hợp này, rõ ràng thấy rằng các lỗ hổng gây cho một chuỗi dừng hoạt động một cách passively thường là nguy hại nhất. Logic gây ra của chúng có thể được truy nguồn trực tiếp đến việc ảnh hưởng đến quy trình thực thi của các khối cá nhân trong một blockchain. Ngược lại, các lỗ hổng về bảo mật đồng thuận thường dẫn đến việc chuỗi dừng hoạt động để triển khai các sửa đổi, với logic gây ra của chúng được truy nguồn đến việc ảnh hưởng đến luồng hoạt động tổng thể và trạng thái của blockchain. Điều này khác biệt so với việc tập trung vào các lỗ hổng dẫn đến mất mát tài chính, nơi tác động nguy hiểm cụ thể không được đánh giá dựa trên con đường logic của việc xảy ra vấn đề mà tập trung vào chủ sở hữu của các quỹ, số tiền liên quan, phạm vi và các phương pháp ảnh hưởng đến các quỹ.

mất tiền

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

Mất vốn thường gặp trong các trường hợp như tiêu thụ khí, tài khoản bị khóa và không thể rút tiền, mất tiền trong quá trình chuyển khoản, lỗi trong logic tính toán dẫn đến mất tiền và không đảm bảo tính duy nhất của ID lưu trữ quỹ.

Ở đâ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 tảng Sự yếu đuối: Dự án Siêu Nhân Tạo

Địa chỉ URL dự án: https://github.com/Carina-labs/nova

Nếu số thập phân trong một khu vực vượt quá 18, các quỹ có thể bị khóa. Trong mã dự án này, không có giới hạn trên số thập phân của khu vực, có thể vượt quá 18. Trong ClaimSnMessage, khi người dùng muốn đòi lại các mã thông báo của họ, ClaimShareToken được sử dụng. Tuy nhiên, nếu số thập phân của khu vực vượt quá 18, quá trình chuyển đổi sẽ thất bại và sẽ không thể rút tài sản khỏi hệ thống. Do đó, bằng cách kiểm soát số thập phân của một khu vực, có thể trực tiếp gây ra sự cố và thất bại giao dịch.

Vị trí của lỗ hổng: https://github.com/Carina-labs/nova/blob/v0.6.3/x/gal/keeper/claim.go#L167

Mảnh mã lỗi:

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

msgServer.ClaimSnAsset

Keeper.ClaimShareToken

Keeper.ConvertWAssetToSnAssetDecimal

Hệ số nhân chính xác

• Lỗ hổng nền: Dự án SuperNova

Địa chỉ dự án: https://github.com/Carina-labs/nova/

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

Vị trí lỗ hổng: https://github.com/Carina-labs/nova/blob/v0.6.3/x/icacontrol/keeper/msg_server.go#L99

Đoạn mã dễ bị tấn công:

Bản vá lỗi: Thêm kiểm tra DenomDuplicateCheck

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

• Lý do dẫn đến lỗ hổng: Dự án Supernova

Địa chỉ dự án: https://github.com/Carina-labs/nova/

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

Vị trí lỗ hổng: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/gal/keeper/msg_server.go#L356

Đoạn mã dễ bị tấn công:

Dựa trên đoạn trích này, chúng ta có thể nhận biết rằng logic chính của các hoạt động liên quan đến quỹ chủ yếu phụ thuộc vào việc xử lý các tin nhắn khác nhau. Tất nhiên, cũng có trường hợp như kịch bản đầu tiên liên quan đến các hoạt động đúc tiền trong quá trình thực hiện BeginBlock. Khi những hoạt động này thất bại, chúng cũng có thể dẫn đến mất mát tài chính. Tổng thể, bằng việc tập trung kiểm toán của chúng ta vào các mô-đun mã nguồn mở liên quan đến các hoạt động tài chính, chúng ta có thể tăng đáng kể khả năng phát hiện 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 danh mục vấn đề này khá rộng. Hai loại rủi ro đầu tiên mà chúng ta đã thảo luận cũng có thể được coi là các phần con của các lỗ hổng ảnh hưởng đến trạng thái hệ thống hoặc hoạt động bình thường. Ngoài ra, nguy hiểm hơn là các lỗ hổng logic khác nhau. Đến một mức độ lớn, những lỗ hổng này tạo ra các rủi ro bảo mật khác nhau theo logic kinh doanh của dự án. Tuy nhiên, do sự tương đồng trong cấu trúc của các thành phần Cosmos SDK và tính modul của chúng, những lỗi tương tự thường xảy ra trong các triển khai mã cụ thể. Ở đây, chúng tôi liệt kê một số loại lỗ hổng phổ biến:

- Kiểm tra biến không hoàn chỉnh trong loại sdk.Msg:

Vì đã có nhiều dự án triển khai một loạt các loại phát sinh dựa trên sdk.Msg, không phải tất cả các phần tử của các loại hiện có đã được kiểm tra một cách tương ứng trong Cosmos SDK. Điều này đã dẫn đến việc bỏ qua việc kiểm tra biến nhúng quan trọng, từ đó đặt ra một số rủi ro về an ninh.

Trường hợp nghiên cứu: Cảnh báo an ninh Cosmos SDK Barberry

Lịch sử lỗ hổng: Phương thức MsgCreatePeriodicVestingAccount.ValidateBasic thiếu cơ chế đánh giá tình trạng của một tài khoản, chẳng hạn như việc nó có hoạt động hay không. Trong PeriodicVestingAccount được xác định trong x/auth, một kẻ tấn công có thể khởi tạo tài khoản của nạn nhân thành một tài khoản bị chiếm đoạt độc hại. Tài khoản này cho phép gửi tiền nhưng cấm 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 sẽ không thể rút tiền.

Bản vá lỗi:

https://forum.cosmos.network/t/cosmos-sdk-security-advisory-barberry/10825

https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-j2cr-jc39-wpx5

https://github.com/cosmos/cosmos-sdk/compare/v0.47.3-rc.0...v0.47.3

https://github.com/cosmos/cosmos-sdk/pull/16465

Mẫu mã nguồn dễ bị tấn công:

Ngoài ra, các vấn đề trong giai đoạn ValidateBasic cũng xuất hiện trong Cosmos-SDK Security Advisory Elderflower và Cosmos-SDK Security Advisory Jackfruit. Vấn đề trước mắc phải sai sót trực tiếp của cuộc gọi ValidateBasic, trong khi vấn đề sau liên quan đến việc xác minh biến thời gian trong thông điệp. Trong các chuỗi ứng dụng, những vấn đề như vậy càng 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 biện pháp xác minh xử lý thông điệp của họ.

Ngoài các loại xác minh, cũng có những vấn đề gặp phải trong logic xử lý của sdk. Bột ngọt, chẳng hạn như các hoạt động liên quan đến việc tiêu thụ khí trên diện rộng, vòng lặp và xử lý sự cố không hợp lý. Vì chuỗi xử lý cho các tin nhắn có cơ chế khôi phục tương ứng, mức độ nguy hiểm của chúng có phần thấp hơn so với việc tắt chuỗi hoàn toàn. Tuy nhiên, chúng vẫn có thể ảnh hưởng đến hoạt động bình thường của hệ thống hoặc dẫn đến mất tiền trên chuỗi.

Loại Lỗ Hổng Phổ Biến

Loại trừ các lỗ hổng duy nhất cho các hoạt động dự án cụ thể, có một số mô hình lỗ hổng phổ biến hơn. Ví dụ, trường hợp mất tiề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 tương tự như trong các hợp đồng thông minh, trong đó việc thay đổi trạng thái trước khi chuyển tiền có thể dẫn đến các vấn đề như nhập lại hoặc các trạng thái sai lầm kéo dài. Các kịch bản trong đó cài đặt trạng thái gắn chặt với việc truyền tin nhắn là khá phổ biến trong blockchain và nhiều lỗ hổng đáng kể bắt nguồn từ các vấn đề như vậy. Bên cạnh đó, có các lỗ hổng bảo mật tính toán như lỗi chia bằng không, bỏ qua tiêu thụ gas và sử dụng các phiên bản có lỗ hổng đã biết, tất cả đều có thể ảnh hưởng đến trạng thái hoặc hoạt động bình thường của hệ thống.

Vấn đề về tính độc đáo

Do toàn bộ các hoạt động đọc và ghi trên blockchain, tính duy nhất trong việc đặt tên rất quan trọng trong một số chức năng. Ví dụ, trường hợp thứ hai của việc mất quỹ đã đề cập trước đó là một vấn đề về tính duy nhất. Hơn nữa, việc tổ hợp các tiền tố trong các biến đại diện cho các khóa, chẳng hạn như chuỗi hoặc mảng byte, có thể gây ra các rủi ro. Một sơ suất nhỏ có thể dẫn đến việc các tên bị hiểu lầm, dẫn đến các vấn đề như mất quỹ hoặc lỗi đồng thuận.

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

Những vấn đề này rộng lớn hơn nhưng có những đặc điểm nhận dạng, giúp phát hiện chúng dễ dàng hơn. Ví dụ bao gồm các vấn đề với việc lặp qua bản đồ trong Golang hoặc cơ chế hoảng loạn trong Rust. Được khuyến nghị là liệt kê những yếu tố rủi ro cụ thể của từng ngôn ngữ này và chú ý đặc biệt đến chúng trong quá trình sử dụng hoặc kiểm toán để giảm thiểu các lỗi như vậy.

Tóm tắt

Từ việc khám phá vấn đề bảo mật cơ bản trong hệ sinh thái Cosmos, rõ ràng rằng những vấn đề này không phải là duy nhất đối với Cosmos và có thể áp dụng cho các hệ sinh thái blockchain khác. Dưới đây là một số đề xuất và kết luận liên quan đến vấn đề bảo mật trong hệ sinh thái Cosmos:

• Chú ý đến các lỗ hổng cơ sở hạ tầng: Các thành phần cốt lõi như CometBFT và Cosmos SDK cũng có thể có lỗ hổng, vì vậy việc cập nhật và bảo trì định kỳ là cần thiết cho bảo mật.

• Xem xét thư viện bên thứ ba ngay lập tức: Nhà phát triển Cosmos thường sử dụng các thư viện bên thứ ba để mở rộng các chức năng của ứng dụng của họ. Những thư viện này có thể chứa các lỗ hổng tiềm ẩn, do đó cần được xem xét và cập nhật để giảm thiểu rủi ro.

• Hãy cẩn thận với các cuộc tấn công của nút độc hại: Các nút đồng thuận rất quan trọng trong hệ sinh thái Cosmos. Các thuật toán dung sai Byzantine của những nút này có thể dễ bị tấn công, vì vậy đảm bảo an ninh nút là rất quan trọng để ngăn chặn hành vi độc hại.

• Xem xét về an ninh vật lý: Các biện pháp an ninh vật lý cần thiết cho phần cứng và máy chủ chạy các nút Cosmos để ngăn chặn việc truy cập trái phép và các cuộc tấn công tiềm ẩn.

• Tiến hành kiểm tra mã nguồn cần thiết: Với sự mở cửa của hệ sinh thái Cosmos SDK và CometBFT, các nhà phát triển và kiểm toán viên nên xem xét cả mã nguồn nhân văn và mã nguồn được viết trong các module tùy chỉnh để xác định và sửa chữa các vấn đề bảo mật tiềm ẩn.

• Chú ý đến các công cụ hệ sinh thái: Hệ sinh thái Cosmos bao gồm nhiều công cụ và ứng dụng, cũng cần trải qua các đánh giá bảo mật và cập nhật định kỳ để đảm bảo an toàn.

Hướng dẫn an ninh giao thức IBC

Mô-đun này tập trung vào các khía cạnh bảo mật của giao thức Giao tiếp Liên chuỗi (IBC), một thành phần quan trọng trong hệ sinh thái Cosmos. Giao thức IBC hoạt động như một cầu nối cho sự tương tác giữa các chuỗi khối khác nhau. Trong khi các cầu nối liên chuỗi khác cung cấp các giải pháp cho các vấn đề cụ thể, cô lập, giao thức IBC cung cấp một giải pháp cơ bản thống nhất và hỗ trợ kỹ thuật cơ bản cho các tương tác giữa chuỗi. IBC là một giao thức cho phép các chuỗi khối không đồng nhất chuyển dữ liệu bất kỳ một cách đáng tin cậy, có trật tự và ít tin cậy nhất.

Kể từ khi Bitcoin xuất hiện, lĩnh vực blockchain đã trải qua sự phát triển bùng nổ. Vô số mạng lưới mới đã nổi lên, mỗi mạng lưới đều có đề xuất giá trị độc đáo, cơ chế đồng thuận, tư tưởng, người ủng hộ và lý do tồn tại riêng. Trước khi IBC được giới thiệu, những mạng lưới blockchain này hoạt động độc lập, giống như trong các container đóng, không thể giao tiếp với nhau, một mô hình cơ bản không bền vững.

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

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

1. Minh bạch về niềm tin

2. Có khả năng hỗ trợ các chuỗi khối không đồng nhất

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

4. Một công nghệ chín chắn, đã được thử nghiệm

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

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

• IBC TAO: Định nghĩa các tiêu chuẩn cho việc truyền gói dữ liệu, xác thực và sắp xếp, về cơ bản là tầng cơ sở hạ tầng. Trong ICS (Tiêu chuẩn Liên chuỗi), điều này bao gồm các danh mục cốt lõi, khách hàng và người chuyển giao.

• IBC APP: Xác định các tiêu chuẩn cho trình xử lý ứng dụng của các gói dữ liệu được truyền qua lớp truyền tải. 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à tài khoản liên chuỗi (ICS-27) và có thể được tìm thấy trong danh mục ứng dụng của ICS.

Giao thức IBC (Từ Cổng thông tin Phát triển Cosmos)

Giao thức IBC (Giao tiếp Giữa Các Blockchain) là một điểm mốc quan trọng của tầm nhìn về “Internet của Các Blockchain” trong hệ sinh thái Cosmos. Trong ngữ cảnh này, các lựa chọn thiết kế của IBC được ảnh hưởng bởi các tiêu chuẩn 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 trừu tượng phổ quát cho phép các blockchain giao tiếp với nhau. Giống như TCP/IP không hạn chế nội dung của các gói dữ liệu được truyền qua mạng, IBC hoạt động theo cùng cách. Hơn nữa, tương tự như cách các giao thức ứng dụng như HTTP và SMTP được xây dựng dựa trên TCP/IP, các ứng dụng như việc chuyển giao tài sản đồng nhất/tài sản không thể thay thế hoặc các cuộc gọi hợp đồng thông minh chéo chuỗi cũng sử dụng giao thức IBC như một lớp cơ sở.

Những vấn đề chính hiện tại thấy được với giao thức IBC liên quan đến truyền kênh và xử lý gói tin. Có những vấn đề lớn trong việc xác minh chứng cứ, nhưng những vấn đề này tương đối ít gặp. Bài viết này tập trung vào các vấn đề phổ biến của giao thức IBC. Nhờ vào 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 quan tâm đến các chi tiết cơ bản như khách hàng, kết nối và xác minh chứng cứ. Tuy nhiên, họ cần triển khai giao diện IBCModule và các phương pháp xử lý Keeper tương ứng. Do đó, nhiều vấn đề liên quan đến giao thức IBC phát sinh trong các đường dẫn mã của các giao diện IBCModule để nhận và xử lý gói tin (onRecvPacket, OnAcknowledgementPacket, OnTimeoutPacket, vv.).

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

Trong hệ sinh thái Cosmos, giao thức IBC phục vụ như một trung tâm kết nối. Các loại lỗ hổng liên quan đến giao thức IBC là đa dạng và phức tạp do tích hợp chặt chẽ của các triển khai với các module như Cosmos-SDK và CometBFT. Ngoài ra, vì IBC chủ yếu được sử dụng trong hệ sinh thái Cosmos, ngôn ngữ lập trình chính của nó là Golang, như được mô tả trong tài liệu ibc-go.

Do vấn đề về không gian, bài viết này không đi sâu vào phân tích chi tiết từng khía cạnh và thành phần của giao thức IBC. Thay vào đó, nó phân loại một số lỗ hổng bảo mật hiện có. Để có một phân tích chi tiết và toàn diện hơn, bạn có thể liên hệ với các kỹ sư an ninh của chúng tôi tại CertiK để thảo luận.

Phân loại lỗ hổng thông thường:

1. Các lỗ hổng về tên

   ① Xử lý Chuỗi Luồng Nguồn

   ② Xử lý Lỗ hổng Bytecode

2. Các Lỗ Hổng Trong Quá Trình Truyền Tải

   ① Lỗ hổng Đặt hàng Gói tin

   ② Lỗ hổng về thời gian chờ gói tin

   ③ Các Lỗ Hổng Xác Thực Gói Tin

   ④ Các Lỗ Hổng Gói Dữ Liệu Khác

3. Rủi ro Logic

   ① Cập Nhật Rủi Ro Trạng Thái

   ② Lỗ hổng Bỏ phiếu và Đồng thuận

   ③ Các Lỗ Hổng Logic Khác

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

Công nghệ IBC hiện tại, đối với việc kiểm toán và phân tích về mặt bảo mật, chia sẻ nhiều điểm tương đồng với quy trình kiểm toán của các giao thức Web2. Phân tích này sẽ phân tích chi tiết một số vấn đề về bảo mật và rủi ro tiềm ẩn của công nghệ IBC từ góc độ thiết lập giao thức, triển khai và mở rộng ứng dụng. Kể từ khi việc đề xuất giao thức thường được hoàn thành bởi một số cá nhân và tổ chức, đối với các tổ chức blockchain khác nhau, công việc tập trung vào việc triển khai và mở rộng ứng dụng của giao thức. Do đó, bài viết này sẽ tập trung vào vấn đề bảo mật của các khía cạnh này. Phương pháp này bắt nguồn từ việc xem xét rộng lớn về các rủi ro bảo mật được bao phủ bởi giao thức IBC, giúp phân loại tốt hơn các loại vấn đề bảo mật vào các giai đoạn và mô-đun tương ứng.

Phân tích Lỗ hổng

Xây dựng giao thức IBC

Case Study 1: Giao thức ICS-07, Lỗ hổng logic

Lỗ hổng nền: Sử dụng không đúng chu kỳ Unbinding

Trong mã, có sự xác nhận sau:

nếu currentTimestamp.Sub(consState.Timestamp) >= clientState.UnbondingPeriod

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

Địa chỉ dự án: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client

Vị trí của lỗ hổng:

• https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client#misbehaviour-predicate

• https://github.com/cosmos/cosmos-sdk/blob/6344d626db1fbdba5e0f67425703c1584021bf5b/x/ibc/light-clients/07-tendermint/types/misbehaviour_handle.go#L96

Đoạn mã dễ bị tấn công:

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

Mã

Triển khai Giao thức IBC

Giai đoạn triển khai của giao thức IBC là giai đoạn mà các vấn đề dễ phát sinh, vì nó đóng vai trò cầu nối quan trọng. Nó không chỉ cần tránh sự mơ hồ trong các thông số giao thức mà còn cần cung cấp các giao diện cơ bản và thuận tiện cho việc áp dụng và mở rộng giao thức sau này. Do đó, các vấn đề chính trong giai đoạn triển khai của giao thức IBC có thể được phân loại cụ thể hơn thành:

1. Những sự không rõ ràng và vấn đề không chuẩn trong việc triển khai giao thức.

2. Lỗi trong cài đặt giao thức.

Sự Mơ Hồ và Vấn Đề Không Chuẩn Trong Việc Thực Hiện Giao Thức

Case Study 1: Giao thức ICS-20, Lỗ hổng về Tên

Vulnerability Background: Xung đột địa chỉ giữ tiền. The GetEscrowAddress()Hàm tạo ra một băm SHA256 bị cắt 20 byte (ID Cổng + ID Kênh). Phương pháp này có ba vấn đề:

1. Thiếu sự tách biệt miền giữa cổng và kênh. Phương pháp nối chuỗi không phân tách các miền của cổng và kênh. Ví dụ, các cặp cổng/kênh (“transfer”, “channel”) và (“trans”, “ferchannel”) sẽ dẫn đến cùng một địa chỉ bảo quản, tức là SHA256 bị cắt ngắn (“transferchannel”). Nếu cho phép một số mô-đun cụ thể với các chức năng thư viện chọn ID cổng và kênh, có thể xảy ra các lỗ hổng.

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

3. Xung đột giữa địa chỉ tài khoản mô-đun và không phải mô-đun. Việc xây dựng địa chỉ tài khoản công cộng giống với 20 byte SHA-256 của khóa công cộng Ed25519. Mặc dù 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 bảo mật chống lại các cuộc tấn công sinh nhật chỉ có 80 bit. Tình huống này tương tự như chế độ tấn công sinh nhật bán kỳ, trong đó một địa chỉ được tạo ra bằng SHA-256 nhanh, và địa chỉ khác được tạo ra bằng các tính toán khóa công cộng Ed25519 tương đối chậm. Mặc dù tình huống này an toàn hơn, nhưng vẫn đối mặt với nguy cơ tấn công tiềm ẩn đối với các tài khoản bảo quản và công cộng.

Địa chỉ dự án: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-020-fungible-token-transfer

Vị trí lỗ hổng: https://github.com/cosmos/cosmos-sdk/blob/6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/types/keys.go#L40-L47

https://github.com/cosmos/cosmos-sdk/blob/6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/keeper/relay.go

Mẩu mã dễ bị tấn công:

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

• Trường hợp 1: IBC Security Advisory Dragonberry, lỗ hổng quá trình truyền tải

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

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: thất bại thời gian chờ

Sơ đồ luồng truyền tải gói ứng dụng IBC

Khi hết thời gian chờ xảy ra, đ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 cấu hình. Lỗ hổng Dragonberry bắt nguồn từ ICS-23 (IBC). Nguyên nhân gốc rễ của lỗ hổng này là người dùng có thể giả mạo các bằng chứng không tồn tại trong quá trình xác minh (nghĩa là bằng chứng sai rằng không có gói dữ liệu nào được nhận), 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ờ với 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ể được nhìn thấy trong hình dưới đây.

Sơ đồ nguyên lý lỗ hổng Dragonberry

Địa chỉ dự án: https://github.com/cosmos/ibc-go/tree/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel

Vị trí lỗ hổng: https://github.com/cosmos/ibc-go/blob/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel/keeper/timeout.go#L117C28-L117C54

Mã nguồn dễ bị tấn công:

• Trường hợp 2: IBC Security Advisory Huckleberry, lỗ hổng quá trình truyền tải

Nền tảng Các lỗ hổng: UnreceivedPackets chỉ xây dựng một phản hồi bằng cách tìm giấy nhận gói tương ứng cho mỗi số thứ tự được bao gồm trong truy vấn. Điều này chỉ hoạt động cho các kênh không tuân thứ tự, vì các kênh được sắp xếp sử dụng nextSequenceRecv thay vì giấy nhận gói. Do đó, trên một kênh được sắp xếp, truy vấn số thứ tự thông qua GetPacketReceipt sẽ không tìm thấy giấy nhận trong đó.

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

Sơ đồ luồng nguyên lý lỗ hổng Huckleberry

Địa chỉ dự án: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/

Vị trí lỗ hổng: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/keeper/grpc_query.go#L408

Đoạn mã dễ bị tấn công:

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

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

Nền lỗ hổng: Chức năng TryUpdateAirdropClaimchuyển đổi địa chỉ người gửi của một gói IBC thành một địa chỉ Stride được đặt tên làsenderStrideAddress, và chiết xuất airdropIdvà địa chỉ airdrop mới địachỉnewStridetừ dữ liệu gói tin. Sau đó, nó gọi CậpNhậtĐịaChỉAirdropcập nhậtđịa chỉ senderStridevàClaimRecordVới việc cập nhật của ClaimRecord, địa chỉ newStridesẽ có thể yêu cầu airdrop. Tuy nhiên, chức năng cập nhật này chỉ xác minh xem địa chỉ người gửi của yêu cầu có trống không và không xác thựcđịachỉnewStrideVì IBC cho phép kết nối máy đơn lẻ để triển khai chuỗi hỗ trợ IBC, điều này tạo ra một rủi ro về bảo mật khi có khả năng cập nhật bất kỳ địa chỉ tài khoản khác nào thành địa chỉ nhận airdrop.

Địa chỉ dự án: https://github.com/Stride-Labs/stride/tree/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot

Vị trí lỗ hổng: https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/module_ibc.go#L119

https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/keeper/airdrop.go#L17

Đoạn mã dễ bị tấn công:

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

Lý do của lỗ hổng: Trong ngữ cảnh của hợp đồng thông minh, có một vấn đề với cách phí được xác minh để xác nhận hoặc hết hạn sự kiện IBC (Giao tiếp Giữa các Blockchain). Lỗ hổng này cho phép hợp đồng thông minh độc hại kích hoạt lỗi 'ErrorOutOfGas'. Sự cố này xảy ra trong quá trình xử lý các tin nhắn 'OnAcknowledgementPacket' và 'OnTimeoutPacket'. Khi lỗi này xảy ra, không thể giải quyết thông qua phương pháp 'outOfGasRecovery' thông thường. Kết quả là các giao dịch bị ảnh hưởng sẽ không được bao gồm trong khối blockchain. Sự cố này có thể khiến cho người chuyển tiếp IBC cố gắng lặp đi lặp lại việc gửi các tin nhắn này. Những lần gửi lại có thể dẫn đến mất mát tài chính cho người chuyển tiếp và quá tải mạng lưới với một số lượng không xử lý (‘bị bỏ rơi’) quá nhiều gói tin, đe dọa tính ổn định của mạng.

Địa chỉ dự án: https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/

Vị trí lỗ hổng:

https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/x/interchaintxs/keeper/ibc_handlers.go#L62

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

Tóm tắt

Phân tích và thảo luận về các vấn đề bảo mật liên quan đến giao thức IBC (Inter-Blockchain Communication), như đã được trình bày trong văn bản trước đó, đã làm nổi bật tính phổ biến và đa dạng của những quan ngại này. Những thách thức chính dường như phần lớn xuất phát từ giai đoạn triển khai và sự mở rộng của các ứng dụng sử dụng giao thức IBC. Khi các chuỗi ứng dụng khác nhau ngày càng cải thiện và hoàn thiện các chức năng module truyền thống của họ, họ đồng thời tích hợp các cài đặt mã đa dạng vào các module IBC của họ. Điều này được thực hiện để tăng hiệu suất và phục vụ các yêu cầu kinh doanh cụ thể.

Ngoài các vấn đề bảo mật đã được đề cập trước đó trong thành phần IBC, những thách thức mới đang nổi lên, đặc biệt là trong middleware IBC. Những lo ngại đang tiến triển này được dự kiến sẽ trở nên ngày càng quan trọng trong tương lai, đặc biệt là liên quan đến bảo mật tổng thể của hệ sinh thái Cosmos. Sự thay đổi này cho thấy một sự nhấn mạnh ngày càng tăng về việc đảm bảo các biện pháp bảo mật mạnh mẽ trong module IBC.

Kết luận

Cuộc điều tra của chúng tôi về bảo mật của hệ sinh thái Cosmos, bao gồm các cuộc kiểm tra chi tiết, tóm tắt và phân loại, đã tập trung vào hai thành phần quan trọng nhất của nó: Cosmos SDK và giao thức IBC. Rút ra từ kinh nghiệm thực tiễn phong phú của chúng tôi, chúng tôi đã biên soạn một bộ sưu tập toàn diện về chuyên môn kiểm tra tổng quát.

Báo cáo này nhấn mạnh những thách thức độc đáo do mạng lưới không đồng nhất như Cosmos đặt ra, đặc biệt là với sự hỗ trợ cho các tương tác qua chuỗi. Sự phức tạp và phân tán của các thành phần của nó làm cho nhiệm vụ đảm bảo an ninh của chúng cực kỳ khó khăn. Điều này không chỉ đòi hỏi áp dụng kiến thức hiện tại của chúng ta về các rủi ro an ninh mà còn phải thích nghi với các tình huống an ninh mới để đối phó với các vấn đề mới nổi lên.

Mặc dù có những khó khăn này, chúng tôi rất lạc quan. Bằng cách ghi chép và phân tích các tình huống phổ biến và thách thức về bảo mật, như chúng tôi đã làm trong báo cáo này, chúng tôi đang mở đường cho việc cải thiện dần dần khung bảo mật tổng thể trong hệ sinh thái đa dạng của Cosmos.

Miễn trừ trách nhiệm：

1. Bài viết này được tái bản từ [GateCertiK]. Tất cả bản quyền thuộc về tác giả gốc [CertiK]. If there are objections to this reprint, please contact the Gate Họcnhóm, và họ sẽ xử lý ngay lập tức.
2. Miễn Trách Nhiệm Về Trách Nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không phải là bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.