分析SharkTeam的ERC2771 Multicall中任意地址替換漏洞的原理

2023年12月8日，OpenZeppelin發布了重要的安全警告。原來，在共享ERC-2771標準和Multicall類型功能時存在地址被替換的風險！我深入研究了這個漏洞，並希望分享我的發現。

攻擊分析

考慮一種攻擊：

• 攻擊者：0xFDe0d1575Ed8E06FBf36256bcdfA1F359281455A
• 交易： 0xecdd111a60debfadc6533de30fb7f55dc5ceed01dfadd30e4a7ebdb416d2f6b6

攻擊方案簡單而巧妙：

1. 惡意攻擊者將5 WETH兌換爲大約3,455,399,346 TIME
2. 然後構造了巧妙的calldata參數，並調用了[Forwarder].execute
3. 此功能在TIME合約中啓動了multicall，剩餘的calldata用於burn() - 在池中銷毀代幣!

它是如何工作的？

在這次攻擊中，星星匯聚在一起：ERC-2771、Multicall和精心編制的數據。TOKEN合約繼承了ERC2771Context，這裏開始變得有趣起來！

ERC-2771提供了虛擬的msg.sender，允許將交易委托給第三方。同時，真實地址被添加到calldata中。當[Forwarder]調用合約時，_msgSender()檢查這些數據並裁剪最後20個字節作爲"真實" msg.sender。

Multicall 將一個調用轉換爲多個調用，從而節省燃氣。它接受一個調用數組，並通過 deleGatecall() 執行它們。

而這裏是陷阱！攻擊者移動 calldata，使得前 4 個字節的新數據對應於函數 burn()，而參數是巨額的代幣。在 0x20 行中添加了 TIME-ETH 流動性池的地址，成爲 "預期的" msg.sender！

問題的根源

在 ERC-2771 [Forwarder] 從未計劃與 multicall 一起使用！攻擊者將參數 _msgSender() 添加到 multicall 的外部調用中。在 multicall 函數內部，一些函數也添加了這些參數，這使得它們能夠模擬來自任何地址的調用！

保護措施

1. 新版 OpenZeppelin Multicall 現在保存 ERC-2771 的上下文長度，並在每次子調用時考慮它。

2. ThirdWeb 更進一步，禁止任何合約調用 multicall，防止使用 [Forwarder].

這個漏洞是一個鮮明的例子，說明單獨安全的組件組合在一起可能會造成災難性的缺口！所有開發者都應該記住：始終檢查不同標準之間的交互。