著名DeFi项目Furucombo被黑，损失超1500万美元。慢雾安全团队第一时间介入分析，并将攻击细节分享给大家。
攻击细节分析
本次发生问题的合约在Furucombo本身的代理合约当中。整个攻击流程很简单。攻击者通过设置了Furucombo的AaveV2Proxy的逻辑地址导致后续通过Furucombo代理合约调用的逻辑全部转发到攻击者自己的恶意合约上，导致任意资金被盗。
慢雾：上周Web3安全事件中总损失约1996.3万美元:金色财经报道，据慢雾区块链被黑档案库统计，2023年8月14日至8月20日，共发生安全事件10起，总损失约1996.3万美元。具体事件：
8月14日，Hexagate发推表示，过去几天单个MEV Bot被利用了约20万美元。以太坊上Zunami Protocol协议遭遇价格操纵攻击，损失1,179个ETH（约220万美元）。
8月15日，以太坊扩容解决方案Metis官方推特账号被盗。Sei Network官方Discord服务器遭入侵。Base生态项目RocketSwap遭遇攻击，攻击者窃取了RCKT代币，将其转换为价值约86.8万美元的ETH并跨链到以太坊。
8月16日，借贷协议SwirlLend团队从Base盗取了约290万美元的加密货币，从Linea盗取了价值170万美元的加密货币。BAYC推出的链上许可申请平台Made by Apes的SaaSy Labs APl存在一个问题，允许访问MBA申请的个人详细信息。
8月18日，DeFi借贷协议Exactly Protocol遭受攻击，损失超7,160枚ETH（约1204万美元）。
8月19日，Cosmos生态跨链稳定币协议Harbor Protocol被利用，损失42,261枚LUNA、1,533枚CMDX、1,571枚stOSMO和18,600万亿枚WMATIC。
8月20日，衍生品市场Thales发布公告称，一名核心贡献者的个人电脑/Metamask遭到黑客攻击，一些充当临时部署者（2.5万美元）或管理员机器人（1万美元）的热钱包已被攻破。[2023/8/21 18:13:42]
但是如果事情那么简单，那么本次分析不值一提。问题远比想象的复杂得多。
慢雾：远程命令执行漏洞CVE-2023-37582在互联网上公开，已出现攻击案例:金色财经报道，据慢雾消息，7.12日Apache RocketMQ发布严重安全提醒，披露远程命令执行漏洞（CVE-2023-37582）目前PoC在互联网上公开，已出现攻击案例。Apache RocketMQ是一款开源的分布式消息和流处理平台，提供高效、可靠、可扩展的低延迟消息和流数据处理能力，广泛用于异步通信、应用解耦、系统集等场景。加密货币行业有大量平台采用此产品用来处理消息服务，注意风险。漏洞描述：当RocketMQ的NameServer组件暴露在外网时，并且缺乏有效的身份认证机制时，攻击者可以利用更新配置功能，以RocketMQ运行的系统用户身份执行命令。[2023/7/14 10:54:22]
如上图所示攻击者的入口在Furucombo的batchExec函数，我们先对batchExec函数进行分析：
慢雾：Quixotic黑客盗取约22万枚OP，跨链至BNB Chain后转入Tornado Cash:7月1日消息，据慢雾分析，Quixotic黑客盗取了大约22万枚OP（约11.9万美元），然后将其兑换成USDC并跨链到BNB Chain，之后将其兑换成BNB并转入Tornado Cash。[2022/7/1 1:44:55]
以上是FurucomboProxy合约的batchExec函数的具体实现，其中_preProcess和_postProcess合约分别是对调用前后做一些数据上的处理，不涉及具体的调用逻辑，这边可以先忽略。我们主要观察核心的_execs函数：
慢雾：攻击Ronin Network的黑客地址向火币转入3750枚 ETH:3月30日消息，慢雾发推称，攻击Axie Infinity侧链Ronin Network的黑客地址向交易所火币转入3750枚ETH。此前金色财经报道，Ronin桥被攻击，17.36万枚ETH和2550万USDC被盗。[2022/3/30 14:26:38]
通过对execs代码的分析不难发现，函数的主要逻辑是对configs数组的数据做检查，并根据configs数组的数据对data进行一些处理。但是回顾上文中攻击者的调用数据，不难发现攻击者的调用数据中，configs的数据是一个0地址：
分析 | 慢雾：攻击者拿下了DragonEx尽可能多的权限 攻击持续至少1天:据慢雾安全团队的链上情报分析，从DragonEx公布的“攻击者地址”的分析来看，20 个币种都被盗取（但还有一些DragonEx可交易的知名币种并没被公布），从链上行为来看攻击这些币种的攻击手法并不完全相同，攻击持续的时间至少有1天，但能造成这种大面积盗取结果的，至少可以推论出：攻击者拿下了DragonEx尽可能多的权限，更多细节请留意后续披露。[2019/3/26]
这里有一个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合约。如有授权，应及时撤销相关授权，避免进一步损失。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。