前言
4 月 18 日，Tokenlon 宣布暂停 imBTC 转账，因其发现有攻击者通过 ERC777 在 Uniswap 流动性合约中的重入漏洞，对 ETH-imBTC 池循环套利。此次的攻击手法是一个存在于 Uniswap v1 上的已知漏洞，该漏洞最早由 Consensys 于 2019 年 4 月发现，当时 Consensys 只是发现了该风险，还没有发现可以利用这种手法进行攻击的 token。随后，在 imBTC 上线 Uniswap 后，由于 imBTC 是基于 ERC777 实现的，通过组合 ERC777 的特性及 Uniswap 代码上的问题，使攻击者可以通过重入漏洞实现套利。下面，我们将来分析此次套利中的攻击手法和具体的细节。
知识准备
ERC777 协议是以太坊上的代币标准协议，该协议是以太坊上 ERC20 协议的改进版，主要的改进点如下：
1. 使用和发送以太相同的理念发送 token，方法为：send(dest, value, data)
2. 合约和普通地址都可以通过注册 tokensToSend hook 函数来控制和拒绝发送哪些token（拒绝发送通过在hook函数tokensToSend 里 revert 来实现）
慢雾：Grafana存在账户被接管和认证绕过漏洞:金色财经报道，据慢雾消息，Grafana发布严重安全提醒，其存在账户被接管和认证绕过漏洞(CVE-2023-3128)，目前PoC在互联网上公开，已出现攻击案例。Grafana是一个跨平台、开源的数据可视化网络应用程序平台，用户配置连接的数据源之后，Grafana可以在网络浏览器里显示数据图表和警告。Grafana根据电子邮件的要求来验证Azure Active Directory账户。在Azure AD上，配置文件的电子邮件字段在Azure AD租户之间是不唯一的。当Azure AD OAuth与多租户Azure AD OAuth应用配置在一起时，这可能会使Grafana账户被接管和认证绕过。其中，Grafana>=6.7.0受到影响。加密货币行业有大量平台采用此方案用来监控服务器性能情况，请注意风险，并将Grafana升级到最新版本。[2023/6/25 21:58:31]
3. 合约和普通地址都可以通过注册 tokensReceived hook 函数来控制和拒绝接受哪些token（拒绝接受通过在hook函数tokensReceived 里 revert 来实现）
4. tokensReceived 可以通过 hook 函数可以做到在一个交易里完成发送代币和通知合约接受代币，而不像 ERC20 必须通过两次调用（approve/transferFrom）来完成
慢雾：Transit Swap黑客攻击交易被抢跑，套利机器人获利超100万美元:10月1日消息，据慢雾安全团队情报，Transit Swap 黑客转移用户 BSC 链 BUSD 资产时被套利机器人抢跑，区块高度为21816885，获利107万BUSD。套利机器人相关地址列表如下：0xa957...70d2、0x90b5...8ff4、0xcfb0...7ac7、
截止到目前，在各方的共同努力下，黑客已将 70% 左右的被盗资产退还到Transit Swap开发者地址，建议套利机器人所属人同样通过service/img/2022811200052/0.jpg">可以发现，攻击者两度向 Uniswap 合约转帐 imBTC，金额同样是 0.00823084，然后从 Uniswap 收取了两笔 ETH，看上去似乎是十分正常的两笔交易，实际上却是暗流涌动，另有玄机。为了更好的了解整一笔交易的细节，我们需要通过 bloxy.info 来查看交易的具体细节。
声音 | 慢雾：警惕“假充值”攻击:慢雾分析预警，如果数字货币交易所、钱包等平台在进行“EOS 充值交易确认是否成功”的判断存在缺陷，可能导致严重的“假充值”。攻击者可以在未损失任何 EOS 的前提下成功向这些平台充值 EOS，而且这些 EOS 可以进行正常交易。
慢雾安全团队已经确认真实攻击发生，但需要注意的是：EOS 这次假充值攻击和之前慢雾安全团队披露过的 USDT 假充值、以太坊代币假充值类似，更多责任应该属于平台方。由于这是一种新型攻击手法，且攻击已经在发生，相关平台方如果对自己的充值校验没有十足把握，应尽快暂停 EOS 充提，并对账自查。[2019/3/12]
从交易细节上看，这里似乎还是没有什么问题，我们继续跟踪 UniSwap 的代码。
上面是代码是 Uniswap 的 ethToTokenSwapInput 函数的代码，根据代码分析， Uniswap 的 ethToTokenSwapInput 函数会调用 ethToTokenInput 函数，然后会先通过 getInputPrice 获取代币能换取的 eth 数量，之后通过 send 函数将 eth 发给用户，最后再通过 transferFrom 把代币转进合约。我们继续跟进 getInputPrice 函数。
通过分析 getInputPrice 函数，我们能知道，ETH 获取量计算的公式为
把该公式放到 ethToTokenInput 函数的上下文中，该公式就变成了
防御方法
1. 在 Uniswap 的 tokenToEthSwapInput 函数中加入 OpenZeppelin 的 ReentrancyGuard 函数，防止重入问题。
2. 在进行代币交换的时候，先扣除用户的代币，再将 ETH 发送给用户。
同时，针对本次攻击事件慢雾安全团队建议：
1. 在关键的业务操作方法中加入锁机制，如：OpenZeppelin 的 ReentrancyGuard
2. 开发合约的时候采用先更改本合约的变量，再进行外部调用的编写风格
3. 项目上线前请优秀的第三方安全团队进行全面的安全审计，尽可能的发现潜在的安全问题
4. 多个合约进行对接的时候也需要对多方合约进行代码安全和业务安全的把关，全面考虑各种业务场景相结合下的安全问题
5. 合约尽可能的设置暂停开关，在出现“黑天鹅”事件的时候能够及时发现并止损
6. 安全是动态的，各个项目方也需要及时捕获可能与自身项目相关的威胁情报，及时排查潜在的安全风险
最后的思考
这两天的 DeFi 世界被闹得沸沸扬扬，imBTC 作为 ERC777 代币首当其冲，ERC777 协议也饱受诟病，但是看完分析，造成此次的攻击事件原因，真的是 imBTC 或者是 ERC777 协议的问题吗？
如果 Uniswap 做好了 ERC777 的兼容，使用 ReentrancyGuard，并在代币交换的时候先扣除用户的代币，再将 ETH 发送给用户，这样的问题是不是就不会发生？
imBTC 作为 以太坊上 token 化的比特币代币协议，其安全性在自身单独运行的时候并不存在问题，第三方 DeFi 平台在接入的时候，应需要充分考虑平台本身的业务逻辑与接入代币之间的兼容性，才能避免因兼容性发生不必要的安全问题。而不是简单的将问题归咎于协议和代币提供方。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。