攻击交易

https://bscscan.com/tx/0xde2c8718a9efd8db0eaf9d8141089a22a89bca7d1415d04c05ba107dc1a190c3

https://arbiscan.io/tx/0xb1141785b7b94eb37c39c37f0272744c6e79ca1517529fec3f4af59d4c3c37ef

攻击者地址

Bsc：0x08e80ecb146dc0b835cf3d6c48da97556998f599

Arbitrum：0x189cf534de3097c08b6beaf6eb2b9179dab122d1

被攻击合约

0xde1e704dae0b4051e80dabb26ab6ad6c12262da0

两条链上漏洞原理以及攻击手法雷同，这里以Bsc链上交易为例停止剖析：

1.攻击者调用攻击合约的0xf321f780函数倡议攻击。

2.攻击合约首先调用DEI合约的approve函数给pair授权一个很大的值，随后调用DEI合约的burnFrom函数，传入pair地址。

3.随后，攻击合约间接调用DEI合约的transferFrom函数将pair的DEI代币全副转移给攻击合约，只剩下一个单位的DEI代币。

4.之后，攻击合约调用pair的sync函数，更新储蓄量，此时pair中只要1个单位的DEI和超130万枚USDT。

5.最后，攻击合约使用所有的DEI将USDC全副兑换出来。

漏洞剖析

我们从上述的攻击过程不难发现，本次事件的主要问题在于第2步与第3步，攻击者调用了approve和burnFrom函数之后，为什么就能间接调用transFrom函数将“其别人”的代币转移走？

我们看一下approve与burnFrom函数的代码，approve函数为正常授权函数，并没有什么问题，关键在于burnFrom函数（如下图），股票配资网，burnFrom函数正常逻辑是获取被销毁地址给调用者地址授权数量，之后将授权数量减去销毁数量的新值用于更新授权数量。可以看到，309行的代码函数获取用户授权值，而开发者将被销毁地址与调用者地址写反，导致获取的授权值是黑客可以任意设置的，在这之前，股票配资，黑客调用approve函数授权了一个宏大的数，所以这里获取的值是一个宏大的值，股票配资网，在310行代码，将授权值停止更新，这里通报的值就是一个异常大的值，导致burnFrom函数调用完毕后，pair地址给黑客地址授权了一个宏大的值，而黑客也能任意控制pair的代币。

资金追踪

截止发文时，被盗资金还未被攻击者转出。

总结

针对本次事件，Beosin安详团队建议：

1.合约开发时，波及权限相关的函数必然要认真考虑其运行逻辑，并做好每一步的测试，防止因为粗枝大叶导致不成挽回的后果。

2. 项目上线前，建议选择专业的安详审计公司停止片面的安详审计，躲避安详风险。