NCE:一文詳解十大智能合約安全威脅之合約升級漏洞_OxyO2

問：我們常提到的智能合約漏洞真的是實際中威脅最大、發生最頻繁的安全漏洞嗎？

答：完全不是那樣。例如“溢出”、“外部調用”等常提到的智能合約安全漏洞并不是最常發生，威脅最大的。

到底哪些安全威脅從發生頻率和危害性上能稱為Top10的呢？SharkTeam合約安全系列課程之，第五課。

一、什么是合約升級？

智能合約部署后默認是不可變的，一旦你創建了它們，就沒有辦法改變它們。每個智能合約都有一個唯一的地址，用戶將交易發送到智能合約的地址，來執行存儲在該合約中的代碼。但是，在實際應用中，開發者通常因為業務升級或安全升級的需求需要通過技術的手段來更新合約邏輯，因此合約升級的開發模式應運而生。常見的幾種合約升級模式如下。

1.1繼承存儲模式

繼承存儲模式通過為代理合約和邏輯合約所需的狀態變量提供嚴格的存儲順序來解決狀態碰撞問題，代理合約委托邏輯合約進行調用。因此，只有代理合約的存儲在使用。繼承了公共存儲合約的代理合約可以訪問其父合約的所有狀態變量，每個狀態變量根據其索引占據適當的內存位置。

初始化流程如下：

部署Registry合約

部署合約的初始版本，確保它繼承了“可升級”合約

將初始版本的地址注冊到Registry

請求Registry合約創建UpgradeabilityProxy實例

調用UpgradeabilityProxy來升級到合約的初始版本

升級流程如下：

部署從初始版本繼承的新版本的合約，以確保它保留代理的存儲結構和合約初始版本中的存儲結構

將合約的新版本注冊到Registry

調用UpgradeabilityProxy實例以升級到新的注冊版本

雖然繼承存儲模式解決了可升級合約的存儲碰撞問題，但這種方法也有自己的缺點。由于所有先前聲明的狀態變量都需要被復制到新部署的版本中，因此升級變得昂貴。其中一些可能沒有被使用，最終會不必要地占用內存。由于公共存儲模式，邏輯合約變得與代理合約緊密耦合。因此，不可能將這些邏輯合約用于不繼承公共存儲合約的任何其他代理。

Composable Finance首席技術官宣布離職:金色財經報道，Composable Finance首席技術官Karel Kubat表示，由于缺乏透明度，以及存在的 \"可疑交易\"，他將離開公司。

他補充說，該公司的 \"財務報表沒有提供給我或社區。社區和我目前對Composable Finance的財務健康狀況沒有任何了解。\"在另一條推文中，Kubat說，\"執行法律是由當局決定的。然而，我們是一個去中心化的社區，簡單的、不道德的管理足以讓我離開。\"[2023/2/21 12:18:38]

1.2非結構化存儲模式

在這種模式中，代理合約往往是具有一些基本函數的最小化合約，大部分的業務邏輯都在邏輯合約里面完成，新的邏輯合約保持了最新的實現合約中存在的狀態變量的順序。代理合約一般需要所有者和實現變量來維持所有權和版本控制，代理合約將這些屬性指定為常量，它們被設置在合約的字節碼內。OpenZepplin在其可升級的合約服務中使用了非結構化的存儲模式。

初始化流程如下：

部署OwnedUpgradeabilityProxy實例

部署合約的初始版本

調用OwnedUpgradeabilityProxy實例來升級到初始版本的地址

如果邏輯合約依賴它的構造函數來設置一些初始狀態，那么在它與代理鏈接后，就必須重新進行設置，因為代理的存儲不知道這些值。OwnedUpgradeabilityProxy有一個函數upgradeToAndCall，專門用來調用邏輯合約上的一些函數，在代理升級到它之后重新進行設置

升級流程如下：

部署新版本的合約，確保它繼承以前版本中使用的狀態變量結構

調用OwnedUpgradeabilityProxy實例來升級到新合約版本的地址

1.3永久存儲模式

這種模式的目標是盡量減少存儲復制的要求。在這種模式中，一個單獨的合約被維護為永久存儲合約。因此，所有的邏輯版本都利用這個永久存儲合約來滿足其存儲需求。因此，存儲復制的要求被從升級模式中移除，這種方法大大降低了升級成本。

