Immunefi的一枚賞金600萬美金的智能合約漏洞挖掘過程
如果您是 Web2 或 Web3 開發人員，并且最終正在考慮在 Web3 中尋找 bug 的職業，那么我們為您服務。查看我們的終極區塊鏈黑客指南，并開始從 Immunefi（Web3 領先的漏洞賞金平臺）上獲得 1.44 億美元的獎勵。
官網：https://immunefi.com/
概括白帽黑客 pwning.eth 于 4 月 26 日通過 Immunefi 在 Aurora 提交了一個嚴重漏洞。
該漏洞包含一個無限支出漏洞，如果被惡意用戶利用，可能會導致 7 萬 ETH 和 2 億美元其他資產的直接損失。
值得慶幸的是，由于 pwning.eth 的高超技術，該漏洞被負責任地披露，而不是被利用。
沒有用戶資金損失，Aurora 迅速修復了這個錯誤，為每個人帶來了積極的結果。
由于該漏洞被評估為嚴重級別，因此白帽公司已從 Aurora 獲得 600 萬美元的獎金，這是歷史上第二大賞金支出。
Aurora 應該受到贊揚，因為它擁有運行良好的賞金計劃、快速的響應時間和大量的漏洞賞金獎勵，這些獎勵激勵了這類項目節省報告。
詳細漏洞報告：
https://aurora.dev/blog/aurora-mitigates-its-inflation-vulnerability
Immunefi 很高興使用我們的平臺促進了這種負責任的披露。我們的目標是通過激勵黑客負責任地披露錯誤并獲得干凈的金錢和聲譽作為交換，使 Web3 更安全。
由于 Aurora 中受影響的部分——彩虹橋——是一座跨鏈橋梁，我們將首先簡要討論跨鏈橋梁的工作原理，然后再深入探討無限支出漏洞本身。
彩虹橋簡介有許多正在積極使用的區塊鏈網絡，例如 Ethereum、NEAR、Polygon、Fantom、Avalanche、BSC 或 Solana，每個都有自己的價值主張。隨著用戶（和資金）涌入 DeFi，對具有低交易費用和快速確認/最終確定性的區塊鏈的需求呈爆炸式增長。
為了滿足這一需求，L2 擴展解決方案和側鏈出現了激增。但是，這些解決方案（通常）不能互操作和相互通信。許多 DeFi 協議是不同鏈的原生協議。例如，Aave 是以太坊原生的，但 PancakeSwap 是 BSC 原生的。
爆炸式增長的 NFT 空間也是如此，我們看到大量的收藏不僅在以太坊上推出，還在 Polygon、Solana 和 NEAR 上推出。但是，如果我們想將寶貴的 NFT 或有價值的代幣從一條鏈轉移到另一條鏈上怎么辦？
這個問題的答案是區塊鏈跨鏈橋技術。橋接器是連接兩個或多個不同區塊鏈并使用戶能夠在它們之間移動資產的一種方式。有不同的橋梁設計和方法。沒有任何標準化的方式來設計您自己的橋梁。我們仍處于未知領域。
與“常規” DeFi 項目相比，橋接器還具有額外的“攻擊面”。雖然收益農場或去中心化交易所可能擁有一系列智能合約和 dapp 網頁，但橋接器通常需要監控節點、驗證器密鑰以及在這些合約和 dapp 之上的安全通信通道。這種增加的復雜性意味著更多的代碼行可以隱藏錯誤，以及黑客入侵的更多方式。
將在一個網絡上獲得/賺取的代幣轉移到另一個網絡的需求每天都在增加。流經橋梁的數量是巨大的。
大多數跨鏈橋接器都實現了所謂的 IOU（我欠你）的方法：
用戶向橋接器協議發送資金，然后這些資金被橋接器智能合約鎖定，而橋接器協議在來自第二個跨鏈橋智能合約的第二個網絡。
通常，目標鏈上的代幣被稱為 IOU 代幣或包裝代幣。例如，如果用戶想通過彩虹橋將以太幣從以太坊發送到 NEAR，以太幣將被以太坊端的橋接合約鎖定，用戶可以從 NEAR 的橋接合約中兌換等價的代幣。對于從一條鏈轉移到另一條鏈的每一美元，橋必須將該美元保留在其“本機”鏈上，以防用戶想要將資金轉移回去。
可想而知，跨鏈橋中堆積如山的資金。
什么是Aurora？Aurora 是建立在 NEAR 網絡上的 EVM 實現，它支持以太坊生態系統中可用的所有工具。除了 EVM，Aurora 還開發了 Rainbow Bridge，允許用戶在 Ethereum、NEAR 和 Aurora 之間轉移資產。換句話說，它允許用戶將 ETH 和 ERC20 代幣從以太坊主網存入 NEAR 的嵌套層，即 Aurora。
我們不會詳細解釋 Aurora 的工作原理。您可以在 Aurora 官方文檔中閱讀。我們將深入探討 Aurora 如何處理從 Aurora 到 NEAR 以及 Aurora 和以太坊之間的取款。
Aurora 引擎中的兩個合約對我們來說特別有趣：ExitToNear和ExitToEthereum. 簡而言之，它們是特殊的內置（預編譯）合約，用于處理來自 Aurora EVM 的提款請求。
在Aurora上映射ERC20代幣的模板合約中，我們可以在以下代碼中看到這兩個合約的觸發：
在這兩種情況下，ERC20 代幣的邏輯看起來都很好，因為調用這些函數將首先燒掉 ERC20 代幣，然后再繼續調用特殊的內置合約。這就是將 ERC20 代幣從 Aurora 提取到 NEAR 或以太坊的方法。以太坊呢？
我們仍然稱這些特殊合約，但方式略有不同。我們只需將 ETH 發送到一個特殊的合約，該合約就會生成一個事件ExitToNear，記錄此退出的發送者、目的地和金額。在ExitToNear合約執行結束時，exit_event_log返回包含事件信息。
下面是合約代碼信息：
https://github.com/aurora-is-near/aurora-engine/blob/5c8691ea6ea5f1b309ef227f7f5c719ffea45d28/engine-precompiles/src/native.rs#L198
主執行完成后，這些日志以及執行期間的所有其他日志將filter_promises_from_logs在aurora-engine/engine/src/engine.rs中進行檢查。
只要使用硬編碼的地址生成日志ExitTo(Near|Ethereum)::ADDRESS，log.data就會將其作為新的承諾進行處理。
但是，只要調用原生合約的代碼，就可以生成這些轉賬承諾。
漏洞分析在以太坊中，合約調用主要分為三種類型：
常規CALL、STATICCALL和DELEGATECALL。
我們不會處理，STATICCALL因為它在 Aurora 引擎中被明確禁止。
我們將深入研究另外兩個。
當合約 ACALL通過調用 對合約 B進行 a 時foo()，函數執行依賴于合約 B 的存儲，并將msg.sender設置為合約 A。
這是因為合約 A 調用了函數foo()，因此msg.sender將是合約 A 的地址，并且msg.value將是與該函數調用一起發送的 ETH。
在該函數調用期間對狀態所做的更改只會影響合約 B。
但是，當使用 進行相同的調用時DELEGATECALL，該函數foo()將在合約 B 上調用，但在合約 A 的上下文中。這意味著將使用合約 B 的邏輯，但該函數所做的任何狀態更改foo()都會影響存儲合約 Amsg.sender將指向首先撥打電話的 EOA。在 Aurora 錯誤的情況下，重要的是msg.value指向第一個調用上下文，而不是第二個。
換句話說，以太坊不被發送delegatecall。（參見示例 2）。
知道我們可以生成從 Aurora 到 NEAR 的傳輸承諾，通過ExitToNear直接調用內置合約，我們可以DELEGATECALL用來欺騙 Aurora 引擎，使其認為我們實際上發送了 Ether。為什么會這樣？因為代碼只檢查是否LOG由內置地址生成，并且假設msg.value > 0實際上意味著 ETH 已發送到該地址。
如果我們使用delegatecall()調用原生合約，msg.value會繼承原來的調用上下文，但是 ETH 不再傳遞給原生合約。下面的智能合約就是這樣做的。
它從調用者那里獲取 ETH 值，觸發ExitToNear合約中的退出事件，然后將 nETH 發送回調用者。nETH 可以通過 Aurora Bridge 再次存入 Aurora EVM，有效地使攻擊者的原始余額翻倍。
步驟：
1.使用彩虹橋（Aurora Bridge）將以太幣從以太坊橋接到極光
2.在 Aurora 上部署惡意合約，使其成為delegatecall原生合約，ExitToNear即0xe9217bc70b7ed1f598ddd3199e80b093fa71124f
3.調用惡意合約的exploit函數。此時，Aurora 被欺騙，從 Aurora 橋接合約向 NEAR 上的調用者發送 nETH。
4.攻擊者的平衡在 Aurora 上沒有改變 攻擊者然后將 nETH 存回 Aurora，使攻擊者的余額翻倍
5.從第 3 步開始重復。需要注意的是，這個錯誤會導致 NEAR 和 Aurora 運行時的復雜集成邏輯，如果沒有來自 pwning.eth 的深入分析，這樣的發現是不可能的。
漏洞修復如果給定的地址與輸入的地址不匹配，現在將返回退出錯誤，這將禁用調用合約的能力，DELEGATECALL類似于 Aurora 禁用STATICCALL。
Aurora 開發了一個測試來確保跟蹤該漏洞，以防萬一邏輯更改可能導致它再次出現。
PS：最近朋友圈也有一位國內的大佬在Imm上提交了一枚智能合約漏洞，收獲了11萬美金的賞金收入（為保護隱私，我就不放朋友圈截圖出來了）
如果大家覺得目前的滲透和安全行業太卷了，不如去研究研究區塊鏈安全，指不定你也可以成為下一個牛逼的區塊鏈黑客大佬！
