跨鏈橋：Web3黑客必爭之地
跨鏈橋，區(qū)塊鏈的基礎設施之一，所實現(xiàn)的功能是允許用戶將自己的資產從一條鏈轉移至另外一條鏈上，是連接不同的區(qū)塊鏈的關鍵橋梁，常使用中心化的方式進行實現(xiàn)。由于跨鏈橋自身往往存儲有用戶所質押的巨額資產，是Web3黑客最熱衷于攻擊的目標之一。
近年來，與跨鏈橋相關的攻擊與漏洞屢見不鮮，本文將詳述Harmony跨鏈橋黑客攻擊事件和Wormhole代理合約未初始化漏洞。
Harmony跨鏈橋黑客攻擊事件
2022年6月23日，Harmony鏈與以太坊間的跨鏈橋上發(fā)生了惡意攻擊，攻擊者控制了跨鏈橋所有者的私鑰后，直接使用管理員權限通過特權函數(shù)轉移走了該橋所持有的大量各類代幣，導致Harmony鏈上價值約9700萬美元的資產被盜。
該跨鏈橋由一個多簽錢包所控制，其本意是通過要求至少有N位管理員的授權才能執(zhí)行操作，來提高錢包的安全性和攻擊門檻，在實際代碼實現(xiàn)中N=2。
多簽錢包實現(xiàn)為一個合約MultiSigWallet.sol，其中能夠處理資產轉移的函數(shù)executeTransaction()?本身帶有confirmed(transactionId, msg.sender)?校驗，需要2位不同的owner依次調用submitTransaction、confirmTransaction兩函數(shù)，才能通過操作權限校驗，以多簽錢包身份發(fā)起資產轉移等任意操作。
多簽錢包地址：
https://etherscan.io/address/0x715CdDa5e9Ad30A0cEd14940F9997EE611496De6
external_call(
txn.destination,
txn.value,
txn.data.length,
txn.data
)
) emit Execution(transactionId);
else {
emit ExecutionFailure(transactionId);
txn.executed = false;
}
}
}
https://etherscan.io/address/0x715CdDa5e9Ad30A0cEd14940F9997EE611496De6#code
MultiSigWallet.sol
于是，保證這些owner私鑰的保密性是Harmony跨鏈橋的安全瓶頸之一。
從目前證據來看，攻擊者可能通過其他鏈下攻擊手段控制了多簽錢包中的2個所有者私鑰，成為了事實上的橋的所有者，通過這些權限校驗都已經不在話下。攻擊者可以正常地使用所有者權限進行資產的管理，包括將所有資產轉移至攻擊者賬戶中。
實際發(fā)生的資產轉移交易https://etherscan.io/tokentxns?a=0x0d043128146654c7683fbf30ac98d7b2285ded00
小結
在由密碼學為基礎建構起的區(qū)塊鏈世界中，沒有什么比確保私鑰自身的保密性更加重要的事情了，私鑰泄漏是最無解、同時也是危害最大的安全隱患。跨鏈橋的開發(fā)者需要注意項目本身中心化的風險，確保項目所私用的私鑰的安全性。同時，區(qū)塊鏈的每一個使用者也都必須清楚地明白：道路千萬條、私鑰保密第一條。
Wormhole代理合約未初始化漏洞
2022年2月24日，匿名白帽子黑客satya0x負責任地披露了Wormhole主橋（以太坊側）的一個代理合約未初始化漏洞，一舉拿下Web3漏洞賞金平臺immunefi有史以來單筆最高的漏洞賞金：一千萬美元。看到這一數(shù)字的讀者朋友們想必會不由得發(fā)問：究竟是如何逆天的漏洞才能夠收割這筆天價賞金？
據長亭科技區(qū)塊鏈安全研究員分析，該漏洞是Wormhole跨鏈項目以太坊側代理合約未初始化而導致的漏洞，黑客可以通過提前控制代理合約背后的實際實現(xiàn)合約，并調用更新函數(shù)迫使實現(xiàn)合約自毀，使得Wormhole項目所有的以太幣都被凍結在原地址中，用戶已經轉移至Wormhole的資產也將會被永久凍結、再也無法取出。
根據國家區(qū)塊鏈漏洞庫區(qū)塊鏈漏洞定級細則中智能合約漏洞定級細則v1.0，該漏洞會使得智能合約核心業(yè)務無法正常運行，造成他人資產大額凍結，在危害程度上劃分為嚴重危害；同時利用成本較低，無特殊利用門檻，且漏洞可穩(wěn)定觸發(fā)，在利用難度上劃分為低難度。綜合這兩個因素考慮，該漏洞定級為高危漏洞。
目前漏洞已修復，我們現(xiàn)在討論一下本次wormhole漏洞的原理。
漏洞合約地址：https://etherscan.io/address/0x736d2a394f7810c17b3c6fed017d5bc7d60c077d
什么是Wormhole
Wormhole跨鏈協(xié)議是連接solana和以太坊的橋，通過Wormhole，DeFi項目可以避開以太坊的擁堵和高費用，并享受Solana的低費用和高吞吐量、快速的交易體驗。
——Solana Wormhole 項目主頁
從Wormhole項目的介紹中我們可以知道，Wormhole是連接兩條相互不兼容的公鏈：以太坊和Solana的一個協(xié)議，在以太坊和Solana上都部署有合約程序，在以太坊上運行的程序稱為以太坊智能合約，在Solana上運行的程序稱為Solana program，兩個分別運行于不同公鏈的程序需要共同發(fā)揮作用，完成用戶的資產跨鏈請求。本次代理合約未初始化漏洞發(fā)生在Wormhole項目的以太坊智能合約中。
什么是以太坊智能合約
以太坊(Ethereum)是目前最廣為人知的公鏈系統(tǒng)，其原生貨幣以太幣是市值第二的加密貨幣。以太坊智能合約是運行于以太坊EVM(Ethereum Virtual Machine)之上的程序。以太坊智能合約的主要功能是實現(xiàn)各類資產管理的功能。初次接觸智能合約一詞的讀者可以在概念上直接將智能合約理解為Java編寫的程序，在Java虛擬機（類比EVM）內運行。
以太坊的一大特色是一個智能合約程序一旦部署上鏈后將再也無法對其代碼邏輯進行修改，換句話說，一個運行中的以太坊智能合約的代碼邏輯是不可更新的。
使用代理合約進行合約更新
以太坊的智能合約在部署后不可更改，使得開發(fā)者在發(fā)現(xiàn)安全漏洞后如何更新自己的智能合約代碼成了一個問題。不過，也不是完全無法實現(xiàn)智能合約的代碼更新，通過一個特殊的以太坊EVM調用：Delegatecall，一個以太坊程序可以間接實現(xiàn)智能合約代碼的更新。
以太坊智能合約使用代碼與存儲耦合的編程模型，換句話說，一個合約的代碼邏輯和合約的數(shù)據存儲都是存放在同一個地址上的，一個合約只能夠通過自己地址上存儲的代碼邏輯去修改自己地址上的數(shù)據存儲。
但情況并不總是如此。以太坊智能合約在相互調用時除了最常用最普通的Call調用之外，還有一種特殊的調用方式：Delegatecall，實現(xiàn)了智能合約代碼和智能合約存儲的分離，也就是說，用別人的代碼來修改自己的數(shù)據存儲。
合約間普通CALL，如下左圖所示：A合約CALL調用了B合約，B合約的程序邏輯運行在B合約地址的數(shù)據存儲中，所讀取與修改的數(shù)據均為屬于B地址的數(shù)據。
合約間委托調用DELEGATECALL，如下右圖所示：A合約委托調用DELEGATECALL調用了B合約，運行的程序代碼仍為B的代碼，但是與CALL根本性的不同是所有的代碼都是運行在A的上下文中的，使用DELEGATECALL時B的代碼修改的是調用者A的數(shù)據存儲狀態(tài)。
可以看到，使用Delegatecall可以運行B的合約代碼而修改A的合約存儲，利用這一特性能夠自然地實現(xiàn)合約的升級。此時，合約A為代理合約（Proxy），合約B為實現(xiàn)合約（Implementation），每次合約調用，都由代理合約A將實際的調用參數(shù)使用Delegatecall傳遞給合約A的數(shù)據存儲中所指定的實現(xiàn)合約B，由B的合約代碼來修改合約A的數(shù)據存儲。當實現(xiàn)合約B的代碼發(fā)現(xiàn)了嚴重漏洞需要升級時，將合約A的數(shù)據存儲中所指定的實現(xiàn)合約從B更改為新的B‘，這樣就實現(xiàn)了合約的升級，原現(xiàn)的合約B雖然仍舊在鏈上保存著，但是實際上已經被廢棄，代理合約不會再將調用轉發(fā)到B合約上。而原本B運行所需要的數(shù)據本來就都存儲在A中，可以無縫地被新合約B’繼續(xù)繼承使用。
以上就是實現(xiàn)智能合約代碼升級的基本原理，目前以太坊社區(qū)有兩種主流的通過代理合約實現(xiàn)智能合約升級的標準：Transparent Proxy Pattern (TPP)和Universal Upgradeable Proxy Standard (UUPS)。
- 透明代理模式(TPP)中代理合約A內會實現(xiàn)合約升級相關的邏輯，缺點是開銷大、無法調用代理合約與實現(xiàn)合約中同名的函數(shù)。
- 通用可升級代理標準 (UUPS) 中代理合約A被EIP-1822標準所統(tǒng)一，不實現(xiàn)任何邏輯，僅僅是將所有調用DELEGATECALL至目標合約，更新的邏輯也實現(xiàn)在目標合約中。
本文一開始所提到的Wormhole協(xié)議使用的是第二種UUPS模式。
UUPS代理合約模式
UUPS模式中代理合約A不實現(xiàn)任何邏輯，所有的合約都在實現(xiàn)合約B中由開發(fā)者自行實現(xiàn)，最主要的功能包括：合約初始化邏輯與合約更新邏輯。
contract Implementation { // 實際合約 B
address public upgrader;
// 初始化邏輯：設置管理員賬號
function initialize() external onlyonce {
upgrader = msg.sender;
}
// 更新邏輯
function upgradeToAndCall(address newImplementation) external {
authorizeUpgrade(); // 鑒權
setImplementation(newImplementation); // 設置新的實現(xiàn)合約的地址
newImplementation.delegatecall('..'); // 調用新的實現(xiàn)合約的初始化函數(shù)
}
}
需要更新實際合約B時，由管理員預先部署好更新后的合約B‘，使用新合約B‘的地址作為參數(shù)調用upgradeToAndCall函數(shù)，該函數(shù)會將代理合約A中記錄實現(xiàn)合約的存儲從B修改為B’，隨后便會使用delegatecall調用新合約B‘的初始化函數(shù)initialize完成初始化。在initialize中會更新A合約存儲中的管理員賬號。
UUPS模式使用時的風險
讓我們一起來重點關注一下負責鑒權的upgrader變量在代理合約A和實現(xiàn)合約B中的作用：因為可更新的智能合約將原本在一個合約中完成的邏輯拆分到了兩個合約中代理合約A和實際合約B，所以這兩個合約都分別在自己的存儲中維護了自己的upgrader存儲變量。
當管理員通過調用upgradeToAndCall這一步驟完成更新之后，由于delegatecall的特性，代理合約A中的upgrader變量被順利地更新了，但是實現(xiàn)合約B‘中的upgrader并沒有被更新。雖然B’的存儲在UUPS模式中不是實際的存儲，但是B‘除了是代理合約A的實現(xiàn)合約之外，同時也是一個可以公開訪問的普通合約。
實際上，在使用UUPS模式更新合約時，對于upgrader存儲變量有兩個分開的重要步驟：
- 將A的存儲中的upgrader更新為msg.sender（upgradeToAndCall中已經實現(xiàn)）
- 將B’的存儲中的upgrader更新為msg.sender（管理員需要的額外步驟）
管理員不僅需要通過調用原實現(xiàn)合約B中的upgradeToAndCall函數(shù)通過新實現(xiàn)合約B‘中的initialize函數(shù)更改A存儲中的upgrader變量（第一步），同時也需要額外在外部獨立調用一次initialize函數(shù)更改B’存儲中的upgrader變量（第二步）。
在缺少第2步的情況下，相當于是代理合約A被正確的初始化了，用戶無法通過代理合約A進行任何惡意的行為，但是B‘沒有做任何的初始化，用戶仍舊可以直接調用B’的初始化函數(shù)initialize，將B‘的存儲中的upgrader更新為自己，通過控制B’的升級行為去調用自毀操作實現(xiàn)將B‘合約銷毀的操作，使得A合約所指向的實現(xiàn)合約B’消失了，代理A合約所剩下的數(shù)據存儲也將沒有任何用處。
Wormhole的實際漏洞情況
Wormhole項目源碼：https://github.com/certusone/wormhole
Wormhole負責更新與鑒權的具體邏輯與上文所描述的思路來說稍復雜。其負責實現(xiàn)UUPS標準upgradeToAndCall?函數(shù)實際名稱為submitContractUpgrade?，并且鑒權時使用了parseVM等與自定義虛擬機相關的操作：
abstract contract Governance .. {
function submitContractUpgrade(bytes memory _vm) public {
Structs.VM memory vm = parseVM(_vm);
setGovernanceActionConsumed(vm.hash);
upgradeImplementation(upgrade.newContract); // 設置新的實現(xiàn)合約的地址
}
}
wormhole/ethereum/contracts/Governance.sol
在實現(xiàn)合約中，initialize負責對管理員變量進行初始化：
contract Implementation is Governance {
function initialize(, bytes32 governanceContract) {
setGovernanceContract(governanceContract); // 設置upgrader
}
}
wormhole/ethereum/contracts/Implementation.sol
Wormhole在上一次調用submitContractUpgrade( )更新在區(qū)塊高度13818843（2021年12月16日），之后實際合約B‘始終處于未初始化的狀態(tài)。
攻擊者可以未授權調用實際合約B’的初始化函數(shù)initialize( )?獲取B’合約管理員權限，隨后憑借所獲得的管理員權限惡意地調用更新函數(shù)submitContractUpgrade( )，該更新函數(shù)中的delegatecall允許執(zhí)行攻擊者指定的任意代碼，其中危害最大的是執(zhí)行selfdestruct讓實際合約B’自毀，使得Wormhole項目中的資產被凍結。
Wormhole項目方在高度14269474（2022年2月24日）調用了初始化函數(shù)后修復了該問題。
使用UUPS代理模式時有需要特別注意的關鍵步驟，在沒有完成必要的初始化的情況下，黑客能夠通過初始化實現(xiàn)合約獲取管理員權限，并惡意地并調用更新函數(shù)銷毀實現(xiàn)合約，導致代理合約內的資產被永久鎖定。
Side note. 你也想嘗試獨立發(fā)現(xiàn)這個千萬美元懸賞的天價漏洞？以太坊安全練習平臺Ethernaut提供了這一漏洞模式的練習環(huán)境，快來自己試試手吧！
總結
跨鏈橋因其自身的中心化特性而在去中心化的Web3世界中引入了中心化風險，其安全性很大程度上取決于跨鏈橋項目方自身。所以說，跨鏈橋的開發(fā)者，對跨鏈橋安全性起了決定性的作用。
