据链闻消息，著名DeFi项目Furucombo被黑，损失超1500万美元。慢雾安全团队第一时间介入分析，并将攻击细节分享给大家。攻击细节分析
本次发生问题的合约在Furucombo本身的代理合约当中。整个攻击流程很简单。攻击者通过设置了Furucombo的AaveV2Proxy的逻辑地址导致后续通过Furucombo代理合约调用的逻辑全部转发到攻击者自己的恶意合约上，导致任意资金被盗。
慢雾：Poly Network再次遭遇黑客攻击，黑客已获利价值超439万美元的主流资产:金色财经报道，据慢雾区情报，Poly Network再次遭遇黑客攻击。分析发现，主要黑客获利地址为0xe0af…a599。根据MistTrack团队追踪溯源分析，ETH链第一笔手续费为Tornado Cash: 1 ETH，BSC链手续费来源为Kucoin和ChangeNOW，Polygon链手续费来源为FixedFloat。黑客的使用平台痕迹有Kucoin、FixedFloat、ChangeNOW、Tornado Cash、Uniswap、PancakeSwap、OpenOcean、Wing等。
截止目前，部分被盗Token （sUSD、RFuel、COOK等）被黑客通过Uniswap和PancakeSwap兑换成价值122万美元的主流资产，剩余被盗资金被分散到多条链60多个地址中，暂未进一步转移，全部黑客地址已被录入慢雾AML恶意地址库。[2023/7/2 22:13:22]
但是如果事情那么简单，那么本次分析不值一提。问题远比想象的复杂得多。如上图所示攻击者的入口在Furucombo的batchExec函数，我们先对batchExec函数进行分析：
慢雾：针对macOS系统恶意软件RustBucket窃取系统信息:金色财经报道，SlowMist发布安全警报，针对macOS 运行系统的 Rust 和 Objective-C 编写的恶意软件RustBucket，感染链由一个 macOS 安装程序组成，该安装程序安装了一个带后门但功能正常的 PDF 阅读器。然后伪造的 PDF 阅读器需要打开一个特定的 PDF 文件，该文件作为触发恶意活动的密钥。[2023/5/23 15:20:27]
以上是FurucomboProxy合约的batchExec函数的具体实现，其中_preProcess和_postProcess合约分别是对调用前后做一些数据上的处理，不涉及具体的调用逻辑，这边可以先忽略。我们主要观察核心的_execs函数：
慢雾：共享Apple ID导致资产被盗核心问题是应用没有和设备码绑定:5月19日消息，慢雾首席信息安全官23pds发推表示，针对共享Apple ID导致资产被盗现象，核心问题是应用没有和设备码绑定，目前99%的钱包、交易App等都都存在此类问题，没有绑定就导致数据被拖走或被恶意同步到其他设备导致被运行，攻击者在配合其他手法如社工、爆破等获取的密码，导致资产被盗。23pds提醒用户不要使用共享Apple ID等，同时小心相册截图被上传出现资产损失。[2023/5/19 15:13:08]
通过对execs代码的分析不难发现，函数的主要逻辑是对configs数组的数据做检查，并根据configs数组的数据对data进行一些处理。但是回顾上文中攻击者的调用数据，不难发现攻击者的调用数据中，configs的数据是一个0地址：
慢雾：NimbusPlatform遭遇闪电贷攻击，损失278枚BNB:据慢雾安全团队情报，2022 年 12 月 14 日， BSC 链上的NimbusPlatform项目遭到攻击，攻击者获利约278枚BNB。慢雾安全团队以简讯的形式分享如下：
1. 攻击者首先在 8 天前执行了一笔交易（0x7d2d8d），把 20 枚 BNB 换成 NBU_WBNB 再换成 GNIMB 代币，然后把 GNIMB 代币转入 Staking 合约作质押，为攻击作准备；
2. 在 8 天后正式发起攻击交易（0x42f56d3），首先通过闪电贷借出 75477 枚 BNB 并换成 NBU_WBNB，然后再用这些 NBU_WBNB 代币将池子里的绝大部分 NIMB 代币兑换出；
3. 接着调用 Staking 合约的 getReward 函数进行奖励的提取，奖励的计算是和 rate 的值正相关的，而 rate 的值则取决于池子中 NIMB 代币和 GNIMB 代币的价格，由于 NIMB 代币的价格是根据上一步闪电贷中被操控的池子中的代币数量来计算的，导致其由于闪电贷兑换出大量的代币而变高，最后计算的奖励也会更多；
4. 攻击者最后将最后获得的 GNIMB 代币和拥有的 NIMB 代币换成 NBU_WBNB 代币后再换成 BNB，归还闪电贷获利；
此次攻击的主要原因在于计算奖励的时候仅取决于池子中的代币数量导致被闪电贷操控，从而获取比预期更多的奖励。慢雾安全团队建议在进行代币奖计算时应确保价格来源的安全性。[2022/12/14 21:44:29]
声音 | 慢雾：ETDP钱包连续转移近2000 ETH到Bitstamp交易所，项目方疑似跑路:据慢雾科技反(AML)系统监测显示，自北京时间 12 月 16 日凌晨 2 点开始，ETDP 项目方钱包(地址 0xE1d9C35F…19Dc1C3)连续转移近 2000 ETH 到 Bitstamp 交易所，另有 3800 ETH 分散在 3 个新地址中，未发生进一步动作。慢雾安全团队在此提醒交易所、钱包注意加强地址监控，避免相关恶意资金流入平台。[2019/12/16]
这里有一个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
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。