BurgerSwap 攻击策略

DemaxPlatform合约地址:https://bscscan.com/address/0xbf6527834dbb89cdc97a79fcd62e6c08b19f8ec0#code

BurgerSwap 是一个仿 Uniswap AMM 项目,但是和 Uniswap 架构有所区别。BurgerSwap 架构总体分成【Delegate -> lpPlatForm -> Pair】。其中 Delegate 层管理了所有的 Pair 的信息,并负责创建 lpPlatForm 层。然后 lpPlatForm 层再往下创建对应的 Pair 合约。在整个架构中,lpPlatForm 层充当了 Uniswap 中 Router 的角色,负责将计算交易数据和要兑换的代币转发到 Pair 合约中,完成兑换。

攻击者从 Pancake 中借出了大量的 WBNB,然后将这些 WBNB 通过 BurgerSwap 兑换成 Burger 代币。在完成以上的操作后,攻击者使用自己控制的代币(攻击合约本身) 和 Burger 代币通过 Delegate 层创建了一个交易对并添加流动性,为后续攻击做准备。

由于先前攻击者在创建交易对的时候使用的是自己控制的代币,在代币兑换过程中, _innerTransferFrom 函数会调用攻击者控制的代币合约,于是攻击者可以 _innerTransferFrom 函数中重入 swapExactTokensForTokens 函数。为什么攻击者要这样做呢?

通过对 PlatForm 层的 swapExactTokensForTokens 函数进行代码分析,我们不难发现,合约在调用 _innerTransferFrom 函数时首先计算了用户的兑换数据,然后在 _innerTransferFrom 函数的操作后使用预先计算的数据来转发到底层进行真正的代币兑换。从这个函数层面来看,就算攻击者重入了 swapExactTokensForTokens 函数,底层调用的 swap 函数也是独立的。

问题就出在 Pair 层本身并不做恒定乘积的检查,在重入的过程中,在 _innerTransferFrom 函数完成后,Pair 的更新数据也没有反映到 PlatForm 层中,导致重入交易中的兑换产生的滑点并不影响下一次的兑换,从而造成了损失。

DemaxPair合约地址

DemaxPair 合约的swap函数代码

UniswapV2Pair合约的swap函数代码

参考UniswapV2Pair的25行,Uniswap有做恒定乘积K值的检查,但BurgerSwap的DemaxPair 合约并没有,因为这个原因,科学家发起重入交易中的兑换产生的滑点并不影响下一次的兑换,从而造成了损失。

Last updated

Was this helpful?