注意安全風(fēng)險

作者：Beosin

封面：Ronin

8 月 6 日，據(jù)區(qū)塊鏈安全審計公司 Beosin Alert 監(jiān)測顯示，Ronin Bridge 項目出現(xiàn)異常提取跨鏈資產(chǎn)的行為。據(jù) Beosin 安全團隊分析，此次異常行為的根本原因在于項目方升級合約時，未正常初始化配置跨鏈交易確認所需的 operator 權(quán)重，導(dǎo)致合約中的 minimumVoteWeight 參數(shù)為零，從而使得任何人的簽名都能通過跨鏈驗證。

攻擊交易鏈接：

https://etherscan.io/tx/0x2619570088683e6cc3a38d93c3d98899e5783864e15525d5f5810c11189ba6cb

Beosin 目前正與項目方合作處理此次事件，本篇長文，我們也將與大家分析本筆交易存在異常的點在于兩點：

首先，提取數(shù)量過高。在 Ronin Bridge 中，有跨鏈提取額度的限制，如果跨鏈提取的額度太大，則需要轉(zhuǎn)至人工確認，而本次交易的跨鏈資產(chǎn) WETH 的限制額度為 4000。此筆交易提取了 3996 個。當(dāng)然這不是漏洞，但足以讓人引起了注意。

其次，查看這筆提取交易發(fā)現(xiàn)，其跨鏈驗證者 Operator 只有一個，且對應(yīng)的操作權(quán)重為 0，那就可以確認這筆交易是存在問題的，因為在 Ronin Bridge 項目中，用戶提取跨鏈資產(chǎn)需要得到多個 Operator 的簽名，且累計的權(quán)重必須達到指定閾值。

事件分析：

分析鏈上合約和數(shù)據(jù)發(fā)現(xiàn)，合約 Operator 是對應(yīng)的 Manager 合約獨立管理，并且它是一個治理合約，專門用于管理 ronin bridge，查看其交易記錄，發(fā)現(xiàn)最近一筆交易是對 Ronin Bridge 合約進行升級，并且就在異常交易之前。所以漏洞的大致方面就基本明確，應(yīng)該是項目方升級合約所導(dǎo)致的問題。

進一步深入，對比 Ronin Bridge 升級前后的代碼發(fā)現(xiàn)，事件所使用的關(guān)鍵參數(shù) “_totalOperatorWeight” 是本次升級新增的，并且需要在升級中調(diào)用 initializeV3 函數(shù)進行 V3 版本新增的 “OperatorWeight” 進行初始化。

但遺憾的是：升級合約的交易中，并未調(diào)用 initializeV3 函數(shù)，而是錯誤調(diào)用 initializeV4 函數(shù)進行了 V4 版本的初始化。

至此，該事件的漏洞原理已經(jīng)明了，Ronin Bridge 項目方在合約升級時未正確對新增數(shù)據(jù)進行初始化，導(dǎo)致對應(yīng)的關(guān)鍵數(shù)據(jù) “_totalOperatorWeight” 始終為 0，使得任意用戶的提取請求都可以通過審核。

至本文發(fā)布前，項目方已經(jīng)確認該問題，并發(fā)文說了本次攻擊行為是白帽所為，并已進行退款，并未造成過多的損失。這是一個好消息，但是也暴露了合約升級這一大易出錯的點。

可升級合約

可升級合約是一種 solidity 智能合約設(shè)計方案，使得已部署的合約能夠在未來進行升級或修改，而無需完全重新部署。這個概念的核心在于將合約的邏輯和數(shù)據(jù)分離，并利用 “delegatecall” 實現(xiàn)對邏輯合約的調(diào)用。

盡管這種模式提供了靈活的升級能力，我們也必須高度重視其安全性。由于代理合約負責(zé)轉(zhuǎn)發(fā)所有的用戶請求，它實際上成為了合約系統(tǒng)的入口點。任何對代理合約的攻擊都可能影響到整個合約的安全性。因此，在設(shè)計和部署可升級合約時，確保代理模式的安全性至關(guān)重要。目前代理模式的合約需要注意以下幾點：

