Balancer 遭駭客攻擊全過程技術拆解
第一步：閃電貸
從 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 美元的數字資產，詳情列表如下：
