据链闻消息，著名DeFi项目Furucombo被黑，损失超1500万美元。慢雾安全团队第一时间介入分析，并将攻击细节分享给大家。攻击细节分析
本次发生问题的合约在Furucombo本身的代理合约当中。整个攻击流程很简单。攻击者通过设置了Furucombo的AaveV2Proxy的逻辑地址导致后续通过Furucombo代理合约调用的逻辑全部转发到攻击者自己的恶意合约上，导致任意资金被盗。
慢雾：针对macOS系统恶意软件RustBucket窃取系统信息:金色财经报道，SlowMist发布安全警报，针对macOS 运行系统的 Rust 和 Objective-C 编写的恶意软件RustBucket，感染链由一个 macOS 安装程序组成，该安装程序安装了一个带后门但功能正常的 PDF 阅读器。然后伪造的 PDF 阅读器需要打开一个特定的 PDF 文件，该文件作为触发恶意活动的密钥。[2023/5/23 15:20:27]
但是如果事情那么简单，那么本次分析不值一提。问题远比想象的复杂得多。如上图所示攻击者的入口在Furucombo的batchExec函数，我们先对batchExec函数进行分析：
慢雾：Titano Finance被黑因池子被设置成恶意PrizeStrategy合约造成后续利用:据慢雾区情报消息，2月14日，BSC链上的Titano Finance项目遭受攻击，损失约190万美元，最初获利地址为0xad9217e427ed9df8a89e582601a8614fd4f74563，目前被黑资金已被攻击者转移到其他23个钱包。该攻击主要由于owner角色可以任意设置setPrizeStrategy函数，导致了池子被设置成恶意的PrizeStrategy合约造成后续利用。[2022/2/14 9:51:14]
以上是FurucomboProxy合约的batchExec函数的具体实现，其中_preProcess和_postProcess合约分别是对调用前后做一些数据上的处理，不涉及具体的调用逻辑，这边可以先忽略。我们主要观察核心的_execs函数：
慢雾：Lendf.Me攻击者刚归还了126,014枚PAX:慢雾安全团队从链上数据监测到，Lendf.Me攻击者(0xa9bf70a420d364e923c74448d9d817d3f2a77822)刚向Lendf.Me平台admin账户(0xa6a6783828ab3e4a9db54302bc01c4ca73f17efb)转账126,014枚PAX，并附言\"Better future\"。随后Lendf.Me平台admin账户通过memo回复攻击者并带上联系邮箱。此外，Lendf.Me攻击者钱包地址收到一些受害用户通过memo求助。[2020/4/20]
动态 | 慢雾：9 月共发生 12 起较典型的安全事件，供应链攻击趋势愈发明显:过去的 9 月区块链生态共发生 12 起较典型的安全事件，包括：EOSPlay 遭受新型随机数攻击、资金盘项目 FairWin 智能合约权限管理缺陷、EOS 黑名单账号 craigspys211 利用新晋 BP 黑名单缺陷转移走 19.999 万枚 EOS 等典型安全事件。此外，慢雾区块链威胁情报(BTI)系统监测发现，针对区块链生态的供应链攻击越来越多，形如：去年 11 月慢雾披露的污染 NPM 模块 EventStream、今年 7 月披露的对数字货币钱包 Agama 构建链的攻击、今年 8 月披露的针对数字货币行情/导航站的 URL 劫持攻击，还有 9 月慢雾披露的针对交易所使用的第三方统计、客服 js 的恶意代码植入，进行实施盗币攻击。[2019/10/1]
通过对execs代码的分析不难发现，函数的主要逻辑是对configs数组的数据做检查，并根据configs数组的数据对data进行一些处理。但是回顾上文中攻击者的调用数据，不难发现攻击者的调用数据中，configs的数据是一个0地址：
分析 | 慢雾：韩国交易所 Bithumb XRP 钱包也疑似被黑:Twitter 上有消息称 XRP 地址（rLaHMvsPnPbiNQSjAgY8Tf8953jxQo4vnu）被盗 20,000,000 枚 XRP（价值 $6,000,000），通过慢雾安全团队的进一步分析，疑似攻击者地址（rBKRigtRR2N3dQH9cvWpJ44sTtkHiLcxz1）于 UTC 时间 03/29/2019?13:46 新建并激活，此后开始持续 50 分钟的“盗币”行为。此前慢雾安全团队第一时间披露 Bithumb EOS 钱包（g4ydomrxhege）疑似被黑，损失 3,132,672 枚 EOS，且攻击者在持续洗币。更多细节会继续披露。[2019/3/30]
这里有一个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
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。