Uniswap的ERC777重入风险:详解本次ETH-imBTC套利的攻击手法及具体细节_TOKEN:IMBTC

编者注:原标题为《详解Uniswap的ERC777重入风险》

前言

据媒体消息,4月18日,Tokenlon宣布暂停imBTC转账,因其发现有攻击者通过ERC777在Uniswap流动性合约中的重入漏洞,对ETH-imBTC池循环套利。此次的攻击手法是一个存在于Uniswapv1上的已知漏洞,该漏洞最早由Consensys于2019年4月发现,当时Consensys只是发现了该风险,还没有发现可以利用这种手法进行攻击的token。随后,在imBTC上线Uniswap后,由于imBTC是基于ERC777实现的,通过组合ERC777的特性及Uniswap代码上的问题,使攻击者可以通过重入漏洞实现套利。下面,我们将来分析此次套利中的攻击手法和具体的细节。

知识准备

ERC777协议是以太坊上的代币标准协议,该协议是以太坊上ERC20协议的改进版,主要的改进点如下:

1、使用和发送以太相同的理念发送token,方法为:send(dest,value,data)

2、合约和普通地址都可以通过注册tokensToSendhook函数来控制和拒绝发送哪些token

Maker将对LINK-A、MATIC-A、YFI-A 和 UNIV2USDCETH-A金库部署新参数:金色财经报道,MakerDAO通过社交媒体透露将对LINK-A、MATIC-A、YFI-A 和 UNIV2USDCETH-A金库部署新参数,包括将清算罚款设置为0%,将Tip参数设置为0,将chip参数设置为0,将清算比率设置为10,000%。一旦这些新的参数被部署到Maker协议,所有抵押率低于10,000%的LINK-A、MATIC-A、YFI-A和UNIV2USDCETH-A的头寸将被清算。[2023/5/21 15:16:42]

3、合约和普通地址都可以通过注册tokensReceivedhook函数来控制和拒绝接受哪些token

4、tokensReceived可以通过hook函数可以做到在一个交易里完成发送代币和通知合约接受代币,而不像ERC20必须通过两次调用来完成

5、持有者可以"授权"和"撤销"操作员?这些操作员通常是交易所、支票处理机或自动支付系统

6、每个代币交易都包含data和operatorData字段,可以分别传递来自持有者和操作员的数据

数据:Uniswap v3在BNB Chain部署一周后,交易量突破5000万美元:金色财经报道,Uniswap v3已在BNB Chain部署一周,目前协议交易量突破5000万美元,约为5330万美元。[2023/3/24 13:22:49]

7、可以通过部署实现tokensReceived的代理合约来兼容没有实现tokensReceived函数的地址

在这里,我们需要特别关注的点是第二点,即ERC777标准中的tokenToSend函数,根据ERC777协议的定义,遵循该标准的token代币在每一次发生代币转账的时候都会去尝试调用代币发送者tokensToSend函数,而代币持有者可以通过在ERC1820注册合约注册自己的合约并通过在这个hook函数中定义一些操作来处理代币转账的过程中的某些流程,如拒绝代币发送或其他操作。

了解这些关键点,有助于我们理解这次攻击的具体攻击手法。现在开始,我们可以稍微加速,看看对于Uniswap而言,这次到底发生了什么?

细节分析

通过Etherscan查询攻击者的其中一笔交易?0x32c83905db61047834f29385ff8ce8cb6f3d24f97e24e6101d8301619efee96e

Maker:G-UNI代币现在占所有Dai抵押品的12.4%:6月25日消息,Maker协议表示,G-UNI代币现在占所有Dai抵押品的12.4%,ETH-A、ETH-B和ETH-C分别为6.9%、6.6%和6.8%。WBTC-A 现在是最大的易变资产资金库类型。系统超额抵押率为134.92%。[2022/6/25 1:30:55]

可以发现,攻击者两度向Uniswap合约转帐imBTC,金额同样是0.00823084,然后从Uniswap收取了两笔ETH,看上去似乎是十分正常的两笔交易,实际上却是暗流涌动,另有玄机。为了更好的了解整一笔交易的细节,我们需要通过bloxy.info来查看交易的具体细节。

通过查询交易的细节,我们发现,攻击者首先是通过ethToTokenSwapInput函数向Uniswap兑换了一些imBTC,然后再通过tokenToEthSwapInput函数开始第一次用imBTC换取ETH,然后Uniswap先将ETH转给了攻击者,再调用imBTC的transferFrom函数,由于imBTC实现了ERC777标准,所以在调用imBTC的trasferFrom函数的时候,imBTC会对攻击者的tokensToSend函数进行调用。随后,在攻击者的tokensToSend函数中,攻击者会进行第二次用imBTC换取ETH,然后流程结束。

