著名DeFi项目Furucombo被黑，损失超1500万美元。慢雾安全团队第一时间介入分析，并将攻击细节分享给大家。
攻击细节分析
本次发生问题的合约在Furucombo本身的代理合约当中。整个攻击流程很简单。攻击者通过设置了Furucombo的AaveV2Proxy的逻辑地址导致后续通过Furucombo代理合约调用的逻辑全部转发到攻击者自己的恶意合约上，导致任意资金被盗。
慢雾：JPEG'd攻击者或已将全部6106.75枚ETH归还给项目方:8月4日消息，慢雾MistTrack监测显示，JPEG'd攻击者或已将全部6106.75枚ETH归还给项目方。[2023/8/4 16:18:46]
但是如果事情那么简单，那么本次分析不值一提。问题远比想象的复杂得多。
如上图所示攻击者的入口在Furucombo的batchExec函数，我们先对batchExec函数进行分析：
以上是FurucomboProxy合约的batchExec函数的具体实现，其中_preProcess和_postProcess合约分别是对调用前后做一些数据上的处理，不涉及具体的调用逻辑，这边可以先忽略。我们主要观察核心的_execs函数：
慢雾：警惕针对 Blur NFT 市场的批量挂单签名“零元购”钓鱼风险:金色财经报道，近期，慢雾生态安全合作伙伴 Scam Sniffer 演示了一个针对 Blur NFT 市场批量挂单签名的“零元购”钓鱼攻击测试，通过一个如图这样的“Root 签名”即可以极低成本（特指“零元购”）钓走目标用户在 Blur 平台授权的所有 NFT，Blur 平台的这个“Root 签名”格式类似“盲签”，用户无法识别这种签名的影响。慢雾安全团队验证了该攻击的可行性及危害性。特此提醒 Blur 平台的所有用户警惕，当发现来非 Blur 官方域名(blur.io)的“Root 签名”，一定要拒绝，避免潜在的资产损失。[2023/3/7 12:46:39]
慢雾：警惕 Terra 链上项目被恶意广告投放钓鱼风险:据慢雾区情报，近期 Terra 链上部分用户的资产被恶意转出。慢雾安全团队发现从 4 月 12 日开始至 4 月 21 日约有 52 个地址中的资金被恶意转出至 terra1fz57nt6t3nnxel6q77wsmxxdesn7rgy0h27x30 中，当前总损失约 431 万美金。
经过慢雾安全追踪分析确认，此次攻击为批量谷歌关键词广告投放钓鱼，用户在谷歌搜索如：astroport，nexus protocol，anchor protocol 等这些知名的 Terra 项目，谷歌结果页第一条看似正常的广告链接（显示的域名甚至是一样的）实为钓鱼网站。 一旦用户不注意访问此钓鱼网站，点击连接钱包时，钓鱼网站会提醒直接输入助记词，一旦用户输入并点击提交，资产将会被攻击者盗取。
慢雾安全团队建议 Terra 链上用户保持警惕不要随便点击谷歌搜索出来的链接或点击来历不明的链接，减少使用常用钱包进行非必要的操作，避免不必要的资损。[2022/4/21 14:37:55]
通过对execs代码的分析不难发现，函数的主要逻辑是对configs数组的数据做检查，并根据configs数组的数据对data进行一些处理。但是回顾上文中攻击者的调用数据，不难发现攻击者的调用数据中，configs的数据是一个0地址：
慢雾：BTFinance被黑，策略池需防范相关风险:据慢雾区情报，智能DeFi收益聚合器BT.Finance遭受闪电贷攻击。受影响的策略包括ETH、USDC和USDT。经慢雾安全团队分析，本次攻击手法与yearnfinance的DAI策略池被黑的手法基本一致。具体分析可参考慢雾关于yearnfinace被黑的技术分析。慢雾安全团队提醒，近期对接CurveFinance做相关策略的机池频繁遭受攻击。相关已对接CurveFinance收益聚合器产品应注意排查使用的策略是否存在类似问题，必要时可以联系慢雾安全团队协助处理。[2021/2/9 19:19:41]
慢雾：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]
这里有一个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合约。如有授权，应及时撤销相关授权，避免进一步损失。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。