圖文拆解：DeFi 平台 Balancer 遭駭客攻 - 數位貨幣

圖文拆解：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被駭客攻擊 去中心專家怎麼看

--