据链闻消息,著名DeFi项目Furucombo被黑,损失超1500万美元。慢雾安全团队第一时间介入分析,并将攻击细节分享给大家。攻击细节分析
本次发生问题的合约在Furucombo本身的代理合约当中。整个攻击流程很简单。攻击者通过设置了Furucombo的AaveV2Proxy的逻辑地址导致后续通过Furucombo代理合约调用的逻辑全部转发到攻击者自己的恶意合约上,导致任意资金被盗。
慢雾:Apple Store恶意钓鱼程序可模仿正常应用程序,盗取账号密码以绕过2FA:7月25日消息,慢雾首席信息安全官23pds发推提醒用户注意Apple ID出现的最新攻击案例,其中Apple Store出现恶意钓鱼程序,通过模仿正常应用程序盗取用户账号和密码,然后攻击者把自己的号码加入双重认证的信任号码,控制账号权限,用来绕过苹果的2FA。“加密货币用户务必注意,因为目前有不少用户、钱包的备份方案是iCloud备份,一旦被攻击,可能造成资产损失”。[2023/7/25 15:56:56]
但是如果事情那么简单,那么本次分析不值一提。问题远比想象的复杂得多。如上图所示攻击者的入口在Furucombo的batchExec函数,我们先对batchExec函数进行分析:
慢雾:6月24日至28日Web3生态因安全问题损失近1.5亿美元:7月3日消息,慢雾发推称,自6月24日至6月28日,Web3生态因安全问题遭遇攻击损失149,658,500美元,包括Shido、Ichioka Ventures、Blockchain for dog nose wrinkles、Chibi Finance、Biswap、Themis等。[2023/7/3 22:14:33]
以上是FurucomboProxy合约的batchExec函数的具体实现,其中_preProcess和_postProcess合约分别是对调用前后做一些数据上的处理,不涉及具体的调用逻辑,这边可以先忽略。我们主要观察核心的_execs函数:
慢雾:Transit Swap事件中转移到Tornado Cash的资金超过600万美元:金色财经报道,慢雾 MistTrack 对 Transit Swap 事件资金转移进行跟进分析,以下将分析结论同步社区:
Hacker#1 攻击黑客(盗取最大资金黑客),获利金额:约 2410 万美元
1: 0x75F2...FFD46
2: 0xfa71...90fb
已归还超 1890 万美元的被盗资金;12,500 BNB 存款到 Tornado Cash;约 1400 万 MOONEY 代币和 67,709 DAI 代币转入 ShibaSwap: BONE Token 合约地址。
Hacker#2 套利机器人-1,获利金额:1,166,882.07 BUSD
0xcfb0...7ac7(BSC)
保留在获利地址中,未进一步转移。
Hacker#3 攻击模仿者-1,获利金额:356,690.71 USDT
0x87be...3c4c(BSC)
Hacker#4 套利机器人-2,获利金额:246,757.31 USDT
0x0000...4922(BSC)
已全部追回。
Hacker#5 套利机器人-3,获利金额:584,801.17 USDC
0xcc3d...ae7d(BSC)
USDC 全部转移至新地址 0x8960...8525,后无进一步转移。
Hacker#6 攻击模仿者-2,获利金额:2,348,967.9 USDT
0x6e60...c5ea(BSC)
Hacker#7 套利机器人-4,获利金额:5,974.52 UNI、1,667.36 MANA
0x6C6B...364e(ETH)
通过 Uniswap 兑换为 30.17 ETH,其中 0.71 支付给 Flashbots,剩余 ETH 未进一步转移。[2022/10/6 18:41:10]
通过对execs代码的分析不难发现,函数的主要逻辑是对configs数组的数据做检查,并根据configs数组的数据对data进行一些处理。但是回顾上文中攻击者的调用数据,不难发现攻击者的调用数据中,configs的数据是一个0地址:
慢雾:攻击者系通过“supply()”函数重入Lendf.Me合约 实现重入攻击:慢雾安全团队发文跟进“DeFi平台Lendf.Me被黑”一事的具体原因及防御建议。文章分析称,通过将交易放在bloxy.info上查看完整交易流程,可发现攻击者对Lendf.Me进行了两次“supply()”函数的调用,但是这两次调用都是独立的,并不是在前一笔“supply()”函数中再次调用“supply()”函数。紧接着,在第二次“supply()”函数的调用过程中,攻击者在他自己的合约中对Lendf.Me的“withdraw()”函数发起调用,最终提现。慢雾安全团队表示,不难分析出,攻击者的“withdraw()”调用是发生在transferFrom函数中,也就是在Lendf.Me通过transferFrom调用用户的“tokensToSend()”钩子函数的时候调用的。很明显,攻击者通过“supply()”函数重入了Lendf.Me合约,造成了重入攻击。[2020/4/19]
动态 | 慢雾:10 月发生多起针对交易所的提币地址劫持替换攻击:据慢雾区块链威胁情报(BTI)系统监测及慢雾 AML 数据显示,过去的 10 月里发生了多起针对数字货币交易所的提币地址劫持替换攻击,手法包括但不限于:第三方 JS 恶意代码植入、第三方 NPM 模块污染、Docker 容器污染。慢雾安全团队建议数字货币交易所加强风控措施,例如:1. 密切注意第三方 JS 链接风险;2. 提币地址应为白名单地址,添加时设置双因素校验,用户提币时从白名单地址中选择,后台严格做好校验。此外,也要多加注意内部后台的权限控制,防止内部作案。[2019/11/1]
这里有一个trick,由于0地址是一个EOA地址,所有对EOA地址的函数调用都会成功,但是不会返回任何结果。结合这个trick,execs函数中的关于configs数据的部分可以先暂时忽略。直接看到最后的核心_exec函数:
_exec函数的逻辑也很简单,在校验了_to地址后,直接就将data转发到指定的_to地址上了。而通过对攻击交易的分析,我们能发现这个_to地址确实是官方指定的合法地址。
最后一步,便是调用_to地址,也就是官方指定的AaveV2Proxy合约的initialize函数,将攻击者自己的恶意地址设置成AaveV2Proxy合约的逻辑地址。通过对Furucombo合约的分析,可以发现整个调用流程上没有出现严重的安全点,对调用的地址也进行了白名单的检查。那么问题只能是出在了对应要调用的代理逻辑上,也就是AaveV2Proxy合约。我们直接分析AaveV2Proxy合约的initialize函数的逻辑:
可以看到initialize函数是一个public函数,并在开头就检查了_implementation是否是0地址,如果是0地址,则抛出错误。这个检查的目的其实就是检查了_implementation是否被设置了,如果被设置了,就无法再次设置。根据这个设置,不难想出initialize这个函数只能调用一次。除非AaveV2Proxy从来没有设置过_implementation,否则这个调用是不会成功的。难道Furucombo真的没有设置过对应的_implementation吗?带着这样的疑问,我们检查了交易内的状态变化。如下:
可以看到,交易中改变了存储位置为0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc的内容,而写入的内容正是攻击者自己的恶意合约地址0x86765dde9304bea32f65330d266155c4fa0c4f04。而0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc这个位置,正是_implementation数据的存储地址。
也就是说,官方从来没有设置过AaveV2Proxy合约的_implementation地址,导致攻击者钻了这个空子,造成了Furucombo资产损失。总结
通过对整个事件的分析来看,Furucombo此次事故并不在安全漏洞的范畴内,主要的原因在于官方将未启用的AaveV2Proxy合约添加进了自己的白名单中,并且未对AaveV2Proxy合约进行初始化,导致攻击者有机可乘。建议
目前,由于Furucombo遭受攻击,导致任何将代币授权过给Furucombo合约(0x17e8ca1b4798b97602895f63206afcd1fc90ca5f)的用户都将面临资金损失的风险。慢雾安全团队建议与Furucombo交互过的用户检查是否有将相关代币授权给Furucombo合约。如有授权,应及时撤销相关授权,避免进一步损失。参考链接:代币授权检查地址:https://approved.zone/攻击交易:https://ethtx.info/mainnet/0x6a14869266a1dcf3f51b102f44b7af7d0a56f1766e5b1908ac80a6a23dbaf449
郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。