零时科技 || Unilend 攻击事件分析

我们监控到一笔Ethereum链上的异常交易,被攻击的项目为Unilend,事件共造成约 197k USD 的损失。

登链封面(事件).jpg

<!--StartFragment-->

背景介绍

2025年1月12日,我们监测到一笔 Ethereum 链上的异常交易:

https\://etherscan.io/tx/0x44037ffc0993327176975e08789b71c1058318f48ddeff25890a577d6555b6ba

经分析,我们发现是一次针对 Unilend 的攻击事件,事件共造成约 197k USD 的损失。

<!--EndFragment-->

<!--StartFragment-->

攻击及事件分析

首先,攻击者通过 Morpho Blue 利用 flashloan 借了 60,000,000 USDC, <!--EndFragment-->

1.png

<!--StartFragment-->

随后,攻击者又通过 Morpho Blue 利用 flashloan 借了 5.75 wstETH 。

<!--EndFragment-->

2.png <!--StartFragment-->

接着,又利用 unwrap 将贷来的 5.75 wstETH 兑换为了 6.85 stETH , 

<!--EndFragment-->

3.png

<!--StartFragment-->

然后,攻击者利用 lend 向 UniPool 中存入了 60,000,000 USDC 和 6.85 stETH 。

<!--EndFragment-->

4.png

<!--StartFragment-->

由于,攻击者已经存入足量的抵押物,所以接下来,攻击者利用 borrow 从 UniPool 中成功借走了 60.67 stETH 。

<!--EndFragment-->

5.png <!--StartFragment-->

然后,攻击者又利用 redeemUnderlying 分别从 UniPool 中兑换了 60,000,000 USDC , 5.75wstETH 。至此,攻击完成。 

<!--EndFragment-->

6.png

<!--StartFragment-->

漏洞就出现在 redeemUnderlying 中,理论上来讲,攻击者存入的抵押物已经在 borrow 时占用了一部分,所以在 redeemUnderlying 存入时的金额时应该失败,但是攻击者却成功执行了。那么,我们看一下 redeemUnderlying 的具体实现。 

<!--EndFragment-->

7.png

<!--StartFragment-->

从代码逻辑中,我们可以看到当 amount<0 时,兑换的是 token0 ,当 amount>0 时,兑换的是 token1 。兑换逻辑为。先计算出可以兑换的数量 tok_amount ,销毁对应的 LP Position ,检查 health factor ,转给用户完成兑换。

具体的漏洞出现在 checkHealthFactorLtv0 和 checkHealthFactorLtv1 中, check healthfactor 的算法为 抵押物数量 x 抵押物价格 / (借出价格 x 借出数量) > 1 ,但由于计算用户collateral amount 和 borrow amount 时测低配,导致此时同样也可以通过 health factor 的检查(理论上不能通过)。我们可以看到计算 collateral amount 和 borrow amount 的代码如下:

<!--EndFragment-->

8.png

<!--StartFragment-->

当用户有 collateral 时,合约会计算此次 redeem 后,抵押物的价值是否还是比已经借出的价值大。但是,在计算 redeem 后抵押物的价值时, tokenBalance0 并没有减去本次 redeem 需要减去的数量,又因为在 _burnLPposition 时 share 已经减去本次 redeem 后减少的 share 。所以导致_lendBalance0 也就是抵押物的数量要高于攻击者实际拥有的抵押物的数量。

攻击者最后再还清从 Morpho Blue 通过 flashloan 获取的 60,000,000 USDC , 5.75 wstETH 后,获利 60.67 stETH ,价值 197k USD 。

<!--EndFragment-->

<!--StartFragment-->

总结

本次漏洞的成因是 Unilend 在进行 redeem 时,在计算抵押物的数量时没有减去 redeem 应该转出的数量,导致错误的计算后抵押物的数量要高于攻击者实际拥有的抵押物的数量,本不应该成功的兑换成功完成。最终导致攻击者掏空了项目方的 stETH 代币。建议项目方在设计经济模型和代码运行逻辑时要多方验证,合约上线前审计时尽量选择多个审计公司交叉审计。

<!--EndFragment-->

点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
零时科技
零时科技
0xbD0b...A354
专注区块链生态安全