zkSync：非常接近Fair Onboarding Alpha階段，但首先需在zkSync 2.0主網上運行一次重置:2月14日消息，zkSync發推稱，目前已經非常接近Fair Onboarding Alpha階段，不過首先需要在zkSync 2.0主網上運行一次重置（regenesis），因為系統在此測試階段只對其核心團隊開放，用戶和項目不會受到影響。

Fair Onboarding Alpha允許開發者在封閉環境中測試其代碼，新的費用模型可以確保交易和區塊擴容考慮系統整體成本，改善證明生成性能并修復所有審計發現。[2023/2/14 12:06:26]

初始化流程如下：

部署一個EternalStorageProxy實例

部署一個初始版本的合約

調用EternalStorageProxy實例來升級到初始版本的地址

如果邏輯合約依賴其構造函數來設置一些初始狀態，那就必須在其鏈接到代理后重新進行，因為代理的存儲不知道這些值。EternalStorageProxy有一個函數upgradeToAndCall，專門用來調用邏輯合約上的一些函數，在代理升級到它之后重新進行設置

升級流程如下：

部署一個新版本的合約，確保它擁有永久存儲結構

調用EternalStorageProxy實例來升級到新版本

1.4Diamond模式

Solidity合約的最大限制為24KB。因此，每個合約的大小永遠不能超過24KB。Diamond模式使開發人員能夠編寫沒有大小限制的智能合約。此模式還支持升級，而無需重新部署現有功能，詳細Diamond標準可見EIP2535。

Diamond是一個合約，它將調用委托給稱為面的實現合約。Diamond合約實現了一個diamondCut函數，它提供了添加/替換/刪除的能力。除了diamondCut函數之外，還實現了一組loupe函數。這些函數顯示了關于所實現的Diamond的信息。Diamond合約維護了一個selectorToFacet的映射，這基本上是一個函數簽名到實現合約地址的映射。當用戶調用一個函數時，Diamond代理的回退函數使用函數簽名來尋找這個映射中的實現地址。在找到函數簽名的地址后，回退函數只是將調用委托給實現合約，并將響應返回給用戶。

Diamond代理依靠的是一種存儲模式。該代理被一些被稱為面的實現合約所共享。理想情況下，每個切面都有自己的存儲。然而，根據實施要求，面可以與其他面共享存儲。DiamondStorage和AppStorage是一些流行的存儲模式，分別用于隔離和共享存儲。

LooksRare原生代幣LOOKS將于2023年1月2日13:00解鎖總供應量的3.75%:12月29日消息，據TokenUnlocks數據，LooksRare原生代幣LOOKS將于2023年1月2日13:00進行一次小額解鎖，解鎖量為3750萬枚LOOKS，占總供應量（10億）的3.75%，約合552萬美元。解鎖的代幣中，包括團隊2500萬枚，財庫1250萬枚。[2022/12/29 22:14:45]

Diamond模式為創建模塊化的智能合約應用程序提供了一種簡潔的方式，沒有任何最大尺寸限制。因此，它似乎是那些希望在未來擴大規模的大型智能合約應用程序的完美選擇。

1.5create2

create操作碼用于在以太坊區塊鏈上部署合約。合約地址是通過散列部署者的地址和該地址的nonce來生成的。Nonce是一個標量值，等于從部署者的地址發送的交易數量。同樣，在合約賬戶的情況下，nonce是該賬戶創建合約的數量。nonce有助于保持交易的順序，并防止重入攻擊。nonce是一個遞增的數字，防止create操作碼產生重復的地址。只要在當前和下一個nonce之間沒有新的交易發生，就有可能通過簡單散列下一個nonce和地址來知道下一個合約的地址。

create2操作碼被添加到以太坊虛擬機中，作為君士坦丁堡硬分叉的一部分，這個操作碼也被用來部署智能合約。create2使用一些用戶控制的輸入來推導出智能合約的地址。換句話說，這個操作碼提供了一種方法，在將智能合約部署到區塊鏈之前計算其地址。這個操作碼不是對部署者的地址和nonce進行散列，而是對部署者的地址、salt和合約的字節碼的哈希進行散列。由于這個操作碼的所有參數都由用戶控制，create2提供了一種預先確定合約地址的方法。這個方法在推導出優化gas的合約地址和實現像狀態通道這樣的擴展解決方案時非常有用。在可升級性方面，create2提供了創建可變合約的能力，這些合約可以用新的字節碼重新部署到同一地址。

