ETH:慢雾：详解Uniswap的ERC777重入风险

编者按：本文来自慢雾科技，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而言，这次到底发生了什么？细节分析

慢雾：利用者通过执行恶意提案控制了Tornado.Cash的治理:金色财经报道，SlowMist发布Tornado.Cash治理漏洞解析。 5月20日，Tornado.Cash遭受了治理攻击，利用者通过执行恶意提案控制了Tornado.Cash的治理。5月13日，利用者发起了20提案，并在提案中说明20提案是对16提案的补充，具有相同的执行逻辑。但实际上，提案合约多了一个自毁逻辑，其创建者是通过create2创建的，具有自毁功能，所以在与提案合约自毁后，利用者仍可以部署不同的以与以前相同的方式将字节码发送到相同的地址。不幸的是，社区没有看到拟议合约中的犯规行为，许多用户投票支持该提案。

在5月18日，利用者通过创建具有多个交易的新地址，反复将0代币锁定在治理中。利用提案合约可以销毁并重新部署新逻辑的特性，利用者在5月20日7:18（UTC）销毁了提案执行合约，并在同一地址部署了一个恶意合约，其逻辑是修改用户在治理中锁定的代币数量。

攻击者修改完提案合约后，于5月20日7:25（UTC）执行恶意提案合约。该提案的执行是通过 Delegatecall 执行的，因此，该提案的执行导致治理合约中由开发者控制的地址的代币锁定量被修改为 10,000。提案执行完成后，攻击者从治理库中解锁了TORN代币。金库中的TORN代币储备已经耗尽，同时利用者控制了治理。[2023/5/21 15:17:00]

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

慢雾：警惕针对 Blur NFT 市场的批量挂单签名“零元购”钓鱼风险:金色财经报道，近期，慢雾生态安全合作伙伴 Scam Sniffer 演示了一个针对 Blur NFT 市场批量挂单签名的“零元购”钓鱼攻击测试，通过一个如图这样的“Root 签名”即可以极低成本（特指“零元购”）钓走目标用户在 Blur 平台授权的所有 NFT，Blur 平台的这个“Root 签名”格式类似“盲签”，用户无法识别这种签名的影响。慢雾安全团队验证了该攻击的可行性及危害性。特此提醒 Blur 平台的所有用户警惕，当发现来非 Blur 官方域名(blur.io)的“Root 签名”，一定要拒绝，避免潜在的资产损失。[2023/3/7 12:46:39]

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

慢雾：Equalizer Finance被黑主要在于FlashLoanProvider合约与Vault合约不兼容:据慢雾区消息，6 月 7 日，Equalizer Finance 遭受闪电贷攻击。慢雾安全团队以简讯形式将攻击原理分享如下：

1. Equalizer Finance 存在 FlashLoanProvider 与 Vault 合约，FlashLoanProvider 合约提供闪电贷服务，用户通过调用 flashLoan 函数即可通过 FlashLoanProvider 合约从 Vault 合约中借取资金，Vault 合约的资金来源于用户提供的流动性。

2. 用户可以通过 Vault 合约的 provideLiquidity/removeLiquidity 函数进行流动性提供/移除，流动性提供获得的凭证与流动性移除获得的资金都受 Vault 合约中的流动性余额与流动性凭证总供应量的比值影响。

3. 以 WBNB Vault 为例攻击者首先从 PancekeSwap 闪电贷借出 WBNB

4. 通过 FlashLoanProvider 合约进行二次 WBNB 闪电贷操作，FlashLoanProvider 会先将 WBNB Vault 合约中 WBNB 流动性转给攻击者，随后进行闪电贷回调。

5. 攻击者在二次闪电贷回调中，向 WBNB Vault 提供流动性，由于此时 WBNB Vault 中的流动性已经借出一部分给攻击者，因此流动性余额少于预期，则攻击者所能获取的流动性凭证将多于预期。

6. 攻击者先归还二次闪电贷，然后从 WBNB Vault 中移除流动性，此时由于 WBNB Vault 中的流动性已恢复正常，因此攻击者使用添加流动性获得凭证所取出的流动性数量将多于预期。

7. 攻击者通过以上方式攻击了在各个链上的 Vault 合约，耗尽了 Equalizer Finance 的流动性。

此次攻击的主要原因在于 Equalizer Finance 协议的 FlashLoanProvider 合约与 Vault 合约不兼容。慢雾安全团队建议协议在进行实际实现时应充分考虑各个模块间的兼容性。[2022/6/8 4:09:22]

慢雾：Avalanche链上Zabu Finance被黑简析:据慢雾区情报，9月12日，Avalanche上Zabu Finance项目遭受闪电贷攻击，慢雾安全团队进行分析后以简讯的形式分享给大家参考：

1.攻击者首先创建两个攻击合约，随后通过攻击合约1在Pangolin将WAVAX兑换成SPORE代币，并将获得的SPORE代币抵押至ZABUFarm合约中，为后续获取ZABU代币奖励做准备。

2.攻击者通过攻击合约2从Pangolin闪电贷借出SPORE代币，随后开始不断的使用SPORE代币在ZABUFarm合约中进行`抵押/提现`操作。由于SPORE代币在转账过程中需要收取一定的手续费(SPORE合约收取)，而ZABUFarm合约实际接收到的SPORE代币数量是小于攻击者传入的抵押数量的。分析中我们注意到ZABUFarm合约在用户抵押时会直接记录用户传入的抵押数量，而不是记录合约实际收到的代币数量，但ZABUFarm合约在用户提现时允许用户全部提取用户抵押时合约记录的抵押数量。这就导致了攻击者在抵押时ZABUFarm合约实际接收到的SPORE代币数量小于攻击者在提现时ZABUFarm合约转出给攻击者的代币数量。

3.攻击者正是利用了ZABUFarm合约与SPORE代币兼容性问题导致的记账缺陷，从而不断通过`抵押/提现`操作将ZABUFarm合约中的SPORE资金消耗至一个极低的数值。而ZABUFarm合约的抵押奖励正是通过累积的区块奖励除合约中抵押的SPORE代币总量参与计算的，因此当ZABUFarm合约中的SPORE代币总量降低到一个极低的数值时无疑会计算出一个极大的奖励数值。

4.攻击者通过先前已在ZABUFarm中有进行抵押的攻击合约1获取了大量的ZABU代币奖励，随后便对ZABU代币进行了抛售。

此次攻击是由于ZabuFinance的抵押模型与SPORE代币不兼容导致的，此类问题导致的攻击已经发生的多起，慢雾安全团队建议：项目抵押模型在对接通缩型代币时应记录用户在转账前后合约实际的代币变化，而不是依赖于用户传入的抵押代币数量。[2021/9/12 23:19:21]

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

慢雾: 警惕比特币RBF风险:据BitMEX消息，比特币于区块高度666833出现陈腐区块，并产生了一笔 0.00062063 BTC 的双花交易。根据 BitMEX提供的交易内容来看，双花的两笔交易的nSequence字段的值都小于0xffffffff -1。慢雾安全团队初步认为此次双花交易有可能是比特币中的RBF交易。[2021/1/20 16:38:01]

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

通过分析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平台在接入的时候，应需要充分考虑平台本身的业务逻辑与接入代币之间的兼容性，才能避免因兼容性发生不必要的安全问题。而不是简单的将问题归咎于协议和代币提供方。

标签：ETHSWAPTOKENTOKEreth币暴跌NFTSwapsiTokenHello Art Token

比特币交易所热门资讯