硬核解析 Uniswap 与 Lendf.Me 攻击全过程

加密谷Live
加密谷Live 机构得得号

Apr 21, 2020 每天更新你不可错过的区块链事件、项目及投资资讯

该文章已上链

摘要: Uniswap/Lendf.Me 攻击事件发生的根本原因在于,ERC777标准中原生地支持hook(钩子)机制的运行,而在imBTC实现过程中,并未在相应函数间加入互斥锁,从而出现了重入攻击漏洞。

作者 | PeckShield
摘 要:Uniswap/Lendf.Me 攻击事件发生的根本原因在于,ERC777标准中原生地支持hook(钩子)机制的运行,而在imBTC实现过程中,并未在相应函数间加入互斥锁,从而出现了重入攻击漏洞。黑客正是利用该漏洞对Uniswap与Lendf.Me发起攻击,以几乎接近于0的成本获得了巨额的数字资产。
UTC时间2020年4月18日上午12:58:19发生了一起针对Uniswap imBTC流动池的重入漏洞攻击。大约24小时后,UTC时间2020年4月19日上午12:58:43 Lendf.Me上也发生了类似的黑客攻击事件。从技术上讲,这两起事件背后的主要逻辑是,兼容ERC777的“transferFrom()”的实现有一个回调机制,这可使得攻击者可以在余额真正更新之前(即在_move()内部),彻底地劫持交易并执行其他非法操作(通过“_callTokensToSend()”)。
具体来说,攻击者利用该漏洞耗尽了Uniswap流动性池中的ETH-imBTC(约有1278个ETH),而Lendf.Me攻击事件中,黑客利用该漏洞伪造了其在Lendf.Me中imBTC抵押品金额内部记录,这样他就可以从所有可用的Lendf.Me流动性池中借到10多种资产(资产总值为25,236,849.44美元)。
 
根本原因分析
我们通过研究源代码发现,“transferFrom()”操作的“from”地址注册成为“implementer”(通过标准化ERC1820界面)时调用“tokensToSend()”函数的内在逻辑就是事件涉及的漏洞所在。为了清晰展示,我们在“tokensToSend()”函数被调用时对部分代码进行截图如下所示。就如在1054行显示的那样,ERC1820的“getInterfaceImplementer()”被用来收回已注册的implementer。该函数有两个参数:“from”和“TOKENS_SENDER_INTERFACE_HASH”,第一个参数其实是攻击者参数(比如该参数可以向Lendf.ME提供imBTC),而第二个参数是一个常数,即“keccak256("ERC777TokensSender")”。在1056行的代码中,“implementer”中定义的“tokensToSend()”函数被调用了,这使得攻击者可以通过填入其他恶意执行代码来黑进相应交易。
 
正如OpenZeppelin在2019年4月的帖子和去年7月发布的概念验证(proof-of-concept)漏洞所描述的那样,攻击者可以通过“InterfaceImplementer()”与定义上文提到的“tokensToSend()”的智能合约设置钩子(hook)。
 
在“tokensToSend()”函数中,攻击者可以填入其他的逻辑代码,比如多次出售相同规模的Token。
 
Uniswap攻击事件
由于前面已经介绍了Uniswap攻击事件背后的理论,所以我们在这篇博客中不再赘述。本文中我们研究了一个特定的恶意交易:(hash: 0x9cb1d93d6859883361e8c2f9941f13d6156a1e8daa0ebe801b5d0b5a612723c1)。
显然内嵌的“tokenToEthSwapInput()”又被调用了一次,这意味着攻击者又进行了一次将imBTC兑换成ETH的交易(当兑换比率被攻击者操纵至对其有利的水平时)。
 
Lendf.Me攻击事件
针对于Lendf.ME的黑客事件作用机制有所不同,但是本质上是一样的。
如果我们研究下以下恶意交易:(hash: 0xae7d664bdfcc54220df4f18d339005c6faf6e62c9ca79c56387bc0389274363b),
由于在存入函数中,Lendf.Me中的“supply()”函数被嵌入一个额外的提现(withdraw())函数钩子(hook),这导致攻击者可以在不实际存入资产的情况下,伪造其imBTC抵押品余额的内部记录。
 
攻击者确实首先向Lendf.Me提供了确定数量的imBTC(即289.999999999 imBTC)。然而在第二个“supply()”中,攻击者仅实际提供了0.000000001个imBTC,并且其后来通过“withdraw()”的钩子又取出了290 imBTC(攻击者黑入了“dotransferIn()”中“imBTC:transferFrom()”的调用——1583行)。从而使得290imBTC在钩子函数“withdraw()”中从攻击者的余额中成功扣除。然而,当代码又回执至“supply”时,余额又被重置为290imBTC(1599行)。这就是攻击者如何在lendf.Me中操纵imBTC抵押品余额数量的内在逻辑。通过多次上述操作,攻击者将其在Lendf.Me中的imBTC内部记录刷到了足够从多个流动池(总资产价值为25,236,849.44美元)中借出可用的10多种资产。
 
缓解措施
作为阻止这种重入攻击的缓解机制,Checks-Effects-Interactions确实能够在这两个事件中起到帮助。如果Lendf.Me“supply()”在存储用户的代币余额更新后调用“doTransferIn()”,攻击者就不可能通过调用“withdraw()”重置余额记录。
从另一角度分析,ERC777原生地支持钩子(hook)机制的运行,因此我们需要防止其所有交易类型的重入攻击。比如,如果“supply()”和“withdraw()”都在函数起始部分设有互斥锁,那么攻击者就不可能使用“supply()”中的“withdraw()”。最后但同样重要的是,我们需要重新回顾一下在ERC20与 ERC777之间进行选择时,选择ERC777正是考虑到其能更好的保护用户资产(因为每次交易操作时,不需要用户将所有的Token都授权给平台)。
写在最后
Lendf.Me黑客事件对于当前的DeFi社区而言确实是一个打击。在下面的图片中我们收集了在该事件中各项资产的损失额数据。
PeckShield   作者
子铭   翻译

Edward   编辑

链得得仅提供相关信息展示,不构成任何投资建议
本文系作者 加密谷Live 授权链得得发表,并经链得得编辑,转载请注明出处、作者和本文链接

更多精彩内容,关注链得得微信号(ID:ChainDD),或者下载链得得App

分享到:

相关推荐

    评论(0

    Oh! no

    您是否确认要删除该条评论吗?

    分享到微信