SIN:黑客获利约630万美元算法稳定币$DEI被攻击事件分析

作者：

时间：1900/1/1 0:00:00

2023年5月6日，据Beosin-Eagle Eye态势感知平台消息，算法稳定币DEI项目合约遭受黑客攻击，黑客获利约630万美元。Beosin安全团队第一时间对事件进行了分析，结果如下。

事件相关信息

攻击交易

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

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

Yearn Finance项目疑似遭受攻击，黑客获利超1000万美元:金色财经报道，据区块链安全审计公司Beosin旗下Beosin EagleEye安全风险监控、预警与阻断平台监测显示，Yearn Finance项目疑似遭受到闪电贷攻击，黑客获利超1000万美元，目前资金全部存在黑客地址。 Beosin Trace将持续对资金流向进行监控。[2023/4/13 14:01:37]

攻击者地址

Bsc：0x08e80ecb146dc0b835cf3d6c48da97556998f599

Arbitrum：0x189cf534de3097c08b6beaf6eb2b9179dab122d1

被攻击合约

SushiSwap的BentoBoxv1合约遭受攻击，黑客获利约2.6万美元:金色财经报道，据区块链安全审计公司Beosin监测显示，SushiSwap的BentoBoxv1合约，据Beosin安全技术人员分析，该攻击是由于Kashi Medium Risk ChainLink价格更新晚于抵押/借贷后。在两笔攻击交易中，攻击者分别flashloan了574,275+785,560 个 xSUSHI, 在抵押和借贷之后，LINK Oracle中的kmxSUSHI/USDT 的价格从下降了16.9%。通过利用这一价格差距，攻击者可以调用 liquidate()函数清算从而获得15,429+11,333 个USDT，Beosin Trace追踪发现目前被盗资金还在攻击者的地址上：0xe7F7A0154Bf17B51C89d125F4BcA543E8821d92F。[2023/2/10 11:58:50]

0xde1e704dae0b4051e80dabb26ab6ad6c12262da0

安全团队：BNBChain上加密项目ORT被利用，黑客获利约7万美元:金色财经报道，据区块链安全审计公司Beosin监测显示，BNBChain上的加密项目ORT被利用，黑客获利约7万美元。

其中黑客首先调用INVEST函数，这个函数会调用_Check_reward函数来计算用户的奖励，但是黑客的duration变量为0，所以会直接返回total_percent变量作为reward参数，然后黑客调用withdraw And Claim函数提取奖励，获取total_percent数量的ORT代币，重复上述步骤获利。[2023/1/17 11:16:00]

两条链上漏洞原理以及攻击手法相同，这里以Bsc链上交易为例进行分析：

1.攻击者调用攻击合约的0xf321f780函数发起攻击。

BSC链上AutoShark Finance遭遇闪电贷攻击，黑客获利约58万美元:10月2日消息，据PeckShield“派盾”官方推特消息，DeFI协议AutoShark Finance遭遇闪电贷攻击，其交换挖掘功能在一系列交易中被利用，由于矿池的流动性相对较低，黑客可以使用闪电贷占据矿池的大部分份额(以弥补交换损失/费用)，同时仍然享受可观的“交换费用奖励”(从每次巨额交换中增加)。黑客重复上述步骤七次，获利318万FINS，之后立即将FINS交换为1,388BNB（约合581,000美元）。

此前报道，今年5月，BSC链上DeFi协议AutoShark Finance遭到闪电贷攻致使其币价闪崩，跌至0.01美元，跌幅达到99%以上。[2021/10/2 17:20:51]

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的代币。