前言
8月17日，BSC链上的XSURGE协议遭到闪电贷攻击，损失超过500万美元。对此，知道创宇区块链安全实验室对攻击流程和代码细节进行了全盘梳理。
全盘梳理
基础信息
-攻击tx：0x7e2a6ec08464e8e0118368cb933dc64ed9ce36445ecf9c49cacb970ea78531d2-攻击合约：
0x1514AAA4dCF56c4Aa90da6a4ed19118E6800dc46
-SurgeToken：
0xE1E1Aa58983F6b8eE8E4eCD206ceA6578F036c21
攻击流程
这里有个小细节，代币转移流程中的顺序是按照事件先后顺序来显示的，而重入之后的买操作引起的事件会在卖操作引起的事件之前，所以在流程中看到的每一个单独的重入攻击中是SURGE的买入发生在卖出之前。
漏洞原理
漏洞点在于SurgeToken合约中的sell()函数，其中对调用者msg.sender的BNB转账采用的call()函数，并且在转账之后才更新代币总量_totalSupply，是典型的重入漏洞场景。
虽然sell()函数使用了nonReentrant修饰防止了重入，但purchase()函数并没有。重入转回BNB给合约，触发fallback函数调用purchase()，由于_totalSupply尚未减去卖出量，而导致可买入相较正常更多的SURGE代币。
复现
价格分析
sell()函数卖出过程中，输入tokenAmount与输出amountBNB的关系：
purchase()函数买入过程中，输入bnbAmount与输出tokensToSend的关系：
在重入过程中，sell()函数卖出后获得的BNB通过重入打回SurgeToken合约传入purchase()函数故令sell()函数的输出amountBNB与purchase()函数的输入bnbAmount相等，可得到整个利用流程中输入与输出的关系：
若要实现套利，需要输出大于输入，则有：
最后得到：
也就是说重入套利过程中调用sell()卖出的代币量必须在代币总量的12.383%以上
模拟演示
为方便调试，将SurgeToken合约中的mint()函数可见性改为public，并为构造函数增加payable修饰，在部署时传入10^15wei。
SurgeToken合约初始化的代币总量为10^9，根据前面推导出的结论，为攻击合约铸币200000000，则攻击合约拥有大约SURGE代币总量16%的代币。
攻击合约调用Attack()函数攻击，查看攻击合约的代币余额已变为209549307，获利9549307。
总结
XSURGE协议被攻击的本质原因在于sell()函数中存在重入漏洞，导致可通过purchase函数买入较多的SURGE代币而获利。
简而言之，典型的重入漏洞场景，教科书级的案例。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。