[新聞] 圖文拆解:DeFi 平台 Balancer 遭駭客攻

作者: joug (好東西不簽嗎)   2020-07-01 16:46:35
圖文拆解:DeFi 平台 Balancer 遭駭客攻擊的全過程 (BAL)
6月29日凌晨02時03分起,最近因「借貸即挖礦 Yield Farming」模式而備受關注 DeFi平
台Balancer上的STA和STONK兩個ERC20通縮代幣池遭到了駭客攻擊,共計損失了超50萬美
元。
(背景補充:Defi突發警示|駭客重現閃電貸手法,耗盡 Balancer 資金池超過 50 萬美
元資產 (Bal))
PeckShield安全人員介入分析後,迅速定位到問題的本質在於,Balancer上的通縮型代幣
和其智能合約在某些特定場景不兼容,使得攻擊者可以創建價格偏差的STA/STONK流通池
並從中獲利。
此次駭客實施攻擊共計分了四個步驟,具體而言:
1)攻擊者通過閃電貸從dYdX 平台借出了104,331 個WETH;
2)攻擊者反复執行swapexactMountin() 調用,直至Balancer 擁有的大部分STA 代幣被
消耗殆盡,進而開始下一步攻擊。最終Balancer 僅僅剩餘0.000000000000000001 個STA

3)攻擊者利用STA 代幣和Balancer 智能合約存在的不兼容性即記帳和餘額的不匹配性實
施攻擊,將資金池中的其他資產耗盡,最終共計獲利價值523,616.52 美元的數字資產。
4)攻擊者 償還從dYdX 借出的閃電貸,並捲走了攻擊所得的數字資產。
接下來的篇幅中,我們將逐步解析駭客在該筆閃電貸交易
(http://oko.palkeo.com/0x013be97768b702fe8eccef1a40544d5ecb3c1961ad5f87fee4d16
fdc08c78106/) 中實施的攻擊行為。
Balancer 遭駭客攻擊全過程技術拆解
圖解黑客攻擊全流程
圖解駭客攻擊全流程
第一步:閃電貸 FlashLoan
從dYdX 閃電貸104,331 WETH,這部分熟悉DeFi 借貸模式的讀者應該都比較清楚,此處不
再贅述。
第二步:清空Balancer 的STA 資產
攻擊者通過多次swapExactAmountIn() 調用清空了Balancer 的STA 資產,為下一步實施
攻擊做準備。值得一提的是,我們發現合約代碼中每次能夠兌換的資產數額其實有上限,
然而狡猾的攻擊者預先計算了可兌換的WETH 最大數額,並巧妙的讓Balancer 只剩了
0.000000000000000001 STA。
由於Balancer 資金池(BPool)各資產間存在“動態平衡”原理,僅剩接近於0 的STA 會
拉高STA 的價值,使得任何人都可以用1 STA 換到大量的其他數字資產。
第三步:攻擊獲利
經過前兩個準備步驟之後,攻擊者是時候展現真正技術了!
第三步 :攻擊獲利圖示上
第三步 :攻擊獲利圖示上
承上所述,攻擊者通過swapExactAmountIn() 函數將 0.000000000000000001 STA 發送到
BPool,以極高的價值差,立即兌換出了30,347 個WETH,實現了獲利。
而此時,BPool 的內部記帳機制 _records[STA] 在BPool 真正收到
0.000000000000000001 STA 之前先加了1(注:此後攻擊者會用gulp()對該數值進行重置
)。
第三步:攻擊獲利圖示下
第三步:攻擊獲利圖示下
另外我們發現,在swapExactAmountIn() 的底部,_pullUnderlying() 嘗試從攻擊者端收
集相應消耗的STA。然而,由於STA 轉帳時還會燒掉1% 的手續費,實際BPool 是收不到任
何STA 的。
這樣就使得BPool 的實際STA 餘額和內部記帳產生不匹配。
接下來是最有趣的一部分,攻擊者調用gulp()不斷重置_records[STA],使得BPool中始終
保持0.000000000000000001個STA。
因此攻擊者可以用極高價的0.000000000000000001個STA將流通池中的WETH、SNX、LINK等
其他資產消耗光。
第四步:償還閃電貸
最終,如上圖所示,攻擊者償還了從閃電貸借出的104,331個WETH。
建議
此次攻擊事件再次暴露了DeFi 可組合性存在的兼容性風險。此前不久,Uniswap 和
Lendf.Me 兩個平台就因和ERC777 標準的兼容性問題,產生了非常嚴重的駭客攻擊事 件

需要警醒的是,在未來DeFi 行業類似的駭客攻擊行為或許會屢見不鮮。
如果問該怎樣才能規避這類攻擊事件的發生呢?或許有兩個優化調整思路:
1)STA/STONK在執行transfer()或transferFrom()時,當轉帳數額不足以支付手續費時,
應該直接回滾或者返回False
2) Balancer應該在每一次transferFrom ()函數調用後檢查BPool的餘額。
當然,任何安全事件事後採取措施補救都無法彌補已經產生的損失,我們相信最好的解決
方案還是事前防備。
DeFi 項目開發者應盡可能利用好的代碼規範,並可尋求第三方安全公司協助其在上線前
進行全面的攻防測試,盡可能找出一切潛在的漏洞。
最後,盡可能對ERC20、ERC777 和其它DeFi 項目的任何組合行為都做好周密排查。
後續
毫無疑問,Balancer 事件的發生勢必也會對DeFi 社區帶來影響,而且這類事情接下來發
生的可能性還會很大,在此提醒廣大DeFi 項目開發者應務必重視合約的安全問題。
經我們統計發現,Balancer 在此次攻擊事件共計損失了523,616.52 美元的數字資產,詳
情列表如下:
https://reurl.cc/8GaoVM
Balancer被駭客攻擊 去中心專家怎麼看
作者: QMO220 (失憶)   2020-07-01 17:32:00
看來跟我想的一樣
作者: darkdixen (darkdixen)   2020-07-01 18:30:00
這是LG糞幣的鍋
作者: DarkerDuck (達克鴨)   2020-07-02 02:11:00
LG表示躺著也中槍XDD
作者: sdtty (龍井裘德洛)   2020-07-02 09:06:00
代碼都審計兩次了還會被破解啊
作者: leftc (阿左)   2020-07-02 23:03:00
兩次不夠,這不就來了第三次嗎~ 審查費 523,616.52 美元

Links booklink

Contact Us: admin [ a t ] ucptt.com