原文:《正處於“刮骨療毒” 自救的SushiSwap,今日又是如何被黑客攻擊的?

2023年4月9日,據BeosinEagleEye態勢感知平台消息, SushiswapRouteProcessor2合約遭受攻擊,部分對合約授權過的用戶資金被黑客轉移,涉及金額約1800ETH,約334萬美元。

據了解,SushiSwap 流動性挖礦項目,克隆自Uniswap,最大的不同是其發行了SUSHI 代幣,團隊希望用SUSHI 通證經濟模型,優化Uniswap。但Uniswap 創始人Hayden Adams 表示,Sushi 只是任何有能力的開發人員通過一天的努力創造出來的東西,試圖利用炒作和Uniswap 創造的價值來獲利。

其實在本次攻擊之前,這個項目還有另外的“坎坷”,去年12 月6 日,上任僅兩個月的Sushi 新任“主廚” Jared Grey 於治理論壇發起了一項新提案。在該提案中, Jared 首次向外界披露了Sushi 當前嚴峻的財務狀況,並提出了一個暫時性的自救方案。 (相關閱讀:《 Sushiswap財庫告急,新任“主廚”按下“自救鍵” 》)

正是在這樣的壓力下,黑客又來一擊,那在黑客的打擊下,SushiSwap能否走出自救的道路?

雪上加霜,處於“自救期”的SushiSwap是如何被黑客攻擊的?

事件相關信息

我們以其中一筆攻擊交易進行事件分析。

攻擊交易

0xea3480f1f1d1f0b32283f8f282ce16403fe22ede35c0b71a732193e56c5c45e8

攻擊者地址

0x719cdb61e217de6754ee8fc958f2866d61d565cf

攻擊合約

0x000000C0524F353223D94fb76efab586a2Ff8664

被攻擊合約

0x044b75f554b886a065b9567891e45c79542d7357

被攻擊用戶

0x31d3243CfB54B34Fc9C73e1CB1137124bD6B13E1

攻擊流程

1.攻擊者地址(0x1876…CDd1)約31天前部署了攻擊合約。

雪上加霜,處於“自救期”的SushiSwap是如何被黑客攻擊的?

2.攻擊者發起攻擊交易,首先攻擊者調用了processRoute函數,進行兌換,該函數可以由調用者指定使用哪種路由,這裡攻擊者選擇的是processMyERC20。

雪上加霜,處於“自救期”的SushiSwap是如何被黑客攻擊的?

雪上加霜,處於“自救期”的SushiSwap是如何被黑客攻擊的?

3.之後正常執行到swap函數邏輯中,執行的功能是swapUniV3。

雪上加霜,處於“自救期”的SushiSwap是如何被黑客攻擊的?

雪上加霜,處於“自救期”的SushiSwap是如何被黑客攻擊的?

4. 在這裡可以看到, pool的值是由stream解析而來,而stream參數是用戶所能控制的,這是漏洞的關鍵原因,這裡lastCalledPool的值當然也是被一併操控的,接著就進入到攻擊者指定的惡意pool地址的swap函數中去進行相關處理了。

雪上加霜,處於“自救期”的SushiSwap是如何被黑客攻擊的?

5.Swap完成之後,由於此時lastCalledPool的值已經被攻擊者設置成為了惡意pool的地址,所以惡意合約調用uniswapV3SwapCallback函數時校驗能夠通過,並且該函數驗證之後就重置了lastCalledPool的值為0x1 ,導致swapUniV3函數中最後的判斷也是可有可無的,最後可以成功轉走指定的from地址的資金,這里為100個WETH。

雪上加霜,處於“自救期”的SushiSwap是如何被黑客攻擊的?雪上加霜,處於“自救期”的SushiSwap是如何被黑客攻擊的?

雪上加霜,處於“自救期”的SushiSwap是如何被黑客攻擊的?

漏洞分析

本次事件攻擊者主要利用了合約訪問控制不足的問題,未對重要參數和調用者進行有效的限制,導致攻擊者可傳入惡意的地址參數繞過限制,產生意外的危害。

雪上加霜,處於“自救期”的SushiSwap是如何被黑客攻擊的?

總結

針對本次事件,Beosin安全團隊建議:

1.在合約開發時,調用外部合約時應視業務情況限制用戶控制的參數,避免由用戶傳入惡意地址參數造成風險。

2.用戶在與合約交互時應注意最小化授權,即僅授權單筆交易中實際需要的數量,避免合約出現安全問題導致賬戶內資金損失。