作爲全球最大，最爲知名的區塊鏈生態之一，Cosmos 專註於提升區塊鏈互操作性，實現不衕區塊鏈之間的高效互通。包括 Celestia、dYdX v4 在內的一繫列頭部項目都基於 Cosmos SDK 和 IBC 協議進行搭建。
隨著 Cosmos 開髮組件受到更多開髮者青睞，Cosmos 生態的安全問題也勢必會帶來更廣泛的影響。例如，此前 Cosmos SDK 的 Dragonfruit 漏洞就影響了多個主流公鏈的正常運行。由於 Cosmos 生態繫統基礎組件的分散性，開髮者需要根據不衕的功能需求使用或者擴展不衕的組件，導緻 Cosmos 生態中的安全問題也存在分散、多樣的特點。一份幫助開髮者結構性了解 Cosmos 生態安全現狀與應對方案的研究，也就顯得十分必要。
CertiK 團隊獨家髮布的《Cosmos 生態安全指南》通過讀者友好的分類細緻剖析了 Cosmos 生態不衕組件的安全場景。此報告不僅包括 Cosmos 生態以往重大安全漏洞的分析，還將一些常見的安全漏洞根據起因，效果，代碼位置等分類，最大程度地爲 Cosmos 生態開髮者提供安全指引，併爲安全審計人員提供學習和審計 Cosmos 安全問題的索引資料。
一直以來，CertiK 團隊都在通過持續的研究和挖掘，協助提升 Cosmos 與整個 Web3 的生態安全。我們將定期爲大家帶來各類項目安全報告和技術研究，歡迎持續關註！如有任何疑問，可隨時與我們取得聯繫。
以下是《Cosmos 生態安全指南》全文👇。
概況
Cosmos 是一款開源、開放、高度可擴展的區塊鏈跨鏈網絡，也是全球最爲知名的區塊鏈生態之一。Cosmos 是一個由 CometBFT（原 Tendermint 團隊）推出的支持跨鏈交互的異構網絡，由多條獨立、併行的區塊鏈組成去中心化網絡，其願景是打破信息的孤島效應，實現不衕區塊鏈之間的互操作性。在當前多鏈時代，實現跨鏈交互已經成爲區塊鏈行業的迫切需求。
Cosmos 提供了一種高效的跨鏈模式，特別適用於專註特定垂直領域的公鏈。通過提供模塊化的區塊鏈基礎設施，Cosmos 爲各應用開髮者提供了便利，使其能夠選擇併使用符合其需求的公鏈。
Cosmos 生態繫統中的應用程序和協議採用IBC（區塊鏈間通信協議）進行連接，實現了各個獨立區塊鏈之間的跨鏈交互，使資産和數據能夠自由流通。Cosmos 的願景是建立一個區塊鏈互聯網，爲大量自主、易於開髮的區塊鏈提供擴展和交互的可能性。
長期以來，CertiK 對 Cosmos 生態環境保持了充分的關註和研究。我們在 Cosmos 生態安全問題上積纍了充足的經驗，在本研究報告中，將介紹我們對 Cosmos 生態繫統安全的探索和研究成果，主要將重點集中在 Cosmos SDK 安全、IBC 協議安全、CometBFT 安全和 CosmWasm 安全四個方曏，討論的對象目標會從 Cosmos 基礎組件延伸到 Cosmos 基礎鏈或應用鏈，通過對類似問題的分析和擴展，以自下而上的方式曏讀者展現 Cosmos 生態中關於鏈自身涉及到的安全要點。
由於 Cosmos 生態的覆雜多樣性，存在的安全問題也具備多樣性的特徵，因此這份研究報告併沒有將所有的安全漏洞類型都涵蓋其中，僅探討更具有典型特徵且對 Cosmos 生態鏈存在更大危害性的漏洞。如果想要了解更多關於其他安全問題的詳情，歡迎聯繫 CertiK 安全工程師交流探討。
背景
- CometBFT：跨鏈可擴展性的基石
CometBFT 是一項創新的共識算法，包括底層共識引擎（CometBFT Core）和通用應用程序區塊鏈接口（ABCI）兩個主要組件。其共識算法採用了 PBFT+Bonded PoS 混合共識，確保節點衕步記録交易。作爲 Interchain 可擴展性的核心組成部分，CometBFT 通過驗證者共識，維護 Interchain 生態繫統的安全性、去中心化和完整性。
- Cosmos SDK：模塊化和新功能
Cosmos SDK 是一個幫助開髮者加速開髮進程的工具包，提供了模塊化和可插拔的特性，利用 Cosmos SDK，開髮者可以基於 CometBFT 共識算法構建自己的區塊鏈或功能組件，實現便捷開髮併縮短開髮周期。目前已在許多區塊鏈項目中得到採用，如 Cronos、Kava 和最近推出的 dYdX V4。未來的髮展計畫將專註於模塊化和引入新功能，使開髮人員能夠創建更覆雜、模塊化的應用程序，培育更廣泛、更強大的生態繫統。
- IBC 協議：增強互操作性和可擴展性
IBC 協議（區塊鏈間通信協議）能夠在區塊鏈之間實現安全、去中心化且無需許可的數據傳輸。由於 Cosmos 是由多條獨立併行的區塊鏈組成的去中心化網絡且利用中繼技術實現不衕區塊鏈之間的跨鏈，因此 IBC 可以説是整個項目最核心的部分。Interchain 基金會目前重點關註兩個主題：可擴展性和可用性。通過提高 IBC 的可擴展性和互操作性，Cosmos 將進一步增強其生態繫統的容量，從而實現區塊鏈、應用程序和智能合約之間的無縫交互。
- CosmWasm：解鎖去中心化、無許可部署
CosmWasm（Cosmos WebAssembly）是一個基於 WebAssembly 的智能合約框架，專爲 Cosmos 生態繫統設計。它使開髮人員能夠在沒有許可要求的情況下部署去中心化應用程序，衕時還允許區塊鏈開髮人員將其産品開髮周期與區塊鏈開髮分開，從而降低驗證器升級的成本。除此之外它還具有模塊化架構，Cosmos SDK 集成，跨鏈通信等特性。
截止目前，Cosmos SDK，IBC 協議相對成熟，且在目前的 Cosmos 生態繫統中使用最爲廣泛。
從鏈開髮者的角度考慮，目前 Cosmos 上的生態鏈所需要大部分自定義化的功能都可以依賴 Cosmos SDK 來完成，而爲了實現跨鏈操作過程中一些特殊操作或是出於優化性能等目的，鏈開髮者會對各自 IBC 模塊實現定製化，除此之外，也有少部分的鏈會對 CometBFT Core 等底層引擎做修改定製化，因篇幅限製暫時不在本研究報告中展開，本研究報告將重點剖析 Cosmos SDK 和 IBC 協議這兩者的技術要點和安全問題。
Cosmos SDK 安全指南
Cosmos SDK 是一個強大而靈活的框架，用於構建區塊鏈應用程序和去中心化協議。它由 Interchain 基金會開髮，是 Cosmos 網絡的核心組件，Cosmos 網絡是互連區塊鏈的去中心化網絡。
Cosmos SDK 旨在簡化自定義區塊鏈應用程序的開髮，併實現不衕區塊鏈之間的無縫互操作性。Cosmos SDK 主要有以下特點：模塊化架構、可定製性、基於 CometBFT、實現 IBC 對應接口、開髮者友好。Cosmos SDK 通過利用 CometBFT Core 底層共識引擎確保強大的安全性，保護網絡免受惡意攻擊，爲用戶的資産和數據提供保護。此外，其模塊化性使用戶能夠輕鬆設計定製模塊。盡管有這些優點，但當開髮人員使用 Cosmos SDK 實現自己的應用程序時，仍然可能存在安全漏洞。
從安全審計角度來講，我們需要對審計目標做到麵麵俱到，充分考慮到各個角度的安全隱患問題，但從安全研究角度來講，我們更需要去關註能夠造成重大影響的安全漏洞，在更短的時間內盡可能的避免最大安全隱患，爲集成服務方提供更有效的幫助。從這個角度考慮，對一些危險程度高、影響範圍大的漏洞做出分類，併分析出其漏洞模型是非常必要且有價值的事情。
在貫穿整個 Cosmos 生態的 ABCI 接口中，我們重點關註 BeginBlock、EndBlock、CheckTx、DeliverTx 這四個接口，前兩者直接涉及到單個區塊的執行邏輯，而後兩者涉及到對 sdk.Msg(Cosmos 生態中傳輸消息的基礎數據結構 ) 的具體處理。
由於 Cosmos 生態上各種應用鏈的實現邏輯都可按照類似 Cosmos SDK 裡的模塊和樣例，因此在分析理解下文的安全漏洞時，需要對 Cosmos SDK 的模塊運行流程有個基本概念。
在 Cosmos 生態裡，交易最初在用戶代理中被創建，然後會被簽名併廣播到區塊鏈內的節點。節點利用 CheckTx 方法來驗證各種交易細節，如簽名、髮件人的餘額、交易序列和提供的燃料等。如果交易通過驗證，它將被添加到內存池，等待被包含在一個區塊中。另外，如果交易未通過驗證，將曏用戶髮送錯誤消息，導緻交易被拒絶。在區塊執行期間，會對交易進行進一步檢查，這是通過 DeliverTx 方法完成的，以確保一緻性和確定性。
在 Cosmos SDK 中，交易的生命周期可以簡要描述爲如下流程：
1.交易創建：交易是在客戶端使用各種工具、CLI 或在前端創建的。
2.添加到內存池：交易被添加到內存池，其中節點髮送一個 ABCI 消息 -CheckTx 到應用層，以檢查有效性併接收結果 abci.ResponseCheckTx。在 CheckTx 中，交易從字節格式解碼爲 Tx 格式，然後在 Tx 的每個 sdk.Msg 上調用 ValidateBasic() 進行初步的無狀態有效性檢查。如果應用程序存在對應的 anteHandler，則會先執行它的內部邏輯，然後調用 runTx 函數，最終會調用到 RunMsgs() 函數來處理 sdk.Msg 的具體內容。如果 CheckTx 成功，消息將添加至本地內存池作爲下一個區塊的候選，併將通過 P2P 廣播到對等 Peer 節點。
包含在一個提議區塊中：每一輪開始時，提議者創建一個包含最新交易的區塊，最後由全節點負責共識的驗證者，衕意接受該區塊或者投票一個空區塊。
狀態更改：DeliverTx 被調用來迭代區塊中的交易，類似於 CheckTx，但它在 Deliver 模式下調用 runTx，併執行狀態的變更。MsgServiceRouter 被調用來路由交易中的不衕消息到不衕的模塊，然後執行 Msg Server 中的每個相應消息。之後，在執行消息後運行檢查，如果有任何失敗，將還原狀態。在執行過程中，使用 Gas 計量器來跟蹤使用了多少燃料 (gas)。如果髮生任何燃料錯誤（例如，燃料不足），則與執行失敗後的後果相衕，狀態更改將被還原。
提交區塊：當節點接收到足夠的驗證者投票時，它就會提交一個新的區塊以添加到區塊鏈中，併最終確定應用層中的狀態轉換。
Cosmos 生態上的交易生命周期圖
以下是 Cosmos SDK 的具體執行邏輯，在分析下文漏洞觸髮路徑時可以方便查閲理解：
Cosmos SDK 重點 ABCI 的具體執行邏輯
常見漏洞分類
在了解漏洞分類之前，我們需要對漏洞危險程度有一個基本畫分，這樣有助於更好地識別出危險性大的安全漏洞，盡可能規避潛在的安全風險。
從危險程度和影響範圍考慮，我們主要關註 Critical 和 Major 評級的安全漏洞，它們通常可以造成以下風險：
鏈停止運行
資金損失
影響繫統狀態或正常運行
而這些危險的起因往往是以下幾種類型的安全漏洞：
拒絶服務
錯誤的狀態設置
驗證缺失或者不合理
唯一性問題
共識算法問題
實現上的邏輯漏洞
語言特性問題
漏洞分析
由於 Cosmos 生態模塊化的特殊性，各類鏈條實現上存在大量模塊間相互使用，模塊內相互調用的案例，因此存在漏洞觸髮路徑與漏洞觸髮位置變量的可控路徑不一緻的情況，我們在分析漏洞具體觸髮原因時不應隻關註觸髮路徑，還應該關註漏洞關鍵變量的可控路徑，這樣才能幫我們更好地畫分定義漏洞模型。
鏈停止運行
鏈停止運行的罪魁禍首大多情況下是單個區塊執行過程中産生的問題，但在 Cosmos 的歷史髮展過程中也出現過共識安全漏洞而導緻鏈不得不主動停止來修覆的情況，因此這裡把影響共識類型的安全漏洞也放到導緻鏈停止運行效果裡來討論，我們會分別來講這兩類問題。
第一類情況常見的是拒絶服務類型的漏洞，其具體原因主要是不當的崩潰處理與循環邊界可被用戶影響的遍歷操作。此類漏洞往往會使得鏈暫停運行，或者減緩其運行速度等。
前文中有提到 Cosmos SDK 和 CometBFT 作爲 Cosmos 生態中關鍵的基礎設施，它們不僅被 Cosmos 中的基礎鏈使用，各類的應用鏈也都基於其架構實現各自邏輯，因此它們都會遵從 CometBFT 的 ABCI 接口規則，其攻擊麵重點也是在其 ABCI 接口上，而能夠造成的 Chain halt 的安全漏洞大多是可以直接影響到區塊代碼執行的問題，因此其髮生的路徑基本都可溯源到 BeginBlock 和 EndBlock 兩個接口。
第二類情況是屬於影響到共識的漏洞，通常和各類鏈的實現相關，目前已知的常見於一些邏輯處理驗證，時間校準和隨機性問題。此類漏洞從本質上會影響到區塊鏈的去中心化原則，直觀上看可能併沒有太大影響，但假如經過有心者惡意設計，那麽依然會産生較大的安全風險。
第一類情況
- 案例一：SuperNova 項目
漏洞背景：鑄幣分髮操作中缺乏地址驗證，從而導緻操作失敗，資金流失。在鑄幣模塊中，每次 token 鑄造都取決於抵押金額。然而，如果池不存在或者合約地址輸入錯誤，鑄幣模塊可能會髮生意外情況，導緻區塊鏈停止運行。在獎勵池模塊中，池合約地址沒有經過驗證。如果分髮操作失敗，鏈將直接停止運行。
漏洞代碼片段：
漏洞觸髮路徑：
BeginBlocker (/x/mint/keeper/abci.go)
Keeper.DistributeMintedCoin
Keeper.distributeLPIncentivePools
PoolIncentiveKeeper.GetAllIncentivePool (/x/mint/keeper/keeper.go)
漏洞補丁：
https://github.com/Carina-labs/nova/commit/538abc771dea68e33fd656031cbcf2b8fe006be0
補丁位於 poolincentive 的消息處理模塊 (x/poolincentive/types/msgs.go)，而非 mint 模塊。
對處理 MsgCreateCandidatePool（即創建 pool）時的消息做了地址校驗，是想從根源上杜絶錯誤地址的可能。
- 案例二：Cosmos Interchain Security 項目
項目地址：https://github.com/cosmos/interchain-security
漏洞背景：驗證者可以通過在衕一個區塊中提交多個 AssignConsumerKey 消息來減緩提供鏈的速度。在 x/ccv/provider/keeper/key_assignment.go 中定義的 AssignConsumerKey 函數使驗證者能夠爲經批準的消費鏈分配不衕的 consumerKey。爲了執行此操作，consumerAddrsToPrune AddressList 會增加一個元素。由於在 x/ccv/provider/keeper/relay.go 中的 EndBlocker 中會遍歷這個 AddressList，攻擊者可以利用它來減慢提供鏈的速度。爲執行這種攻擊，惡意行爲者可以創建具有多個 AssignConsumerKey 消息的交易，併曏提供鏈髮送這些交易。consumerAddrsToPrune AddressList 的基數將與髮送的 AssignConsumerKey 消息相衕。因此，EndBlocker 的執行將花費比預期更多的時間和資源，導緻提供鏈運行速度減緩，甚至停止。
漏洞代碼片段：
漏洞觸髮路徑：
msgServer.AssignConsumerKey
Keeper.AssignConsumerKey
AppModule.EndBlock
EndBlockCIS
HandleLeadingVSCMaturedPackets
HandleVSCMaturedPacket
PruneKeyAssignments
- 案例三：Quicksilver 項目 -Airdrop 模塊
漏洞背景：BeginBlocker 和 EndBlocker 是模塊開髮人員可以在其模塊中實現的可選方法。它們分別在每個區塊的開始和結束時觸髮。在 BeginBlock 和 EndBlock 方法中使用崩潰來處理錯誤可能會導緻鏈在出現錯誤時停止。EndBlocker 清算未完成的空投時未考慮模塊是否有足夠的代幣從而觸髮崩潰的可能，導緻鏈停止運行。
漏洞代碼片段：
漏洞觸髮路徑：
AppModule.EndBlock
Keeper.EndBlocker
Keeper.EndZoneDrop
直接去掉了 panic 的處理代碼，換成了記録錯誤日誌。
- 案例四：Cosmos Interchain Security 項目
項目地址：https://github.com/cosmos/interchain-security
漏洞背景：攻擊者可以通過曏提供鏈的獎勵地址髮送多個代幣來可以實現拒絶服務攻擊。
在消費鏈的 EndBlocker 執行流程中，在 x/ccv/consumer/keeper/distribution.go 中定義的 SendRewardsToProvider 函數穫取 tstProviderAddr 中所有代幣的餘額，併將它們髮送到提供鏈。爲了實現這一點，它必鬚遍歷獎勵地址中找到的所有代幣，併逐個通過 IBC 髮送到提供鏈。由於任何人都可以曏獎勵地址髮送代幣，攻擊者可以創建併髮送大量不衕 denom 的代幣，例如使用具有 token 工廠模塊的鏈，來髮起拒絶服務攻擊。因此，EndBlocker 的執行將花費比預期更多的時間和資源，導緻消費鏈運行速度減緩，甚至停止。
漏洞代碼片段：
漏洞觸髮路徑:
AppModule.EndBlock
EndBlock
EndBlockRD
SendRewardsToProvider
第二類情況
這一類共識問題可能併不能帶來直觀的嚴重危害，但是從整個區塊鏈本質原則和體繫考慮，亦或是從具體的場景去看這些漏洞的話，它們帶來的影響和危害併不見得比其他常規漏洞危害小，除此之外，這類漏洞也有存在著共衕點。
- 案例一
漏洞背景：Cosmos SDK Security Advisory Jackfruit
Cosmos SDK 的 x/authz 模塊中 ValidateBasic 方法的非確定性行爲容易導緻共識停止。x/authz 模塊的 MsgGrant 消息結構包含一個 Grant 字段，其中包括用戶定義的授權所授予的到期時間。在 Grant 結構的 ValidateBasic() 驗證處理中，比較其時間信息與節點本地的時間信息而不是區塊時間信息，由於本地時間是非確定性的，各個節點的時間戳可能存在差異，因此會導緻共識問題。
漏洞公告：
https://forum.cosmos.network/t/cosmos-sdk-security-advisory-jackfruit/5319
https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-2p6r-37p9-89p2
漏洞代碼片段：
漏洞補丁：
https://github.com/cosmos/cosmos-sdk/compare/v0.44.1...v0.44.2
像關於時間戳這樣的問題不僅會出現在 Cosmos SDK 這樣的基礎組件中，在各類應用鏈中也曾出現過類似的漏洞。
- 案例二
漏洞背景：SuperNova，nova 項目
項目地址：https://github.com/Carina-labs/nova/tree/v0.6.3
使用 time.Now() 返回操作繫統的時間戳。本地時間是主觀的，因此是非確定性的。由於各個節點的時間戳可能存在小的差異，因此鏈可能無法達成共識。在 ICAControl 模塊中，交易髮送函數使用 time.Now() 來穫取時間戳。
漏洞代碼片段：
漏洞補丁:
將使用本地時間戳改爲了使用區塊時間。
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))
- 案例三
漏洞背景：BandChain 項目的預言機模塊
項目地址：https://github.com/bandprotocol/bandchain/
代碼庫中的註釋錶明，預言機模塊必鬚在質押之前執行，以便實現違反預言機協議者的懲罰措施。代碼中出現的順序是：在 SetOrderEndBlockers 函數中，質押模塊在預言機模塊之前運行。如果質押模塊在預言機模塊之前執行，那麽基於預言機模塊中完成的驗證來懲罰驗證者質押等操作將是不可能實現的。
漏洞位置：https://github.com/LeastAuthority/bandchain/blob/master/chain/app/app.go#L221-L225
漏洞代碼片段：
可以看到漏洞具體實現和漏洞註釋完全是反過來的，預言機模塊應該排在質押模塊之前。
- 案例四
漏洞背景：Sei Cosmos 項目的 accesscontrol 模塊
項目地址：https://github.com/sei-protocol/sei-cosmos
在 Cosmos 各類代碼庫的多個實例中，go map iteration 都有使用 go 語言的 map 類型，併對其進行了迭代。由於 go 語言的 map 的迭代是非確定性的，這將導緻節點達到不衕的狀態，這可能會導緻共識問題，從而導緻鏈停止運行。比較合適的處理方法是將映射鍵排序到一個切片中，併迭代排序後的鍵。此類問題比較普遍，屬於是語言特性在運用上引入的問題。
在 x/accesscontrol/keeper/keeper.go 的 BuildDependencyDag 的實現中，節點迭代 anteDepSet。由於 Go 中映射迭代的非確定性行爲，ValidateAccessOp 可能會出現兩種不衕類型的錯誤，這可能會導緻共識失敗。
漏洞代碼片段：
根據這些案例可以髮現，對於使得鏈被動停止運行的漏洞危害性往往最大，其漏洞起因的邏輯關繫都可追溯到直接影響區塊鏈中單個區塊運行的執行流程。而像一些共識安全漏洞，往往是鏈主動停止運行去修覆，其漏洞起因的邏輯關繫都可追溯到影響區塊鏈整體的運行流程和狀態。與我們接下來討論的造成資金損失類型的漏洞關註點不衕，資金損失類型的漏洞通常不會去根據其問題出現的邏輯路徑來判斷其具體危險影響程度，而是更關註其資金的擁有者、資金量的大小、影響資金的範圍以及影響資金的方式等。
資金損失
資金損失類問題常見於對 sdk.Msg 和 IBC 消息的邏輯處理中，當然在能夠造成鏈停止運行的原因中也存在有部分漏洞可以造成鏈資金損失的效果，具體影響還得看具體漏洞，這裡著重討論前者。此外由於 IBC 是 Cosmos 生態中非常重要的一環，因此難免會涉及到 IBC 的部分漏洞，具體關於 IBC 的攻擊麵與相對應的漏洞我們放到下一章節去探討。
資金損失常見於 gas 消耗、資金被鎖無法取出、資金傳輸過程中丟失、計算邏輯錯誤導緻資金損失和資金存儲 ID 未保證唯一性等邏輯情況。
這裡我們以 SuperNova 項目爲例，分析下和它相關的三個漏洞。
- 漏洞背景：SuperNova 項目
項目地址：https://github.com/Carina-labs/nova
如果區域（zone）的小數位數高於 18，資金可能會被鎖定。在該項目代碼中，區域的小數位數沒有上限，可以超過 18 位。在 ClaimSnMesssage 中，當用戶希望索取他們的份額代幣時，使用了 ClaimShareToken。然而，如果區域的小數位數高於 18，那麽轉換將失敗，無法從繫統中提取資産。因此通過控製區域小數位數，可以直接觸髮交易崩潰失敗。
漏洞位置：https://github.com/Carina-labs/nova/blob/v0.6.3/x/gal/keeper/claim.go#L167
漏洞代碼片段：
漏洞觸髮路徑：
msgServer.ClaimSnAsset
Keeper.ClaimShareToken
Keeper.ConvertWAssetToSnAssetDecimal
precisionMultiplier
- 漏洞背景：SuperNova 項目
項目地址：https://github.com/Carina-labs/nova/
區域的唯一性未經驗證。在已註冊的區域上，使用區域 ID 來檢查基礎代幣（BaseDenom）的唯一性，每個區域的 BaseDenom 應該是唯一的，如果基礎代幣的值設置錯誤，將導緻資金損失。該項目在 RegisterZone 中設置基礎代幣之前，併未確保 BaseDenom 在所有主區域中都是唯一的，否則會存在用戶曏另一含有衕名 BaseDenom 的惡意 zone 存儲資金的可能性，從而造成資金損失。
漏洞位置：https://github.com/Carina-labs/nova/blob/v0.6.3/x/icacontrol/keeper/msg_server.go#L99
漏洞代碼片段：
漏洞補丁：多了 DenomDuplicateCheck 檢查
除此之外上文鏈停止運行第一種情況中的案例一，是由於崩潰導緻鑄幣失敗，也是資金損失的一種形式。
- 漏洞背景：Supernova 項目
項目地址：https://github.com/Carina-labs/nova/
缺少狀態更新。在 IcaWithdraw() 方法中，如果交易失敗，版本狀態沒有修改，會導緻 WithdrawRecord 無法訪問，對應的資金也無法提取。更通俗的理解就是 state 設置在 SendTx 前,失敗後未修改 state，導緻該資金回撤失敗併且下次無法再次回撤。
漏洞代碼片段：
根據這部分的案例可以髮現，與資金相關的操作主要實現邏輯，還是取決於對各類消息的處理，當然也存在如第一類情況的案例一在 BeginBlock 執行流程中涉及到的鑄幣操作，當這些操作失敗時也會導緻資金損失。整體來説，我們將審計重點放在涉及資金操作的代碼模塊就可以大幅提高髮現此類漏洞的可能性。
影響繫統狀態或正常運行
此類問題範圍比較寬泛，剛才討論的前兩者危害其實也可以認爲是影響繫統狀態或正常運行的漏洞類型的子集。除此之外，危險性更大的更多是一些邏輯類型的漏洞，很大程度上，這類漏洞會根據項目的業務邏輯而産生不衕的安全風險，但是由於 Cosmos SDK 組件構造的相似性以及模塊化的特點，在具體代碼實現時候往往會犯下類似的錯誤，這裡給大家列舉下常見的漏洞類型：
sdk.Msg 類型中變量校驗不完全
由於各項目基於 sdk.Msg 實現了各式各樣的派生類型，但是在 Cosmos SDK 中其實併未對所有已有類型的各個元素做相應的檢測，導緻疏漏了一些關鍵的內嵌變量檢測，從而存在一定的安全風險。
- 案例一：Cosmos SDK Security Advisory Barberry
漏洞背景：MsgCreatePeriodicVestingAccount.ValidateBasic 驗證機製缺失對賬戶的存活等狀態的判斷。在 x/auth 中定義的 PeriodicVestingAccount，攻擊者可以將受害者的賬戶初始化爲惡意歸屬賬戶，該賬戶允許存款但不允許取款。當用戶將資金存入其賬戶時，這些資金將被永久鎖定，併且用戶無法提取。
漏洞補丁：
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
漏洞代碼片段：
除此之外，Cosmos-SDK Security Advisory Elderflower、Cosmos-SDK Security Advisory Jackfruit，其實都是在 ValidateBasic 環節出現的問題，前者是直接缺失了對 ValidateBasic 的調用，後者則是在消息內部關於時間戳變量校驗出現的問題。而在應用鏈，此類的問題更是常見，像 ethermint，pstake-native，quicksilver 等項目在處理消息的驗證措施上都出現過類似的安全漏洞。
除了驗證類型，在 sdk.Msg 的處理邏輯中，也會遇到如涉及到大量 gas 消耗的循環操作，不合理的崩潰處理等，由於針對消息的處理鏈上具備相應的 recovery 機製，因此它們的危險程度相對於鏈停止運行會低一些，但依然可以影響到繫統的正常運行或是導緻鏈上資金的損失。
常見類型漏洞
除去根據項目業務特有的安全漏洞，還存在一些比較常見的漏洞模型，比如資金損失案例三，就是一個在髮送消息前改變狀態的操作，這類漏洞和智能合約中的漏洞很相似，在傳輸資金之前先改變了自身的狀態，往往會帶來如重入或者遺留的錯誤狀態等問題，像這種狀態設置和消息傳輸緊密結合的場景在區塊鏈中其實十分常見，很多造成重大危險的漏洞都是源於此類問題。除此之外，還有一些計算上的安全漏洞類似於除零漏洞、gas 消耗繞過、使用有漏洞的版本等，這類漏洞都會影響到繫統狀態或繫統正常運行。
唯一性問題
由於區塊鏈上涉及到大量的查找讀取存儲操作，因此在某些功能實現中，命名的唯一性非常重要。例如前文資金損失案例二，就是唯一性問題，除此之外一些代錶 key 等重要因素的 string 或者 byte 數組類型的變量，有時候它們的前綴組成也會存在一定的風險，比如是否存在「/」作爲每次命名的結尾等，稍有不慎就可能會導緻命名被僞造成另一種含義的字符串，從而導緻一繫列如資金損失、共識出錯等問題。
語言特性問題
這類問題更加寬泛一些，但是比較有特徵可循，因此較爲容易被髮現，比如 golang 的 map 迭代問題、rust 中的一些 panic 機製問題等，建議在使用對應語言前，將這些語言特性本身可能會導緻對應風險的點列舉出來，在使用或者審計時單獨關註即可最大程度上避免此類錯誤。
小結
根據我們對 Cosmos 生態底層安全問題的探索，其實不難髮現，此類問題不僅適用於 Cosmos 生態，有很多漏洞模型衕樣可以運用在其他的生態鏈中，以下是有關研究 Cosmos 生態繫統安全問題的一些建議和總結：
- 關註基礎設施漏洞：CometBFT 和 Cosmos SDK 的核心組件也可能存在漏洞，因此需要對這些組件進行定期更新和維護，以確保安全性。
- 及時審查第三方庫：Cosmos 開髮者通常使用第三方庫來擴展其應用程序的功能。然而，這些庫可能包含潛在的漏洞，因此需要審查和更新這些庫以降低風險。
- 註意惡意節點攻擊：在 Cosmos 生態繫統中，共識節點是網絡的關鍵組成部分。節點的拜占庭容錯算法可能會受到攻擊，因此需要確保節點的安全性以防止不良行爲。
- 註意物理安全：對於運行 Cosmos 節點的硬件和服務器，需要採取物理安全措施以防止未經授權的訪問和潛在的攻擊。
- 必要的代碼審查：由於 Cosmos SDK 和 CometBFT 生態繫統的開放性，開髮者和審查員應該對核心代碼以及在自定義模塊中編寫的代碼進行審查，以識別和糾正潛在的安全問題。
- 留意生態繫統工具：Cosmos 生態繫統包括許多工具和應用程序，這些工具也需要進行安全審查和定期更新，以確保其安全性。
IBC 協議安全指南
本模塊將重點探討 IBC 協議 (The Inter-Blockchain Communication protocol) 方麵相關的安全問題。IBC 協議是 Cosmos 中極其重要的一環，它的作用是架起各鏈之間的交互橋梁，假如説其他各類跨鏈橋是爲一些較爲獨立的問題提供解決方案，那麽 IBC 協議可以説是爲鏈之間的交互問題提供了統一的基礎解決方案和底層技術支持。IBC 是一種允許異構區塊鏈以可靠、有序和信任最小化的方式傳遞任何數據的協議。
自比特幣問世以來，區塊鏈領域經歷了爆炸性的增長。數不清的新網絡紛紛涌現，它們各自擁有獨特的價值主張、共識機製、意識形態、支持者和存在理由。在引入 IBC 之前，這些區塊鏈大都處於獨立運作的狀態，就像存在於封閉的容器中，無法相互通信，然而這種封閉的模式從根本上是不可持續的。
假如將區塊鏈視爲各個人口不斷增長併充滿商業活動的國家，有的區塊鏈擅長農業，而有的在畜牧業方麵錶現出色，它們自然而然地希望進行互利的貿易和合作，各自髮揮自身優勢。毫不誇張地説，IBC 開辟了一個充滿無限可能性的新世界，使不衕的區塊鏈能夠互操作、傳遞價值、交換資産和服務，併建立連接，而不受今天大型區塊鏈網絡固有的可擴展性問題所限製。
那麽 IBC 是如何滿足這些需求，併起到至關重要的作用呢？根本原因在於 IBC 是：
無需信任的
可支持異構區塊鏈的
可在應用層進行自定義的
經過檢驗的成熟技術
IBC 協議的基礎是輕客戶端（light clients）和中繼器（relayers）。通過 IBC 進行通信的鏈 A 和鏈 B 互相具有對方賬本的輕客戶端。鏈 A 無需信任第三方，隻需通過驗證區塊頭就可以對鏈 B 的狀態達成共識。通過 IBC（尤其是模塊）進行交互的鏈彼此間不會直接傳送消息。相反，鏈 A 將數據包中的一些消息衕步至其狀態。隨後，中繼器會對這些數據包進行檢測，併將它們傳送給目標鏈。
總的來説，IBC 協議可分爲兩層，分別是IBC TAO 和 IBC APP。
IBC TAO：定義數據包的傳輸、身份驗證和排序的標準，即基礎設施層。在 ICS 中，這由核心、客戶端和中繼器類別組成。
IBC APP：定義通過傳輸層傳遞的數據包的應用程序處理程序的標準，這些包括但不限於衕質化代幣轉賬 (ICS-20)、非衕質化代幣轉賬 (ICS-721) 和鏈間賬戶 (ICS-27)，併且可以在應用程序類別的 ICS 中找到。
IBC 圖錶 ( 來自 Cosmos Developer Portal)
IBC 協議是 Cosmos 堅持的區塊鏈互聯網（Internet of Blockchains）願景的支柱。從這個意義上説，IBC 的設計選擇受到了 TCP/IP 規範的影響。與 TCP/IP 爲計算機通信製定標準的方式類似，IBC 也指定了一組通用抽象，通過將其實現可以允許區塊鏈進行通信。TCP/IP 對通過網絡中繼的數據包的內容不設限製，IBC 也是如此。此外，與 HTTP 和 SMTP 等應用協議在 TCP/IP 上搭建的方式類似，衕質化資産 / 非衕質化資産傳輸或跨鏈智能合約調用等應用實例也將 IBC 協議作爲基礎層。
目前 IBC 協議出現的主要問題都是在關於通道傳輸和數據包的處理上，當然也不乏在證明驗證等環節出現過比較大的問題，但那些問題相對較少，本文重點討論 IBC 協議的常見問題。由於 IBC 協議的模塊化設計，IBC 應用程序開髮人員可以無需關註客戶端、連接和證明驗證等底層細節。但他們需要實現 IBCModule 接口，以及相對應的 Keeper 處理方法等，因此較多 IBC 協議相關的問題都出現在 IBCModule 關於接收和處理數據包的接口（onRecvPacket, OnAcknowledgementPacket, OnTimeoutPacket 等）代碼路徑中。
常見漏洞分類
在 Cosmos 生態中，IBC 協議作爲連接樞紐，從漏洞種類上來説IBC 協議相關的漏洞更爲豐富，出現漏洞的位置更加覆雜，由於 IBC 協議的相關實現和 Cosmos-SDK，CometBFT 等模塊結合密切，下文中難免會提到一些 Cosmos 生態其他模塊的實現。此外，目前 IBC 主要運用在 Cosmos 生態繫統中，因此其主流使用語言還是 Golang，詳情可見 ibc-go 相關文檔。
由於篇幅限製，這裡不再針對 IBC 協議中各個環節和組件做細緻的分析，隻對現有的一些安全漏洞做分類探討，如果想了解更爲細緻和全麵的分析，歡迎聯繫我們 CertiK 的安全工程師交流探討。
常見漏洞分類：
1.命名漏洞
① 字符串處理漏洞
② 字節碼處理漏洞
- 傳輸過程漏洞
① 數據包順序漏洞
② 數據包超時漏洞
③ 數據包認證漏洞
④ 其他數據包漏洞
- 邏輯漏洞
① 狀態更新漏洞
② 投票共識等漏洞
③ 其他邏輯漏洞
- Gas 消耗漏洞
現有的 IBC 協議，在審計和分析其安全性的流程上和 Web2 協議的審計流程上具有較多相似性，這次我們將從協議的製定、實現和運用擴展這樣一個完整流程的角度來剖析 IBC 協議上的部分安全問題和潛在風險。由於協議的製定往往是由少數人員和組織去完成的，對於各類區塊鏈組織來説，更多的工作是圍繞在協議的實現和運用擴展上，因此本文也將重點討論這兩者的安全問題。這是出於對 IBC 協議安全風險涵蓋範圍廣的考慮，能更好地把協議上不衕類型的安全問題畫分到對應的環節和模塊中。
漏洞分析
IBC 協議的製定
- 案例一：ICS-07 協議，邏輯漏洞
漏洞背景：解綁期限的錯誤使用
在代碼中存在如下校驗：
if currentTimestamp.Sub(consState.Timestamp) >= clientState.UnbondingPeriod {
根據 Tendermint 安全模型來看，時間爲 t 的區塊（標頭）的 NextValidators 中的驗證器需要在 t+TrustingPeriod 之前正確運行，在那之後，它們可能會有其他行爲。然而這裡檢查的是 UnbondingPeriod，而不是 TrustingPeriod，其中 UnbondingPeriod>TrustingPeriod。如果 consState 的期限介於 TrustingPeriod 和 UnbondingPeriod 之間，那麽將接受該標頭作爲用於驗證構成不當行爲的其中一個衝突標頭的基準。在此期間，consState.NextValidators 中的驗證器不再被認爲是值得信任的，敵對的前驗證者可以在不冒任何風險的情況下關閉客戶端。
漏洞代碼片段：
協議定義函數
代碼實現
IBC 協議的實現
IBC 協議的實現環節是比較容易出現問題的地方，因爲這個環節起到了承上啟下的作用，既要盡可能的避免協議規範中的歧義問題，又需要爲了協議後續的運用和擴展實現提供更爲基礎便捷的接口。因此這裡將 IBC 協議實現環節的主要問題再做一個小分類，即：
協議實現中的歧義和不規範問題
協議設定誤差問題
協議實現中的歧義和不規範問題
- 案例一：ICS-20 協議，命名漏洞
漏洞背景：托管地址衝突。GetEscrowAddress() 是截斷爲 20 字節的 SHA256（端口 ID+ 通道 ID）。這種方法存在三個問題：
1.端口和通道之間沒有域分隔，使用字符串串聯不會分隔端口和通道的域。例如端口 / 通道組合（「transfer」、「channel」）和（「trans」、「ferchannel」）將給出相衕的托管地址，即截斷的 SHA256（「transferchannel」）。如果某些具有庫功能的模塊能夠選擇端口和通道 ID，則可能會出現漏洞。
2.模塊賬戶地址之間的衝突。在 SHA-256 的前映像中使用任意的字母數字字符串，後映像大小爲 160 位。這種小後映像和快速的哈希函數的組合使得生日攻擊成爲可能，因爲其安全性僅降至 80 位。這意味著大約需要 2^80 次猜測即可找到兩個不衕的托管賬戶地址之間的碰撞。2018 年，在 Tendermint 的背景下已經進行了詳細的攻擊 SHA256 截斷的成本分析，證明了從成本的角度來看這種攻擊是可行的，找到碰撞意味著兩個不衕的托管賬戶映射到衕一個賬戶地址。這可能導緻存在從托管賬戶中盜取資金的風險，詳情可查看 ICS20 GetEscrowAddress pre-image domain overlaps with public keysT:BUG。
- 模塊和非模塊賬戶地址之間的衝突。公共賬戶地址的構造與 Ed25519 公鑰的 20 字節 SHA-256 相衕。雖然 160 位的安全性足以防止對特定公共地址的衝突攻擊，但針對生日攻擊的安全性又隻有 80 位。這種情況類似於一種半生日攻擊模式，其中一個地址由快速 SHA-256 生成，另一個地址由相對較慢的 Ed25519 公鑰計算生成。雖然這種情況會更加安全，但它仍然會引髮對托管和公共賬戶的潛在攻擊。
漏洞代碼片段：
協議設定誤差問題
- 案例一：IBC Security Advisory Dragonberry，傳輸過程漏洞
漏洞背景：IBC 在處理應用數據包時會使用一個 Packet 的結構，根據超時機製，衕步和異步的確認機製以及相應的證明驗證流程，數據包會分成兩個執行流程：
1.正常情況：超時內成功
2.超時情況：超時失敗
IBC 應用數據包傳輸流程圖
當髮生超時情況時，説明此次傳輸失敗，IBC 協議便會髮起退款流程，衕時需要註意的是 IBC 具有用戶可配置的超時機製。此次的 Dragonberry 漏洞源自 ICS-23(IBC)，該漏洞的根本原因在於用戶可以僞造驗證流程中的不存在證明（即未收到數據包的虛假證明），從而繞過安全校驗，僞造出「合理的」IBC 超時情況來欺騙 IBC 協議，導緻中繼器髮送帶有虛假證明的超時數據包，併可能會升級爲 ICS-20 雙花問題，其漏洞的具體觸髮流程可以看下圖。
Dragonberry 漏洞原理流程圖
漏洞代碼片段：
- 案例二：IBC Security Advisory Huckleberry，傳輸過程漏洞
漏洞背景：UnreceivedPackets 僅通過查找查詢中包含的每個序列號的相應數據包收據來構建響應。這僅適用於無序通道，因爲有序通道使用的是 nextSequenceRecv 而不是數據包收據。因此，在有序通道上，通過 GetPacketReceipt 查詢序列號不會找到其中的收據。
此問題的嚴重程度較輕，因爲 ICS-20 FT 傳輸的通道大部分是無序的，併且中繼器不依賴這個 grpc 端點來確定觸髮超時數據包。然而，假如目標鏈中有大量數據包，衕時配置了用於 IBC 傳輸的有序通道，且沒有對 grpc 響應進行分頁，這將産生導緻服務節點性能下降甚至崩潰的風險。其具體的觸髮流程可以看下圖。
Huckleberry 漏洞原理流程圖
漏洞代碼片段：
IBC 協議的運用和擴展
- 案例一：stride airdrop 漏洞，邏輯漏洞
漏洞背景：TryUpdateAirdropClaim 該函數將 IBC 數據包的髮送者地址轉換爲名爲 senderStrideAddress 的 Stride 地址，併從數據包元數據中提取 airdropId 和新的空投地址 newStrideAddress。然後調用 UpdateAirdropAddress 來更新 senderStrideAddress 和 ClaimRecord。隨著 ClaimRecord 的更新，newStrideAddress 將能夠領取空投。然而這裡更新函數隻校驗了 sender 該請求的地址是否爲空，未對 newStrideAddress 做校驗，由於 ibc 允許 solo machine 連接實現 IBC-enabled 的鏈，因此這裡就存在更新任意其他賬戶地址作爲空投地址的安全風險。
項目地址：https://github.com/Stride-Labs/stride/tree/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot
漏洞代碼片段：
- 案例二：neutron ibc 模塊漏洞，gas 消耗漏洞
漏洞背景：智能合約爲 IBC 事件的確認 / 超時支付的費用沒有得到足夠的驗證，惡意智能合約可以利用這一點在 OnAcknowledgementPacket 和 OnTimeoutPacket 消息處理期間導緻 ErrorOutOfGas 崩潰。這些崩潰不會通過 outOfGasRecovery 執行來恢覆，這意味著交易不會包含在區塊中，併且會導緻 IBC 中繼器重覆提交消息，最終可能會造成中繼器資金流失和網絡廢棄數據包過多的危害。
項目地址：https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/
漏洞位置：
漏洞代碼片段：
小結
根據上文對 IBC 協議安全問題的研究分析，其實不難髮現，IBC 協議的安全問題分布範圍廣，且問題多樣，但主要問題還是出現在 IBC 協議的實現和運用擴展上。在各大應用鏈逐漸豐富完善自身傳統模塊功能性的衕時，爲了貼合自身業務需求，優化運行效果，也在對應的 IBC 模塊中添加了不衕的代碼實現。
除了上文提到 IBC 環節中的安全問題外，其他一些如 IBC 中間件的安全問題也在涌現，相信在未來，IBC 模塊方麵的安全問題會成爲 Cosmos 生態安全中的重要一環。
總結
在針對 Cosmos 生態安全的探索與研究過程中，我們經歷了覆雜的審計、彙總和分類工作，探討了關於 Cosmos 生態裡最爲關鍵的 Cosmos SDK 和 IBC 協議兩者的安全問題，併通過豐富的實踐經歷，總結出大量通用的審計經驗。
本報告突顯了在麵對支持跨鏈交互的異構網絡時所麵臨的挑戰，由於其組成元件覆雜且分散，因此在對這些組件進行安全審計時衕樣具有挑戰性，我們不僅需要通過已有的安全經驗去排查固有的一些安全風險，還需要不斷麵臨新的安全場景，分析新的安全問題。
盡管如此，我們依然相信，通過類似本報告所總結的一些通用場景和安全問題，可以逐步提高異構網絡 Cosmos 生態整體的安全性。
聲明：
- 本文轉載自[CertiK]，著作權歸屬原作者[CertiK]，如對轉載有異議，請聯繫Gate Learn團隊，團隊會根據相關流程盡速處理。
- 免責聲明：本文所錶達的觀點和意見僅代錶作者個人觀點，不構成任何投資建議。
- 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。
Статті на тему
如何質押 ETH？
什麼是穩定幣 USDT？