EVM包含一個selfdestruct操作碼，智能合約可以通過這個操作碼來刪除。為了在原始地址上部署一個新的字節碼，該地址必須是自由的，因為智能合約是不可改變的。有幾種方法可以將新的字節碼部署到原始地址上，一個低效的方法是找到salt的參數，與新的字節碼相結合，生成原始地址，尋找正確的salt參數的計算可以在鏈下完成。然而，這并不是一個很好的方法。另一個選擇是部署一個可變合約。如上所述，可變合約可以使用不同的字節碼重新部署到原始地址。

NEAR將把wallet.near.org轉變為所有兼容錢包的登錄頁面:7月30日消息，NEAR計劃將wallet.near.org轉變為所有兼容NEAR的錢包的登錄頁面，并鼓勵wallet.near.org上的錢包持有者將其錢包遷移到新的提供商，基金會將在未來幾周內發布一系列關于相應教程和指南。[2022/7/30 2:47:33]

建立一個良好的升級模式，需要一個可變合約工廠。這個可變合約工廠的目的是通過改變其實現而不改變其地址來促進升級。在部署合約時，對應的部署函數使用create2預先計算可變合約的地址，實現合約是使用傳統的create操作碼部署的。這個操作碼使用地址和nonce來生成地址，并將合約部署到該地址。要求實現地址不能為零。否則，實現合約沒有被正確部署，函數必須返回。部署完實現合約后，工廠狀態被更新來存儲當前的實現合約。

值得注意的是，實現合約必須是自毀的，這也會使可變合約自毀。在重新部署可變合約之前，要確保可變合約使用selfdestruct操作碼進行自我銷毀。由于create2操作碼的存在，可變合約的地址總是提前知道的。此外，由于它能夠改變其實現，可變合約每次都可以用不同的實現重新部署。

使用create2是有優勢的，但它也有自己的風險。最重要的風險是，每次合約被重新部署時，其存儲都會被抹去。另外，帶有selfdestruct操作碼的實現合約可能不是一個可靠的資金存儲方式。因此，在采用這種智能合約升級模式之前，開發者必須謹慎行事。

二、攻擊事件分析

2.1UraniumFinance

2021年4月28日，幣安智能鏈上區塊鏈項目UraniumFinance在流動性遷移過程中被攻擊，涉及資金為5000萬美元。攻擊合約地址：0x2b528a28451e9853F51616f3B0f6D82Af8bEA6Ae。

我們從攻擊合約中找到的項目合約地址并進行了攻擊原理分析，攻擊流程如下：

首先查看攻擊合約的代碼發現，這個合約的源碼沒有公開，通過反編譯查看其源碼

通過瀏覽器查看最早的攻擊交易

0x5a504fe72ef7fc76dfeb4d979e533af4e23fe37e90b5516186d5787893c37991,可得到攻擊者調用的合約方法對應的簽名為52f18fc3

BNB 實時銷毀量突破 10 萬枚:金色財經消息，據BNBBurn.info顯示，BNB 實時銷毀量突破 10 萬枚，當前達 100,145.59 枚。BNB 的實時銷毀機制由 BEP95 提出，類似以太坊當前的銷毀機制。[2022/7/5 1:52:51]

從反編譯代碼中尋找這個編碼后的合約方法，可以找到這個合約攻擊的項目方合約地址，也就是Uranium項目所在的地址：0xa943ea143cd7e79806d670f4a7cf08f8922a454f

通過分析，Uranium項目合約中的漏洞出現在UraniumPair.sol合約中的swap函數中，這個漏洞會導致任何人可以隨意的轉出合約中的數字資產，而只需要付出一點點的代價。可以看到swap中，最后是一個10的8次方數和一個10的6次方數的比較，這是一個幾乎是恒等的判斷，這就意味著只要按照一定的套路不斷的執行swap函數，就可以清空這個合約中所有的數字資產。

我們看到UniswapV2Pair.sol的合約中的寫法是相同的，但是它是兩個10的6次方數字的比較。

問題分析：造成這次事件的原因應該是項目方更新升級這個合約的時候，忘記了將后面的1000的2次方改為10000的二次方。

2.2Audius

2022年7月24日，黑客從音樂流媒體協議Audius轉移了1800萬個AUDIO代幣。攻擊者發起了兩次攻擊，其中第一次攻擊失敗，第二次攻擊成功。我們主要來分析第二次攻擊，攻擊者在創建了攻擊合約后，通過攻擊合約發起了攻擊，包含4筆交易：

