原文作者：Cosmos 聯合創始人Ethan Buchman
關於幣安黑客事件的一些想法。 Binance是Cosmos軟件的最大用戶，他們運營著一個價值數百億美元的平台，但沒有對核心軟件做出有意義的貢獻或參與。從這裡發生的事情中，我們可以學到很多。
你可能看到了samczsun 的優秀推文貼展示了這個問題。 https://twitter.com/samczsun/status/1578167198203289600讓我們嘗試補充一些有關情況的詳細信息。
一個官方防禦補丁已發佈在這裡：https://forum.cosmos.network/t/cosmos-sdk-security-advisory-dragonfruit/7614
友情提醒：如果你發現Cosmos 軟件存在潛在漏洞，請遵循我們負責任的披露流程：
https://github.com/cosmos/cosmos-sdk/blob/main/SECURITY.md
問題的癥結在於黑客能夠偽造一個默克爾證明（merkle proof），這不應該是可實現的– 默克爾證明應該是高度安全的。區塊鏈輕客戶端（以及IBC）建立在默克爾證明（merkle proof）之上，因此正確處理它們很重要。
默克爾證明是數據存儲中存在某些鍵值對的加密貨幣學證明， 我們可以稱之為“包含證明”。很多區塊鏈將其數據存儲在一棵默克爾樹（merkle tree）中，以便可以生成證明某些數據包含在樹中的證明。
默克爾證明在IBC 中被大量使用，例如，一個區塊鏈可以證明它有一個指向另一個區塊鏈的數據包。當然，如果你可以證明某些數據在樹中，但實際上並沒有，那將是一個大問題。而這就是在幣安身上發生的事。
Cosmos 鏈使用一種稱為IAVL 的默克爾樹，它位於IAVL 存儲庫中。它附有一首關於默克爾樹有多棒的詩。 IAVL 是一個自定義的默克爾化平衡二叉搜索樹，它類似於以太坊的帕特里夏樹（patricia trie）。
https://github.com/cosmos/iavl/blob/master/POEM
每個區塊鏈開發人員在接觸這些結構的架構和算法時，都不得不陷入默克爾樹的瘋狂之中。
IAVL 存儲庫公開了一個API，用於使用一個“RangeProof”對象構建和驗證證明。一個範圍證明（Range Proof）用於證明某些範圍的key 在默克爾樹中並列存在。
一個範圍證明還可用於證明單個鍵值對（範圍大小為1），或證明某個鍵不在樹中（範圍大小為2）。
IAVL 存儲庫將RangeProof 對像用於所有三種證明（包含、不存在、範圍內的鍵）。但事實證明RangeProof 的內部工作存在一個嚴重漏洞。
一個證明應該由一個子葉節點和一系列內部節點組成，這些節點勾勒出從子葉到根的路徑，並具有足夠的信息來計算樹的merkle 根哈希並驗證子葉實際上是樹的一部分。
由於這是一棵二叉樹，所以每個內部節點都可以有一個左分支和右分支。但是在證明中，你是在樹中跟踪路徑，因此內部節點應該只包含其左分支或右分支哈希。另一個是由證明中其他節點的哈希構造的。
這就是IAVL RangeProof 的代碼遇到問題的地方。 IAVL RangeProof 允許填充InnerNode 中的Left 和Right 字段。而這不應該發生。
攻擊者基本上利用了將信息粘貼到Right 字段中的優勢，它們從未經過驗證，也從未影響哈希計算，從而使驗證者相信某些子葉是樹的一部分。因此，他們成功地偽造了一個默克爾證明。
值得注意的是，這個問題取決於攻擊者能否將子葉添加到單個證明中，因為RangeProof 允許你一次證明多個子葉。因此，即使你的協議只希望一次證明一個key，使用RangeProof 也會為攻擊者打開攻擊面。
所以使用RangeProof 並不是一個好主意。但是我們也可以提出一個簡單的防禦措施——如果任何內部節點同時填充了Left 和Right 字段，則預先拒絕證明。這樣做應該可以解決這個問題。
雖然RangeProof 是一個核心Cosmos 存儲庫(IAVL) 的一部分，但它實際上並未用於Cosmos 堆棧內的區塊鏈協議中。 IAVL 樹本身被所有Cosmos SDK 鏈使用，但RangeProofs 並沒有。這是理解的關鍵
相反，對於IBC 中的默克爾證明，開發者按照IBC 標准設定的更嚴格的流程開發了一個新規範。該規範稱為「ICS23」，它位於IBC 規範存儲庫中：https://github.com/cosmos/ibc 中。
那什麼是ICS23？這是支持多種默克爾樹的默克爾證明的通用標準（包括IAVL 樹）。 ICS23 定義了一種用於序列化和驗證默克爾證明的通用格式。
IBC 沒有使用IAVL 樹的內置RangeProof 系統，而是使用ICS23 標準來生成和驗證IAVL 樹的默克爾證明。而ICS23 代碼中並沒有這個漏洞。
這不僅僅是使用不同的代碼，並因此僥倖躲過一劫的問題。這代表了一種根本不同的軟件工程方法。
ICS23 遵循更嚴格的設計流程，旨在最大限度地減少攻擊面，同時仍然是通用的，這是一項艱鉅的任務作為其中的一部分，它明確地拒絕了range proofs，ICS23 中並沒有range proofs。
因此，該漏洞本身在ICS23 規範中是不可接受的，這是好的，IBC 的目標是使跨鏈通信更加安全。
當然，IBC 規範和協議可能並不完善，並將繼續改進。作為一個複雜的協議和軟件實現，它（IBC）甚至可能存在我們社區必須應對的尚未被發現的漏洞，安全需要一個社區。
我們都必須認真對待安全。如果發現潛在漏洞，請負責任地披露：https://github.com/cosmos/cosmos-sdk/blob/main/SECURITY.md。
如果你可以為改進軟件和協議做出貢獻，我們邀請你這樣做
總的來說，這次事件是一個機會，它提醒了大家在軟件開發生命週期中加強安全實踐的重要性，傳播一些關於IBC 是什麼及其工作方式的一些認識，並邀請整個生態來幫助改進IBC。
跨鏈橋黑客對我們的行業來說是一個真正的問題，如果不認真致力於更高的安全性和標準流程，它們（跨鏈橋）就不會變得更好。讓IBC 成為一個光輝的例子。
這裡還有一個關於使用開源軟件的重要教訓：遵循最佳實踐，保持最新狀態，並向上游貢獻資源很高興看到binance 成為更負責任和協作的生態參與者
資訊來源：由0x資訊採集自互聯網。版權歸作者“元宇宙之道”所有，未經許可，不得轉載