到底哪些安全威脅從發生頻率和危害性上能稱為Top10的呢？ SharkTeam合約安全系列課程之【十大智能合約安全威脅】。
問：我們常提到的智能合約漏洞真的是實際中威脅最大、發生最頻繁的安全漏洞嗎？
答：完全不是那樣。例如“溢出”、“外部調用”等常提到的智能合約安全漏洞並不是最常發生，威脅最大的。
到底哪些安全威脅從發生頻率和危害性上能稱為Top10的呢？ SharkTeam合約安全系列課程之【十大智能合約安全威脅】，第五課【詳解合約升級漏洞】。
一、什麼是合約升級？
智能合約部署後默認是不可變的，一旦你創建了它們，就沒有辦法改變它們。每個智能合約都有一個唯一的地址，用戶將交易發送到智能合約的地址，來執行存儲在該合約中的代碼。但是，在實際應用中，開發者通常因為業務升級或安全升級的需求需要通過技術的手段來更新合約邏輯，因此合約升級的開發模式應運而生。常見的幾種合約升級模式如下。
1.1繼承存儲模式
繼承存儲模式通過為代理合約和邏輯合約所需的狀態變量提供嚴格的存儲順序來解決狀態碰撞問題，代理合約委託邏輯合約進行調用。因此，只有代理合約的存儲在使用。繼承了公共存儲合約的代理合約可以訪問其父合約的所有狀態變量，每個狀態變量根據其索引佔據適當的內存位置。
初始化流程如下：
（1）部署Registry合約
（2）部署合約的初始版本（v1），確保它繼承了“可升級”合約
（3）將初始版本的地址註冊到Registry
（4）請求Registry合約創建UpgradeabilityProxy實例
（5）調用UpgradeabilityProxy來升級到合約的初始版本
升級流程如下：
（1）部署從初始版本繼承的新版本的合約（v2），以確保它保留代理的存儲結構和合約初始版本中的存儲結構
（2）將合約的新版本註冊到Registry
（3）調用UpgradeabilityProxy實例以升級到新的註冊版本
雖然繼承存儲模式解決了可升級合約的存儲碰撞問題，但這種方法也有自己的缺點。由於所有先前聲明的狀態變量都需要被複製到新部署的版本中，因此升級變得昂貴。其中一些可能沒有被使用，最終會不必要地佔用內存。由於公共存儲模式，邏輯合約變得與代理合約緊密耦合。因此，不可能將這些邏輯合約用於不繼承公共存儲合約的任何其他代理。
1.2非結構化存儲模式
在這種模式中，代理合約往往是具有一些基本函數的最小化合約，大部分的業務邏輯都在邏輯合約裡面完成，新的邏輯合約保持了最新的實現合約中存在的狀態變量的順序。代理合約一般需要所有者和實現變量來維持所有權和版本控制，代理合約將這些屬性指定為常量，它們被設置在合約的字節碼內。 OpenZepplin在其可升級的合約服務中使用了非結構化的存儲模式。
初始化流程如下：
（1）部署OwnedUpgradeabilityProxy實例
（2）部署合約的初始版本（v1）
（3）調用OwnedUpgradeabilityProxy實例來升級到初始版本的地址
（4）如果邏輯合約依賴它的構造函數來設置一些初始狀態，那麼在它與代理鏈接後，就必須重新進行設置，因為代理的存儲不知道這些值。 OwnedUpgradeabilityProxy有一個函數upgradeToAndCall，專門用來調用邏輯合約上的一些函數，在代理升級到它之後重新進行設置
升級流程如下：
（1）部署新版本的合約（v2），確保它繼承以前版本中使用的狀態變量結構
（2）調用OwnedUpgradeabilityProxy實例來升級到新合約版本的地址
1.3永久存儲模式
這種模式的目標是盡量減少存儲複製的要求。在這種模式中，一個單獨的合約被維護為永久存儲合約。因此，所有的邏輯版本都利用這個永久存儲合約來滿足其存儲需求。因此，存儲複製的要求被從升級模式中移除，這種方法大大降低了升級成本。
初始化流程如下：
（1）部署一個EternalStorageProxy實例
（2）部署一個初始版本的合約（v1）
（3）調用EternalStorageProxy實例來升級到初始版本的地址
（4）如果邏輯合約依賴其構造函數來設置一些初始狀態，那就必須在其鏈接到代理後重新進行，因為代理的存儲不知道這些值。 EternalStorageProxy有一個函數upgradeToAndCall，專門用來調用邏輯合約上的一些函數，在代理升級到它之後重新進行設置
升級流程如下：
（1）部署一個新版本的合約（v2），確保它擁有永久存儲結構
（2）調用EternalStorageProxy實例來升級到新版本
1.4Diamond 模式
Solidity 合約的最大限制為24KB。因此，每個合約的大小永遠不能超過24KB。 Diamond 模式使開發人員能夠編寫沒有大小限制的智能合約。此模式還支持升級，而無需重新部署現有功能，詳細Diamond 標準可見EIP 2535。
Diamond 是一個合約，它將調用委託給稱為面的實現合約。 Diamond 合約實現了一個diamondCut 函數，它提供了添加/替換/刪除的能力。除了diamondCut 函數之外，還實現了一組loupe 函數。這些函數顯示了關於所實現的Diamond 的信息。 Diamond 合約維護了一個selectorToFacet的映射，這基本上是一個函數簽名到實現合約地址的映射。當用戶調用一個函數時，Diamond 代理的回退函數使用函數簽名來尋找這個映射中的實現地址。在找到函數簽名的地址後，回退函數只是將調用委託給實現合約，並將響應返回給用戶。
Diamond 代理依靠的是一種存儲模式。該代理被一些被稱為面的實現合約所共享。理想情況下，每個切面都有自己的存儲。然而，根據實施要求，面可以與其他面共享存儲。 DiamondStorage和AppStorage是一些流行的存儲模式，分別用於隔離和共享存儲。
Diamond 模式為創建模塊化的智能合約應用程序提供了一種簡潔的方式，沒有任何最大尺寸限制。因此，它似乎是那些希望在未來擴大規模的大型智能合約應用程序的完美選擇。
1.5 create2
create操作碼用於在以太坊區塊鏈上部署合約。合約地址是通過散列部署者的地址和該地址的nonce來生成的。 Nonce是一個標量值，等於從部署者的地址發送的交易數量。同樣，在合約賬戶的情況下，nonce是該賬戶創建合約的數量。 nonce有助於保持交易的順序（來自一個地址的低nonce交易會先被開採），並防止重入攻擊。 nonce是一個遞增的數字，防止create操作碼產生重複的地址。只要在當前和下一個nonce之間沒有新的交易發生，就有可能通過簡單散列下一個nonce和地址來知道下一個合約的地址。
create2操作碼被添加到以太坊虛擬機中，作為君士坦丁堡硬分叉的一部分，這個操作碼也被用來部署智能合約。 create2使用一些用戶控制的輸入來推導出智能合約的地址。換句話說，這個操作碼提供了一種方法，在將智能合約部署到區塊鏈之前計算其地址。這個操作碼不是對部署者的地址和nonce進行散列，而是對部署者的地址、salt（由部署者提供的32字節的字符串）和合約的字節碼的哈希進行散列。由於這個操作碼的所有參數都由用戶控制，create2提供了一種預先確定合約地址的方法。這個方法在推導出優化gas的合約地址和實現像狀態通道這樣的擴展解決方案時非常有用。在可升級性方面，create2提供了創建可變合約（metamorphic contract）的能力，這些合約可以用新的字節碼重新部署到同一地址。
EVM包含一個selfdestruct 操作碼，智能合約可以通過這個操作碼來刪除。為了在原始地址上部署一個新的字節碼，該地址必須是自由的，因為智能合約是不可改變的。有幾種方法可以將新的字節碼部署到原始地址上，一個低效的方法是找到salt的參數，與新的字節碼相結合，生成原始地址，尋找正確的salt參數的計算可以在鏈下完成。然而，這並不是一個很好的方法。另一個選擇是部署一個可變合約。如上所述，可變合約可以使用不同的字節碼重新部署到原始地址。
建立一個良好的升級模式，需要一個可變合約工廠。這個可變合約工廠的目的是通過改變其實現而不改變其地址來促進升級。在部署合約時，對應的部署函數使用create2預先計算可變合約的地址，實現合約是使用傳統的create操作碼部署的。這個操作碼使用地址和nonce來生成地址，並將合約部署到該地址。要求實現地址不能為零。否則，實現合約沒有被正確部署，函數必須返回。部署完實現合約後，工廠狀態被更新來存儲當前的實現合約。
值得注意的是，實現合約必須是自毀的，這也會使可變合約自毀。在重新部署可變合約之前，要確保可變合約使用selfdestruct操作碼進行自我銷毀。由於create2操作碼的存在，可變合約的地址總是提前知道的。此外，由於它能夠改變其實現，可變合約每次都可以用不同的實現重新部署。
使用create2是有優勢的，但它也有自己的風險。最重要的風險是，每次合約被重新部署時，其存儲都會被抹去。另外，帶有selfdestruct操作碼的實現合約可能不是一個可靠的資金存儲方式。因此，在採用這種智能合約升級模式之前，開發者必須謹慎行事。
二、攻擊事件分析
2.1 Uranium Finance
2021年4月28日，幣安智能鏈上區塊鏈項目Uranium Finance在流動性遷移過程中被攻擊，涉及資金為5000 萬美元。攻擊合約地址：0x2b528a28451e9853F51616f3B0f6D82Af8bEA6Ae。
我們從攻擊合約中找到的項目合約地址並進行了攻擊原理分析，攻擊流程如下：
（1）首先查看攻擊合約的代碼發現，這個合約的源碼沒有公開，通過反編譯查看其源碼
（2）通過瀏覽器查看最早的攻擊交易
0x5a504fe72ef7fc76dfeb4d979e533af4e23fe37e90b5516186d5787893c37991,可得到攻擊者調用的合約方法對應的簽名為52f18fc3
（3）從反編譯代碼中尋找這個編碼後的合約方法，可以找到這個合約攻擊的項目方合約地址，也就是Uranium 項目所在的地址：0xa943ea143cd7e79806d670f4a7cf08f8922a454f
（4）通過分析，Uranium 項目合約中的漏洞出現在UraniumPair.sol 合約中的swap 函數中，這個漏洞會導致任何人可以隨意的轉出合約中的數字資產，而只需要付出一點點的代價。可以看到swap 中，最後是一個10的8次方數和一個10的6次方數的比較，這是一個幾乎是恆等的判斷，這就意味著只要按照一定的套路不斷的執行swap 函數，就可以清空這個合約中所有的數字資產。
我們看到UniswapV2Pair.sol的合約中的寫法是相同的，但是它是兩個10的6次方數字的比較。
問題分析：造成這次事件的原因應該是項目方更新升級這個合約的時候，忘記了將後面的1000的2次方改為10000的二次方。
2.2 Audius
2022年7月24日，黑客從音樂流媒體協議Audius轉移了1800萬個AUDIO代幣。攻擊者發起了兩次攻擊，其中第一次攻擊失敗，第二次攻擊成功。我們主要來分析第二次攻擊，攻擊者在創建了攻擊合約後，通過攻擊合約發起了攻擊，包含4筆交易：
（1）txHash1: 0xfefd829e246002a8fd061eede7501bccb6e244a9aacea0ebceaecef5d877a984
（2）txHash2: 0x3c09c6306b67737227edc24c663462d870e7c2bf39e9ab66877a980c900dd5d5
（3）txHash3: 0x4227bca8ed4b8915c7eec0e14ad3748a88c4371d4176e716e8007249b9980dc9
（4）txHash4: 0x82fc23992c7433fffad0e28a1b8d11211dc4377de83e88088d79f24f4a3f28b3
在txHash1中，主要交易流程如下：
（1）通過Audius的代理合約對Governance合約進行初始化
（2）評估/執行84號提案，即第一次攻擊提交的提案，評估為QuorumNotMet，原因是沒有投票
（3）查詢Governance代理合約的AUDIO代幣餘額
（4）提交85號提案，與84號提案相同。該提案的功能就是將Governance代理合約中的AUDIO轉移到攻擊合約，數量不能超過Governance代理合約的AUDIO餘額
（5）通過代理合約對Staking合約進行初始化，將治理代幣地址以及代理合約地址都設置為攻擊合約
（6）通過代理合約對DelegateManagerV2合約進行初始化，將治理代幣地址以及代理治理地址都設置為攻擊合約
（7）通過代理合約將DelegateManagerV2合約中的服務提供者工廠合約為攻擊合約
（8）通過代理合約將質押的代理權授權給攻擊合約，授權的代幣數量為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。
三、預防措施
我們了解合約升級的幾種模式以及回顧了相關攻擊事件後，作為開發人員應該採取哪些適當的措施來防止相關攻擊？
（1）可升級智能合約的真正問題是從合約中遷移存儲值，構建可升級智能合約的更好方法是區分不同合約中的存儲和邏輯，將合約數據保存在一個僅接受來自邏輯合約調用的合約中，不斷改變邏輯合約的邏輯
（2）在調用delegatecall 之前檢查目標合約是否存在，Solidity 不會替我們執行此檢查，忽略檢查可能會導致意外行為和安全問題
（3）仔細考慮變量聲明的順序，因為會出現變量打包存儲同一個插槽、影響gas成本、內存佈局、delegate調用結果等問題
（4）仔細考慮合約初始化問題，狀態變量可能在構造時候出現未初始化，應當在初始化期間緩解潛在的競爭條件
（5）考慮代理模式中的函數名稱，避免函數名稱衝突
（6）項目上線前，需聯繫專業的第三方專業審計團隊進行審計
展開全文打開碳鏈價值APP 查看更多精彩資訊
