BSC上閃電貸攻擊再現！BurgerSwap 被駭技術分析 — 我竟騙了我自己？

本次攻擊屬於 BurgerSwap 架構上的問題，由於 Pair 層完全信任 PaltForm 層的數據，並沒有自己再做一次檢查，導致攻擊的發生。
（類似事件：BSC 項目 PancakeBunny 遭閃電貸攻擊！估遭駭 2 億美元，BUNNY 暴跌 99%）
（類似事件：BSC首現閃電貸攻擊／技術解析 Spartan Protocol 遭駭手法，造成 3 千萬美元損失）

本文目錄

據慢霧區消息，2021 年 5 月 28 日，幣安智能鏈（BSC） DeFi 項目 BurgerSwap 被駭，損失達 330 萬美元。慢霧安全團隊第一時間介入分析，並將結果分享如下：

攻擊細節分析

BurgerSwap 是一個仿 Uniswap AMM 項目，但是和 Uniswap 架構有所區別。

BurgerSwap 架構總體分成【Delegate -> lpPlatForm -> Pair】。其中 Delegate 層管理了所有的 Pair 的訊息，並負責創建 lpPlatForm 層。然後 lpPlatForm 層再往下創建對應的 Pair 合約。

在整個架構中，lpPlatForm 層充當了 Uniswap 中 Router 的角色，負責將計算交易數據和要兌換的代幣轉發到 Pair 合約中，完成兌換。

本次事件的根本正是出在這種架構的問題上。透過一步步分析攻擊者的交易行為，我們來還原整個攻擊過程的核心：

本次攻擊開始於 Pancake 的閃電貸，攻擊者從 Pancake 中借出了大量的 WBNB，然後將這些 WBNB 通過 BurgerSwap 兌換成 Burger 代幣。在完成以上的操作後，攻擊者使用自己控制的代幣（攻擊合約本身）和 Burger 代幣通過 Delegate 層創建了一個交易對並添加流動性，為後續攻擊做準備。

在完成代幣的創建和準備之後，攻擊者立馬通過 PaltForm 層的 swapExactTokensForTokens 函數發起了兌換，兌換路徑為【攻擊者自己控制的代幣-> Burger -> WBNB】

接下來進行了最關鍵的一次操作。

由於先前攻擊者在創建交易對的時候使用的是自己控制的代幣，在代幣兌換過程中， _innerTransferFrom 函數會調用攻擊者控制的代幣合約，於是攻擊者可以 _innerTransferFrom 函數中重入 swapExactTokensForTokens 函數。為什麼攻擊者要這樣做呢？

通過對 PlatForm 層的 swapExactTokensForTokens 函數進行程式碼分析，我們不難發現，合約在調用_innerTransferFrom 函數時首先計算了用戶的兌換數據，然後在 _innerTransferFrom 函數的操作後使用預先計算的數據來轉發到底層進行真正的代幣兌換。

從這個函數層面來看，就算攻擊者重入了 swapExactTokensForTokens 函數，底層調用的 swap 函數也是獨立的，乍看下並沒有什麼問題，但是鏈上的一個行為引起了慢霧安全團隊的注意：

我們驚訝地發現，在重入的兌換過程中，兌換的數量竟然沒有因為滑點的關係而導致兌換數量的減少。這究竟是什麼原因呢？看來關鍵是底層的Pair合約的問題了。

筆者又進一步分析了底層調用的Pair合約，程式碼如下：

通過分析 Pair 的程式碼，我們再次驚訝地發現在 swap 的過程中，合約竟然沒有在兌換後根據恆定乘積公式檢查兌換後的數值！！

也就是說，Pair 合約完全依賴了 PlatForm 層的數據進行兌換，導致了本次事件的發生。由於 Pair 層本身並不做恆定乘積的檢查，在重入的過程中，PlatForm層的兌換數據預先進行了計算，在 _innerTransferFrom 函數完成後，Pair 的更新數據也沒有反映到 PlatForm 層中，導致重入交易中的兌換產生的滑點並不影響下一次的兌換，從而造成了損失。用圖來看的話大概如下：