KEN:慢雾:详解Uniswap的ERC777重入风险_TOKE

编者按:本文来自慢雾科技,Odaily星球日报授权转载。

前言

据链闻消息,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函数来控制和拒绝发送哪些token3、合约和普通地址都可以通过注册tokensReceivedhook函数来控制和拒绝接受哪些token4、tokensReceived可以通过hook函数可以做到在一个交易里完成发送代币和通知合约接受代币,而不像ERC20必须通过两次调用来完成5、持有者可以"授权"和"撤销"操作员这些操作员通常是交易所、支票处理机或自动支付系统6、每个代币交易都包含data和operatorData字段,可以分别传递来自持有者和操作员的数据7、可以通过部署实现tokensReceived的代理合约来兼容没有实现tokensReceived函数的地址在这里,我们需要特别关注的点是第二点,即ERC777标准中的tokenToSend函数,根据ERC777协议的定义,遵循该标准的token代币在每一次发生代币转账的时候都会去尝试调用代币发送者tokensToSend函数,而代币持有者可以通过在ERC1820注册合约注册自己的合约并通过在这个hook函数中定义一些操作来处理代币转账的过程中的某些流程,如拒绝代币发送或其他操作。了解这些关键点,有助于我们理解这次攻击的具体攻击手法。现在开始,我们可以稍微加速,看看对于Uniswap而言,这次到底发生了什么?细节分析

慢雾:JPEG'd攻击者或已将全部6106.75枚ETH归还给项目方:8月4日消息,慢雾MistTrack监测显示,JPEG'd攻击者或已将全部6106.75枚ETH归还给项目方。[2023/8/4 16:18:46]

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

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

慢雾:仍有大部分钱包支持eth_sign,仅少部分钱包提供安全风险警告:金色财经报道,在加密货币NFT板块,越来越多的钓鱼网站滥用 eth_sign 签名功能来进行盲签欺诈,提醒或禁用这种低级的签名方法对于保护用户安全是至关重要的,不少 Web3 钱包已经采取相关措施来对这种危险的签名方法进行安全提示和限制。仍有一大部分加密钱包支持 eth_sign,其中少部分钱包提供 eth_sign 安全风险警告。如果用户仍想要使用 eth_sign,他们可以选择支持该功能的加密钱包。但是,用户在使用这些钱包时需要特别注意安全警告,以确保其交易的安全性。[2023/5/11 14:57:14]

通过查询交易的细节,我们发现,攻击者首先是通过ethToTokenSwapInput函数向Uniswap兑换了一些imBTC,然后再通过tokenToEthSwapInput函数开始第一次用imBTC换取ETH,然后Uniswap先将ETH转给了攻击者,再调用imBTC的transferFrom函数,由于imBTC实现了ERC777标准,所以在调用imBTC的trasferFrom函数的时候,imBTC会对攻击者的tokensToSend函数进行调用。随后,在攻击者的tokensToSend函数中,攻击者会进行第二次用imBTC换取ETH,然后流程结束。从交易细节上看,这里似乎还是没有什么问题,我们继续跟踪UniSwap的代码。

慢雾:Rubic协议错将USDC添至Router白名单,导致已授权合约用户USDC遭窃取:12月25日消息,据慢雾安全团队情报,Rubic跨链聚合器项目遭到攻击,导致用户账户中的USDC被窃取。慢雾安全团队分享如下:1. Rubic是一个DEX跨链聚合器,用户可以通过RubicProxy合约中的routerCallNative函数进行Native Token兑换。在进行兑换前,会先检查用户传入的所需调用的目标 Router是否在协议的白名单中。

2. 经过白名单检查后才会对用户传入的目标Router进行调用,调用数据也由用户外部传入。

3. 不幸的是USDC也被添加到Rubic协议的Router白名单中,因此任意用户都可以通过RubicProxy合约任意调用USDC。

4. 恶意用户利用此问题通过routerCallNative函数调用USDC合约将已授权给RubicProxy合约的用户的USDC通过transferFrom接口转移至恶意用户账户中。

此次攻击的根本原因在于Rubic协议错误的将USDC添加进Router白名单中,导致已授权给RubicProxy合约的用户的USDC被窃取。[2022/12/26 22:07:00]

慢雾:Crosswise遭受攻击因setTrustedForwarder函数未做权限限制:据慢雾区情报,2022年1月18日,bsc链上Crosswise项目遭受攻击。慢雾安全团队进行分析后表示,此次攻击是由于setTrustedForwarder函数未做权限限制,且在获取调用者地址的函数_msg.sender()中,写了一个特殊的判断,导致后续owner权限被转移以及后续对池子的攻击利用。[2022/1/19 8:57:48]

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

慢雾:PAID Network攻击者直接调用mint函数铸币:慢雾科技发文对于PAID Network遭攻击事件进行分析。文章中指出,在对未开源合约进行在反编译后发现合约的 mint 函数是存在鉴权的,而这个地址,正是攻击者地址(0x187...65be)。由于合约未开源,无法查看更具体的逻辑,只能基于现有的情况分析。慢雾科技分析可能是地址(0x187...65be)私钥被盗,或者是其他原因,导致攻击者直接调用 mint 函数进行任意铸币。

此前报道,PAID Network今天0点左右遭到攻击,增发将近6000万枚PAID代币,按照当时的价格约为1.6亿美元,黑客从中获利2000ETH。[2021/3/6 18:21:08]

通过分析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-3:883ms