Polygon 期待 Uniswap V3 部署至该网络,已在社区提议:11月21日消息,Polygon 联合创始人 Mihailo Bjelic 在 Uniswap 论坛中提议将 Uniswap V3 部署至 Polygon PoS 链。他认为 Polygon 是目前仅次于以太坊主网的 DeFi 生态系统,而且他们也希望激励 Uniswap 的采用率。[2021/11/21 7:02:46]

从交易细节上看,这里似乎还是没有什么问题,我们继续跟踪UniSwap的代码。

上面是代码是Uniswap的ethToTokenSwapInput函数的代码,根据代码分析,Uniswap的ethToTokenSwapInput函数会调用ethToTokenInput函数,然后会先通过getInputPrice获取代币能换取的eth数量,之后通过send函数将eth发给用户,最后再通过transferFrom把代币转进合约。我们继续跟进getInputPrice函数。

Yearn.Finance核心开发者:已将Uniswap和Sushiswap LP添加到白名单:Yearn.Finance中文站发微博称,核心开发者banteg表示,已将Uniswap和Sushiswap LP添加到白名单。它涵盖了YFI的所有有效益用途,现在还剩下Gas费优化调整。 ???[2020/11/28 22:23:50]

通过分析getInputPrice函数,我们能知道,ETH获取量计算的公式为

把该公式放到ethToTokenInput函数的上下文中,该公式就变成了

在该公式下,一次正常的imBTC兑换ETH的过程中,作为分母的imBTC储备量在兑换过后应该要上升,对应的ETH储备量会变小。

但是回顾攻击者的操作方式,在攻击者第一次发送imBTC兑换ETH的过程中,Uniswap会先发送ETH给攻击者,这时候Uniswap中ETH储备量减少,然后Uniswap调用transferFrom函数,(注意此时还未将攻击者的imBTC扣除),紧接着在transferFrom函数中攻击者调用的第二次的ethToTokenSwapInput时,通过getInputPrice获取兑换的ETH数量的公式会变成这样:

注意看,在第二次的兑换计算中,只有ETH的储备量变少了,而imBTC的储备量并未增加,这导致相比与单独的调用ethToTokenSwapInput函数,攻击者可以通过重入的方式,在第二次使用imBTC兑换ETH的过程中,使计算公式的分子发生了变化,而公式的分母不会发生变化。相比正常的兑换,攻击者通过重入方式进行的第二次兑换会获取微小的利润,导致有利可图。重复这样的过程,就能通过等量的imBTC获取更多的ETH,导致Uniswap做事商的损失。

防御方法

在Uniswap的tokenToEthSwapInput函数中加入OpenZeppelin的ReentrancyGuard函数,防止重入问题。

在进行代币交换的时候,先扣除用户的代币,再将ETH发送给用户。

同时,针对本次攻击事件慢雾安全团队建议:

在关键的业务操作方法中加入锁机制,如:OpenZeppelin的ReentrancyGuard

开发合约的时候采用先更改本合约的变量,再进行外部调用的编写风格

项目上线前请优秀的第三方安全团队进行全面的安全审计,尽可能的发现潜在的安全问题

多个合约进行对接的时候也需要对多方合约进行代码安全和业务安全的把关,全面考虑各种业务场景相结合下的安全问题

合约尽可能的设置暂停开关,在出现“黑天鹅”事件的时候能够及时发现并止损

安全是动态的,各个项目方也需要及时捕获可能与自身项目相关的威胁情报,及时排查潜在的安全风险

最后的思考

这两天的DeFi世界被闹得沸沸扬扬,imBTC作为ERC777代币首当其冲,ERC777协议也饱受诟病,但是看完分析,造成此次的攻击事件原因,真的是imBTC或者是ERC777协议的问题吗?

如果Uniswap做好了ERC777的兼容,使用ReentrancyGuard,并在代币交换的时候先扣除用户的代币,再将ETH发送给用户,这样的问题是不是就不会发生?

imBTC作为以太坊上token化的比特币代币协议,其安全性在自身单独运行的时候并不存在问题,第三方DeFi平台在接入的时候,应需要充分考虑平台本身的业务逻辑与接入代币之间的兼容性,才能避免因兼容性发生不必要的安全问题。而不是简单的将问题归咎于协议和代币提供方。

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

金智博客

[0:15ms0-7:295ms