Hướng dẫn an toàn hệ sinh thái Cosmos: Phân tích các kịch bản bảo mật khác nhau của các thành phần trong hệ sinh thái Cosmos
Tuyển chọn TechFlowTuyển chọn TechFlow
Hướng dẫn an toàn hệ sinh thái Cosmos: Phân tích các kịch bản bảo mật khác nhau của các thành phần trong hệ sinh thái Cosmos
Bài viết này không chỉ bao gồm 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ã nguồn và các yếu tố khác.
Chuyên sâu báo cáo Web3Tác giả: CertiK
Là một trong những hệ sinh thái blockchain lớn nhất và nổi tiếng nhất thế giới, Cosmos tập trung vào việc nâng cao khả năng tương tác giữa các blockchain, nhằm hiện thực hóa sự giao tiếp hiệu quả giữa các chuỗi khác nhau. Một loạt các dự án hàng đầu như Celestia, dYdX v4 đều được xây dựng dựa trên Cosmos SDK và giao thức IBC.
Cùng với việc các thành phần phát triển của Cosmos ngày càng được nhiều nhà phát triển ưa chuộng, các vấn đề an toàn trong hệ sinh thái Cosmos cũng sẽ gây ra ảnh hưởng rộng rãi hơn. Ví dụ, trước đây lỗ hổng Dragonfruit trong Cosmos SDK đã ảnh hưởng đến hoạt động bình thường của nhiều chuỗi công khai hàng đầu. Do tính chất phân tán của các thành phần cơ sở trong hệ sinh thái Cosmos, 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 nhu cầu chức năng cụ thể, dẫn đến việc các vấn đề an toàn trong hệ sinh thái Cosmos cũng mang đặc điểm phân tán và đa dạng. Vì vậy, một tài liệu nghiên cứu giúp các nhà phát triển hiểu rõ cấu trúc tình hình an toàn và các giải pháp xử lý trong hệ sinh thái Cosmos là vô cùng cần thiết.
Hướng dẫn An toàn Hệ sinh thái Cosmos do đội ngũ CertiK độc quyền phát hành đã phân tích chi tiết các kịch bản an toàn của từng thành phần khác nhau trong hệ sinh thái Cosmos theo cách 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 phân tích về các lỗ hổng an toàn nghiêm trọng trước đây trong hệ sinh thái Cosmos, mà còn phân loại các lỗ hổng an toàn phổ biến theo nguyên nhân, hậu quả, vị trí mã nguồn,... nhằm cung cấp tối đa hướng dẫn an toàn cho các nhà phát triển hệ sinh thái Cosmos, đồng thời cung cấp tài liệu tra cứu học tập và kiểm toán an toàn cho các chuyên viên kiểm toán an ninh.
Trong suốt thời gian qua, đội ngũ CertiK luôn hỗ trợ cải thiện an toàn cho hệ sinh thái Cosmos và toàn bộ hệ sinh thái Web3 thông qua nghiên cứu và khai thác liên tục. Chúng tôi sẽ định kỳ cập nhật các báo cáo an toàn dự án và nghiên cứu kỹ thuật, mời bạn theo dõi! Nếu có bất kỳ câu hỏi nào, vui lòng liên hệ với chúng tôi bất cứ lúc nào.
Dưới đây là toàn văn "Hướng dẫn An toàn Hệ sinh thái Cosmos"👇.
Tổng quan
Cosmos là mộtmạng lưới liên chuỗi blockchain mã nguồn mở, mở rộng cao, đồng thời cũng là một trong những hệ sinh thái blockchain nổi tiếng nhất toàn cầu. Cosmos là một mạng lưới dị hợp (heterogeneous) hỗ trợ giao tiếp liên chuỗi được ra mắt bởi CometBFT (trước đây là nhóm Tendermint), bao gồm nhiều chuỗi riêng biệt chạy song song tạo thành một mạng lưới phi tập trung, với tầm nhìn phá vỡ hiệu ứng “đảo thông tin”, hiện thực hóa khả năng tương tác giữa các blockchain khác nhau. Trong kỷ nguyên đa chuỗi hiện nay, việc đạt được giao tiếp liên chuỗi đã trở thành nhu cầu cấp thiết của ngành công nghiệp blockchain.
Cosmos cung cấp một mô hình liên chuỗi hiệu quả, đặc biệt phù hợp với các chuỗi công cộng tập trung vào lĩnh vực chuyên biệt. Bằng cách cung cấp cơ sở hạ tầng blockchain mô-đun, Cosmos mang lại tiện lợi cho các nhà phát triển ứng dụng, cho phép họ lựa chọn và sử dụng chuỗi công cộng phù hợp với nhu cầu của mình.
Các ứng dụng và giao thức trong hệ sinh thái Cosmos sử dụng IBC (giao thức Giao tiếp giữa các Blockchain) để kết nối, từ đó thực hiện giao dịch liên chuỗi giữa các blockchain độc lập, cho phép tài sản và dữ liệu lưu thông tự do. Tầm nhìn của Cosmos là xây dựng một “Internet blockchain”, cung cấp khả năng mở rộng và tương tác cho một lượng lớn blockchain tự chủ và dễ phát triển.
Trong thời gian dài, CertiK luôn dành sự quan tâm và nghiên cứu sâu sắc đối với môi trường hệ sinh thái Cosmos. Chúng tôi đã tích lũy được kinh nghiệm phong phú về các vấn đề an toàn trong hệ sinh thái Cosmos. Trong báo cáo nghiên cứu này, chúng tôi sẽ giới thiệu những khám phá và kết quả nghiên cứu của mình về an toàn hệ sinh thái Cosmos, tập trung chủ yếu vào bốn phương diện: an toàn Cosmos SDK, an toàn giao thức IBC, an toàn CometBFT và an toàn 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 các chuỗi cơ sở hoặc chuỗi ứng dụng, trình bày tuần tự từ dưới lên trên các điểm then chốt về an toàn liên quan đến bản thân chuỗi trong hệ sinh thái Cosmos thông qua phân tích và mở rộng các vấn đề tương tự.
Do tính phức tạp và đa dạng của hệ sinh thái Cosmos, các vấn đề an toàn tồn tại cũng mang tính đa dạng. Vì vậy, báo cáo nghiên cứu này không bao gồm tất cả các loại lỗ hổng an toàn, mà chỉ thảo luận các lỗ hổng điển hình và có mức độ nguy hại lớn hơn đối với các chuỗi trong hệ sinh thái Cosmos. Nếu muốn tìm hiểu thêm chi tiết về các vấn đề an toàn khác, vui lòng liên hệ với các kỹ sư an toàn CertiK để trao đổi.
Bối cảnh
-
CometBFT: Nền tảng cho khả năng mở rộng liên chuỗi
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: động cơ đồng thuận nền tảng (CometBFT Core) và giao diện khối ứng dụng phổ quát (ABCI). Thuật toán đồng thuận của nó kết hợp PBFT+Bonded PoS, đảm bảo các nút ghi lại giao dịch một cách đồng bộ. Là một thành phần cốt lõi của khả năng mở rộng Interchain, CometBFT duy trì tính an toàn, phi tập trung và toàn vẹn của hệ sinh thái Interchain thông qua sự đồng thuận của các trình xác thực.
-
Cosmos SDK: Tính mô-đun và chức năng mới
Cosmos SDK là một bộ công cụ giúp các nhà phát triển đẩy nhanh tiến độ phát triển, cung cấp các đặc tính mô-đun và có thể tháo lắp, cho phép các nhà phát triển xây dựng blockchain hoặc thành phần chức năng riêng dựa trên thuật toán đồng thuận CometBFT, từ đó đơn giản hóa quá trình phát triển và rút ngắn chu kỳ phát triển. Hiện nay, nó đã được áp dụng trong nhiều dự án blockchain như Cronos, Kava và dYdX V4 vừa ra mắt gần đây. 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 chức năng mới, cho phép các nhà phát triển tạo ra các ứng dụng phức tạp và mô-đun hóa hơn, nuôi dưỡng một hệ sinh thái rộng lớn và mạnh mẽ hơn.
-
Giao thức IBC: Tăng cường tính tương tác và khả năng mở rộng
Giao thức IBC (giao thức Giao tiếp giữa các Blockchain) cho phép truyền dữ liệu an toàn, phi tập trung và không cần giấy phép giữa các blockchain. Vì Cosmos là một mạng lưới phi tập trung gồm nhiều chuỗi độc lập chạy song song và sử dụng công nghệ relay để thực hiện liên kết liên chuỗi, nên IBC có thể nói là phần cốt lõi nhất 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à tính sẵn có. Bằng cách nâng cao khả năng mở rộng và tính tương tác của IBC, Cosmos sẽ tiếp tục tăng dung lượng hệ sinh thái, từ đó hiện thực hóa sự tương tác liền mạch giữa các blockchain, ứng dụng và hợp đồng thông minh.
-
CosmWasm: Mở khóa việc triển khai phi tập trung, không cần giấy phép
CosmWasm (Cosmos WebAssembly) là một khuôn khổ hợp đồng thông minh dựa trên WebAssembly, được thiết kế 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 giấy phép, đồng thời cho phép các nhà phát triển blockchain tách biệt chu kỳ phát triển sản phẩm khỏi chu kỳ phát triển blockchain, từ đó giảm chi phí nâng cấp trình xác thực. Ngoài ra, nó còn có các đặc điểm như kiến trúc mô-đun, tích hợp Cosmos SDK, giao tiếp liên chuỗi, v.v.
Tính đến thời điểm hiện tại, Cosmos SDK và giao thức IBC tương đối trưởng thành và được sử dụng rộng rãi nhất trong hệ sinh thái Cosmos hiện nay.
Xét từ góc độ của nhà phát triển chuỗi, phần lớn các chức năng tùy chỉnh mà các chuỗi trong hệ sinh thái Cosmos cần hiện nay đều có thể thực hiện được nhờ Cosmos SDK. Để thực hiện các thao tác đặc biệt trong quá trình vận hành liên chuỗi hoặc nhằm mục đích tối ưu hiệu suất, các nhà phát triển chuỗi sẽ tùy chỉnh từng mô-đun IBC của riêng họ. Ngoài ra, cũng có một số ít chuỗi sẽ tùy chỉnh các động cơ nền tảng như CometBFT Core. Do giới hạn về độ dài, phần này tạm thời không được mở rộng trong báo cáo nghiên cứu này. Báo cáo này sẽ tập trung phân tích các điểm kỹ thuật và các vấn đề an toàn của hai thành phần Cosmos SDK và giao thức IBC.
Hướng dẫn An toàn Cosmos SDK
Cosmos SDK là một framework mạnh mẽ và linh hoạt dùng để xây dựng các ứng dụng blockchain và giao thức phi tập trung. Được phát triển bởi Quỹ Interchain, 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 nhiều blockchain liên kết với nhau.
Cosmos SDK nhằm đơn giản hóa việc phát triển các ứng dụng blockchain tùy chỉnh và hiện thực hóa khả năng tương tác liền mạch giữa các blockchain khác nhau. Các đặc điểm chính của Cosmos SDK bao gồm: 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 với IBC, thân thiện với nhà phát triển. Cosmos SDK tận dụng động cơ đồng thuận nền tảng CometBFT Core để đảm bảo an toàn mạnh mẽ, bảo vệ mạng khỏi các cuộc tấn công độc hại, từ đó bảo vệ tài sản và dữ liệu của người dùng. Ngoài ra, tính mô-đun cho phép người dùng dễ dàng thiết kế các mô-đun tùy chỉnh. Mặc dù có những lợi thế này, nhưng khi các nhà phát triển sử dụng Cosmos SDK để triển khai ứng dụng của riêng mình, vẫn có thể tồn tại các lỗ hổng an toàn.
Xét về mặt kiểm toán an toàn, chúng ta cần xem xét đầy đủ mục tiêu kiểm toán, cân nhắc đầy đủ các mối nguy hiểm tiềm tàng ở mọi góc độ. Tuy nhiên, từ góc độ nghiên cứu an toàn, chúng ta cần tập trung hơn vào các lỗ hổng an toàn có tác động lớn, nhằm tránh tối đa các rủi ro an toàn trong thời gian ngắn nhất và cung cấp hỗ trợ hiệu quả hơn cho các bên tích hợp dịch vụ. Từ góc độ này, việc phân loại các lỗ hổng nguy hiểm cao, phạm vi ảnh hưởng lớn và phân tích mô hình lỗ hổng của chúng là điều hết sức cần thiết và có giá trị.
Trong giao diện ABCI xuyên suốt 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, DeliverTx. Hai giao diện đầu tiên liên quan trực tiếp đến logic thực thi của từng khối, trong khi hai giao diện sau liên quan đến xử lý cụ thể của sdk.Msg (cấu trúc dữ liệu cơ bản cho việc truyền tin nhắn trong hệ sinh thái Cosmos).
Vì logic triển khai của các chuỗi ứng dụng khác nhau trong hệ sinh thái Cosmos đều có thể tuân theo các mô-đun và mẫu tương tự trong Cosmos SDK, nên khi phân tích và hiểu các lỗ hổng an toàn dưới đây, cần có khái niệm cơ bản về quy trình vận hành mô-đun của Cosmos SDK.
Trong hệ sinh thái Cosmos, giao dịch ban đầu được tạo trong đại lý người dùng, sau đó được ký và phát sóng đến các nút trong blockchain. Các nút sử dụng phương pháp 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, thứ tự giao dịch và lượng gas cung cấp, v.v. Nếu giao dịch vượt qua xác minh, nó sẽ được đưa vào bộ nhớ đệm (mempool), chờ được đưa vào một khối. Ngược lại, nếu giao dịch không vượt qua 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, giao dịch sẽ được kiểm tra thêm, quá trình này được hoàn thành bằng phương pháp DeliverTx để đảm bảo tính nhất quán và tính tất định.
Trong Cosmos SDK, vòng đời của một giao dịch có thể được mô tả ngắn gọn như sau:
1. Tạo giao dịch: Giao dịch được tạo ở phía client bằng các công cụ, CLI hoặc trên giao diện người dùng.
2. Thêm vào bộ nhớ đệm: Giao dịch được thêm vào mempool, nơi nút gửi một thông điệp 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 đó gọi ValidateBasic() trên mỗi sdk.Msg của Tx để thực hiện kiểm tra tính hợp lệ sơ bộ không trạng thái. Nếu ứng dụng có anteHandler tương ứng, trước tiên sẽ thực thi logic nội bộ của nó, sau đó gọi hàm runTx, cuối cùng gọi đến 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 mempool cục bộ như một ứng cử viên cho khối tiếp theo và sẽ được phát sóng P2P đến các nút peer.
3. Được đưa vào khối đề xuất: Ở đầu mỗi vòng, người đề xuất tạo một khối chứa các giao dịch mới nhất, cuối cùng được các trình xác thực nút đầy đủ chịu trách nhiệm về đồng thuận, đồng ý chấp nhận khối đó hoặc bỏ phiếu cho một khối trố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ế độ Deliver và thực hiện 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 đó, các kiểm tra được thực hiện sau khi thực thi tin nhắn; nếu có bất kỳ thất bại nào, trạng thái sẽ được hoàn nguyên. Trong quá trình thực thi, bộ đo gas được sử dụng để theo dõi lượng gas đã sử dụng. Nếu xảy ra bất kỳ lỗi gas nào (ví dụ: gas không đủ), hậu quả sẽ giống như việc thực thi thất bại, các thay đổi trạng thái sẽ được hoàn nguyên.
5. Xác nhận khối: Khi nút nhận được đủ phiếu bầu từ các trình xác thực, nó sẽ xác nhận một khối mới để thêm vào blockchain và cuối cùng là xác nhận chuyển đổi trạng thái ở lớp ứng dụng.
Sơ đồ vòng đời giao dịch trong hệ sinh thái Cosmos
Dưới đây là logic thực thi cụ thể của Cosmos SDK, có thể tham khảo để hiểu rõ hơn khi phân tích đường dẫn kích hoạt lỗ hổng ở phần sau:
Logic thực thi cụ thể của ABCI trọng điểm trong Cosmos SDK
Phân loại lỗ hổng phổ biến
Trước khi tìm hiểu về phân loại lỗ hổng, chúng ta cần có sự phân chia cơ bản về mức độ nguy hiểm của lỗ hổng, điều này giúp nhận diện tốt hơn các lỗ hổng an toàn có mức độ nguy hiểm cao và cố gắng tránh các rủi ro an toàn tiềm tàng.
Xét về 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 an toàn được đánh giá là Critical và Major, chúng thường có thể gây ra các rủi ro sau:
1. Chuỗi ngừng hoạt động
2. Mất tài sả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 gây ra các mối nguy hiểm này thường là các loại lỗ hổng an toàn sau:
1. Từ chối dịch vụ
2. Thiết lập trạng thái sai
3. Thiếu hoặc kiểm tra không hợp lý
4. Vấn đề về tính duy nhất
5. Vấn đề về thuật toán đồng thuận
6. Lỗi logic trong triển khai
7. Vấn đề về đặc tính ngôn ngữ
Phân tích lỗ hổng
Do tính chất mô-đun đặc biệt của hệ sinh thái Cosmos, các chuỗi khác nhau có rất nhiều ví dụ về việc sử dụng lẫn nhau giữa các mô-đun và gọi hàm lồng nhau trong mô-đun, do đó có thể xảy ra tình huống đường dẫn kích hoạt lỗ hổng không nhất quán với đường dẫn kiểm soát biến quan trọng của lỗ hổng. Khi phân tích nguyên nhân cụ thể gây ra lỗ hổng, chúng ta không nên chỉ chú ý đến đường dẫn kích hoạt, mà còn phải chú ý đến đường dẫn kiểm soát biến quan trọng của lỗ hổng, điều này mới giúp chúng ta phân loại và định nghĩa mô hình lỗ hổng một cách tốt hơn.
Chuỗi ngừng hoạt động
Thủ phạm chính khiến chuỗi ngừng hoạt động thường là các vấn đề phát sinh trong quá trình thực thi khối đơn lẻ, nhưng trong lịch sử phát triển của Cosmos cũng từng xuất hiện các lỗ hổng an toàn đồng thuận buộc chuỗi phải chủ động dừng lại để sửa chữa. Vì vậy, ở đây chúng tôi cũng đưa các lỗ hổng an toàn ảnh hưởng đến đồng thuận vào phần thảo luận về hiệu ứng ngừng hoạt động của chuỗi. Chúng tôi sẽ lần lượt trình bày hai loại vấn đề này.
Loại đầu tiên thường thấy là các lỗ hổng từ chối dịch vụ, nguyên nhân cụ thể chủ yếu là xử lý sập máy không đúng cách và các thao tác lặp có biên giới bị người dùng ảnh hưởng. Những lỗ hổng này thường khiến chuỗi tạm dừng hoạt động hoặc làm chậm tốc độ chạy.
Như đã đề cập ở phần trước, Cosmos SDK và CometBFT là cơ sở hạ tầng then chốt trong hệ sinh thái Cosmos, chúng không chỉ được các chuỗi cơ sở trong Cosmos sử dụng mà các chuỗi ứng dụng khác cũng dựa trên kiến trúc này để triển khai logic riêng của mình. Do đó, chúng đều tuân theo quy tắc giao diện ABCI của CometBFT, diện tấn công trọng điểm cũng nằm ở giao diện ABCI của nó. Các lỗ hổng an toàn có thể gây ra Chain halt (dừng chuỗi) chủ yế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 xảy ra của chúng hầu như đều có thể truy ngược về hai giao diện BeginBlock và EndBlock.
Loại thứ hai thuộc về các lỗ hổng ảnh hưởng đến đồng thuận, thường liên quan đến việc triển khai của các chuỗi khác nhau, hiện nay đã biết là phổ biến ở một số xử lý logic xác minh, hiệu chuẩn thời gian và vấn đề ngẫu nhiên. Về bản chất, các lỗ hổng này ảnh hưởng đến nguyên tắc phi tập trung của blockchain. Nhìn bề ngoài có thể không thấy ảnh hưởng lớn, nhưng nếu bị kẻ xấu cố ý thiết kế thì vẫn có thể tạo ra rủi ro an toàn đáng kể.
Loại đầu tiên
-
Ví dụ một: Dự án SuperNova
Bối cảnh lỗ hổng: Thiếu xác minh địa chỉ trong thao tác phát hành tiền, dẫn đến thất bại thao tác và mất tiền. Trong mô-đun minting, mỗi lần tạo token đều phụ thuộc vào số tiền đặt cược. Tuy nhiên, nếu pool không tồn tại hoặc địa chỉ hợp đồng nhập sai, mô-đun minting có thể gặp tình huống bất ngờ, dẫn đến chuỗi ngừng hoạt động. Trong mô-đun reward pool, địa chỉ hợp đồng pool chưa được xác minh. Nếu thao tác phân phối thất bại, chuỗi sẽ ngừng hoạt động trực tiếp.
Vị trí lỗ hổng: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/mint/keeper/keeper.go#L175
Đoạn mã lỗ hổ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
Bản vá nằm trong mô-đun xử lý tin nhắn của poolincentive (x/poolincentive/types/msgs.go), chứ không phải mô-đun mint.
Thêm xác minh địa chỉ khi xử lý tin nhắn MsgCreateCandidatePool (tức là tạo pool), nhằm loại trừ khả năng địa chỉ sai ngay từ gốc rễ.
-
Ví dụ hai: Dự án Cosmos Interchain Security
Địa chỉ dự án: https://github.com/cosmos/interchain-security
Bối cảnh lỗ hổng: Các trình xác thực có thể làm chậm tốc độ chuỗi cung cấp bằng cách gửi nhiều tin nhắn AssignConsumerKey trong cùng một khối. Hàm AssignConsumerKey được định nghĩa trong x/ccv/provider/keeper/key_assignment.go cho phép các trình xác thực gán consumerKey khác nhau cho các chuỗi tiêu dùng đã được phê duyệt. Để thực hiện điều này, danh sách AddressList consumerAddrsToPrune sẽ tăng thêm một phần tử. Vì trong EndBlocker của x/ccv/provider/keeper/relay.go sẽ lặp qua AddressList này, kẻ tấn công có thể lợi dụng điều này để làm chậm tốc độ chuỗi cung cấp. Để thực hiện cuộc tấn công này, kẻ xấu có thể tạo giao dịch chứa nhiều tin nhắn AssignConsumerKey và gửi các giao dịch này đến chuỗi cung cấp. Số lượng phần tử trong consumerAddrsToPrune AddressList sẽ bằng với số lượng tin nhắn 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, dẫn đến tốc độ chạy của chuỗi cung cấp chậm lại, thậm chí ngừng hoạt động.
Vị trí lỗ hổng: https://github.com/cosmos/interchain-security/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/provider/keeper/key_assignment.go#L378
Đoạn mã lỗ hổng:
Đường dẫn kích hoạt lỗ hổng:
msgServer.AssignConsumerKey
Keeper.AssignConsumerKey
AppModule.EndBlock
EndBlockCIS
HandleLeadingVSCMaturedPackets
HandleVSCMaturedPacket
PruneKeyAssignments
-
Ví dụ ba: Dự án Quicksilver - Mô-đun Airdrop
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 mình. Chúng được kích hoạt lần lượt ở đầu và cuối mỗi khối. Việc sử dụng crash để xử lý lỗi trong các phương pháp BeginBlock và EndBlock có thể khiến chuỗi dừng hoạt động khi xảy ra lỗi. EndBlocker khi thanh lý airdrop chưa hoàn thành không xem xét mô-đun có đủ token hay không, có thể kích hoạt khả năng crash, dẫn đến chuỗi ngừng hoạt động.
Vị trí lỗ hổng: https://github.com/quicksilver-zone/quicksilver/blob/b4aefa899e024d60f4047e2f2f403d67701b030e/x/airdrop/keeper/abci.go#L15
Đoạn mã lỗ hổng:
Đường dẫn kích hoạt lỗ hổng:
AppModule.EndBlock
Keeper.EndBlocker
Keeper.EndZoneDrop
Bản vá lỗ hổng: https://github.com/quicksilver-zone/quicksilver/blob/20dc658480b1af1cb323b4ab4a8e5925ee79a0ed/x/airdrop/keeper/abci.go#L16
Loại bỏ trực tiếp mã xử lý panic, thay bằng ghi log lỗi.
-
Ví dụ bốn: Dự án Cosmos Interchain Security
Địa chỉ dự án: https://github.com/cosmos/interchain-security
Bối cảnh lỗ hổng: Kẻ tấn công có thể thực hiện tấn công từ chối dịch vụ bằng cách gửi nhiều token đến địa chỉ thưởng của chuỗi cung cấp.
Trong quy trình thực thi EndBlocker của chuỗi tiêu dùng, hàm SendRewardsToProvider được định nghĩa trong x/ccv/consumer/keeper/distribution.go lấy số dư của tất cả token trong tstProviderAddr và gửi chúng đến chuỗi cung cấp. Để thực hiện điều này, nó phải lặp qua tất cả các token được tìm thấy trong địa chỉ thưởng và gửi từng cái một đến chuỗi cung cấp thông qua IBC. Vì bất kỳ ai cũng có thể gửi token đến địa chỉ thưởng, kẻ tấn công có thể tạo và gửi một lượng lớn token với denom khác nhau, ví dụ như sử dụng chuỗi có mô-đun factory token, để phát động 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, dẫn đến tốc độ chạy của chuỗi tiêu dùng chậm lại, thậm chí ngừng hoạt động.
Vị trí lỗ hổng: https://github.com/cosmos/interchain-security/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/consumer/keeper/distribution.go#L103
Đoạn mã lỗ hổng:
Đường dẫn kích hoạt lỗ hổng:
AppModule.EndBlock
EndBlock
EndBlockRD
SendRewardsToProvider
Loại thứ hai
Loại vấn đề đồng thuận này có thể không gây ra tác hại trực tiếp nghiêm trọng, nhưng xét về nguyên tắc bản chất và hệ thống tổng thể của blockchain, hoặc xét từ các tình huống cụ thể, ảnh hưởng và tác hại mà chúng gây ra không hề nhỏ hơn các lỗ hổng thông thường khác. Ngoài ra, các lỗ hổng này cũng có điểm chung.
-
Ví dụ một
Bối cảnh lỗ hổng: Cảnh báo an toàn Cosmos SDK Jackfruit
Hành vi không tất định trong phương pháp ValidateBasic của mô-đun x/authz trong Cosmos SDK dễ dẫn đến việc ngừng đồng thuận. Cấu trúc tin nhắn MsgGrant của mô-đun x/authz bao gồm một trường Grant, bao gồm thời gian hết hạn được cấp bởi ủy quyền do người dùng định nghĩa. Trong xử lý xác thực ValidateBasic() của cấu trúc Grant, 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ì thời gian cục bộ là không tất định, dấu thời gian của các nút khác nhau có thể khác nhau, do đó gây ra vấn đề đồng thuận.
Thông báo lỗ hổng:
https://forum.cosmos.network/t/cosmos-sdk-security-advisory-jackfruit/5319
https://forum.cosmos.network/t/cosmos-sdk-vulnerability-retrospective-security-advisory-jackfruit-october-12-2021/5349
https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-2p6r-37p9-89p2
Đoạn mã lỗ hổng:
Bản vá lỗ hổng:
https://github.com/cosmos/cosmos-sdk/compare/v0.44.1...v0.44.2
Các vấn đề liên quan đến dấu thời gian như vậy không chỉ xuất hiện trong các thành phần cơ sở như Cosmos SDK, mà cũng từng xuất hiện trong các chuỗi ứng dụng.
-
Ví dụ hai
Bối cảnh lỗ hổng: SuperNova, dự án nova
Địa chỉ dự án: https://github.com/Carina-labs/nova/tree/v0.6.3
Sử dụng time.Now() để trả về dấu thời gian của hệ điều hành. Thời gian cục bộ là chủ quan, do đó là không tất định. Vì dấu thời gian của các nút khác nhau có thể có sự chênh lệch nhỏ, chuỗi có thể không đạt được đồng thuận. Trong mô-đun ICAControl, hàm gửi giao dịch sử dụng time.Now() để lấy dấu thời gian.
Vị trí lỗ hổng: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/icacontrol/keeper/send_msgs.go#L14
Đoạn mã lỗ hổng:
Bản vá lỗ hổng:
Thay việc sử dụng dấu thời gian cục bộ bằng dấu 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))
-
Ví dụ ba
Bối cảnh lỗ hổng: Mô-đun oracles của dự án BandChain
Địa chỉ dự án: https://github.com/bandprotocol/bandchain/
Ghi chú trong kho mã cho thấy mô-đun oracle phải được thực hiện trước staking để thực hiện biện pháp trừng phạt những người vi phạm giao thức oracle
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
CertiK