函數(shù)選擇器沖突

在以太坊虛擬機（EVM）中，每個智能合約函數(shù)都有一個唯一的標識符，稱為函數(shù)選擇器。這個選擇器是函數(shù)簽名的前 4 個字節(jié)的哈希值。函數(shù)選擇器用于確定合約中的具體函數(shù)，確保調(diào)用請求被正確路由到相應(yīng)的函數(shù)實現(xiàn)。而在代理模式在調(diào)用函數(shù)時，會先檢查代理合約中的函數(shù)接口是否能匹配調(diào)用函數(shù)，如果不能匹配，才會利用 fallback 中的 delegatecall 調(diào)用邏輯合約。

因此，如果代理合約和邏輯合約中存在函數(shù)選擇器相同的函數(shù)，當(dāng)代理合約接收到調(diào)用時，它直接調(diào)用代理合約中的函數(shù)，而不是邏輯合約，這可能導(dǎo)致預(yù)期之外的行為或安全漏洞。

存儲沖突

在以太坊虛擬機（EVM）中，合約的狀態(tài)數(shù)據(jù)存儲在特定的存儲槽中，每個存儲槽的地址由其索引（從 0 開始）確定。合約中的每個狀態(tài)變量都對應(yīng)一個存儲槽，數(shù)據(jù)在這些槽中持久化。

在代理模式中，存儲槽通常是由代理合約管理的，而邏輯合約則通過代理合約來訪問這些槽。存儲沖突可能發(fā)生在邏輯合約中新增的狀態(tài)變量與代理合約中現(xiàn)有的狀態(tài)變量槽發(fā)生沖突時。這可能導(dǎo)致代理合約中的數(shù)據(jù)被覆蓋或不一致

合約初始化問題

在代理模式中，由于代理合約和邏輯合約的分離，而每次升級可能都涉及到變量的更改和新增，因此在升級時必須確保在正確設(shè)置這些關(guān)鍵變量。本次的 ronin bridge 事件就是因為這個問題沒做好，導(dǎo)致被攻擊。

此外，需要確保初始化函數(shù) initialize 只能被調(diào)用一次，以防止在初始化后被惡意攻擊者重復(fù)調(diào)用，從而修改關(guān)鍵變量。

ldelegatecall 調(diào)用機制

delegatecall 是一種低級調(diào)用機制，它允許一個合約在其上下文中執(zhí)行另一個合約的代碼。這意味著，調(diào)用合約的存儲、地址和消息發(fā)送者保持不變，但執(zhí)行的邏輯來自被調(diào)用的目標合約。雖 delegatecall 提供了強大的功能，但也需要謹慎使用。

如果目標合約地址不存在，delegatecall 的執(zhí)行將失敗并返回失敗碼，但這種失敗可能不會被立刻發(fā)現(xiàn)。結(jié)果，代理合約中的調(diào)用可能看起來像是成功，但實際操作并未生效，從而導(dǎo)致系統(tǒng)的不一致或錯誤。

代理合約權(quán)限管理

在代理模式中，權(quán)限管理是另一個關(guān)鍵的安全問題。代理模式通過分離代理合約和邏輯合約的職責(zé)，使得合約可以在不改變數(shù)據(jù)存儲的情況下進行升級，但同時也引入了復(fù)雜的權(quán)限管理問題。正確地管理權(quán)限對于保證合約系統(tǒng)的安全性和穩(wěn)定性至關(guān)重要。

免責(zé)聲明：作為區(qū)塊鏈信息平臺，本站所發(fā)布文章僅代表作者及嘉賓個人觀點，與本站立場無關(guān)。文章內(nèi)的信息僅供參考，均不構(gòu)成任何投資建議及要約，并請您遵守所在國家或地區(qū)的相關(guān)法律法規(guī)。