txHash1:0xfefd829e246002a8fd061eede7501bccb6e244a9aacea0ebceaecef5d877a984

txHash2:0x3c09c6306b67737227edc24c663462d870e7c2bf39e9ab66877a980c900dd5d5

txHash3:0x4227bca8ed4b8915c7eec0e14ad3748a88c4371d4176e716e8007249b9980dc9

txHash4:0x82fc23992c7433fffad0e28a1b8d11211dc4377de83e88088d79f24f4a3f28b3

在txHash1中，主要交易流程如下：

通過Audius的代理合約對Governance合約進行初始化

評估/執行84號提案，即第一次攻擊提交的提案，評估為QuorumNotMet，原因是沒有投票

查詢Governance代理合約的AUDIO代幣余額

提交85號提案，與84號提案相同。該提案的功能就是將Governance代理合約中的AUDIO轉移到攻擊合約，數量不能超過Governance代理合約的AUDIO余額

通過代理合約對Staking合約進行初始化，將治理代幣地址以及代理合約地址都設置為攻擊合約

通過代理合約對DelegateManagerV2合約進行初始化，將治理代幣地址以及代理治理地址都設置為攻擊合約

通過代理合約將DelegateManagerV2合約中的服務提供者工廠合約為攻擊合約

通過代理合約將質押的代理權授權給攻擊合約，授權的代幣數量為1e31

通過以上步驟，攻擊者篡改并獲取了治理系統的最高權限。

在txHash2中，攻擊者在提交了提案85之后的3個區塊內進行了投票。

在txHash3中，攻擊者在3個區塊的投票期以及1個區塊的等待期之后對提案85進行了評估/執行。

在txHash4中，執行提案85，將18,56萬枚AUDIO轉移到攻擊合約，攻擊合約收到1800萬枚AUDIO后，將其兌換為704枚ETH。

最后，攻擊者將兌換的ETH存入到了Tornash平臺。

問題分析：攻擊者之所以能夠攻擊成功，根本原因在于通過代理合約多次調用初始化函數，而初始化函數本應該只能調用一次的。以Governance合約中的初始化函數為例，其代碼如下：

這里使用了Openzeppelin里面的初始化器initializer，initializer沒有起到任何作用，原因在于代理調用。

Openzeppelin里面的初始化器initializer中定義的兩個bool類型的狀態變量initialized和intializing分別占用了存儲插槽slot0中的前16個字節。第1個8字節為initialized，第2個8字節為initializing。

由于代理合約本身定義了一個地址類型的狀態變量proxyAdmin，其值為0x80ab62886eacfebca74511823d4699eb88fd097e，同樣占用了存儲插槽slot0，第1個8字節為0，第2個8字節為0x80ab6288，第3個8字節為0x6eacfebca7451182，第4個8字節為0x3d4699eb88fd097e。于是，實現合約中的initialized和intializing與代理合約中的proxyAdmin同時占用了存儲插槽slot0，從而引起了存儲沖突。

插槽0中的數據分布如下：

初始化函數執行到initializer時，從存儲插槽slot0的第1個8字節讀取initialized，其值為0，即false；從存儲插槽slot0的第2個8字節讀取initializing，其值為0x80ab6288>0，即true。

三、預防措施

我們了解合約升級的幾種模式以及回顧了相關攻擊事件后，作為開發人員應該采取哪些適當的措施來防止相關攻擊？

可升級智能合約的真正問題是從合約中遷移存儲值，構建可升級智能合約的更好方法是區分不同合約中的存儲和邏輯，將合約數據保存在一個僅接受來自邏輯合約調用的合約中，不斷改變邏輯合約的邏輯

在調用delegatecall之前檢查目標合約是否存在，Solidity不會替我們執行此檢查，忽略檢查可能會導致意外行為和安全問題

仔細考慮變量聲明的順序，因為會出現變量打包存儲同一個插槽、影響gas成本、內存布局、delegate調用結果等問題

仔細考慮合約初始化問題，狀態變量可能在構造時候出現未初始化，應當在初始化期間緩解潛在的競爭條件

考慮代理模式中的函數名稱，避免函數名稱沖突

項目上線前，需聯系專業的第三方專業審計團隊進行審計

來源：金色財經

Tags：NCEAMOProxyOXYStrongHands FinanceSAMOProxyNodeOxyO2

幣贏交易所