FUR:慢雾：Furucombo被黑分析

据链闻消息，著名DeFi项目Furucombo被黑，损失超1500万美元。慢雾安全团队第一时间介入分析，并将攻击细节分享给大家。

攻击细节分析

本次发生问题的合约在Furucombo本身的代理合约当中。整个攻击流程很简单。攻击者通过设置了Furucombo的AaveV2Proxy的逻辑地址导致后续通过Furucombo代理合约调用的逻辑全部转发到攻击者自己的恶意合约上，导致任意资金被盗。

但是如果事情那么简单，那么本次分析不值一提。问题远比想象的复杂得多。

如上图所示攻击者的入口在Furucombo的batchExec函数，我们先对batchExec函数进行分析：

慢雾：BXH于BSC链被盗的ETH、BTC类资产已全部跨链转至相应链:11月3日消息，10月30日攻击BXH的黑客（BSC: 0x48c94305bddfd80c6f4076963866d968cac27d79）在洗币过程中，多次使用了 AnySwap、PancakeSwap、Ellipsis 等兑换平台，其中部分 ETH 代币被兑换成 BTC。此外，黑客现已将 13304.6 ETH、642.88 BTCB 代币从 BSC 链转移到 ETH、BTC 链，目前，初始黑客获利地址仍有 15546 BNB 和价值超 3376 万美元的代币。慢雾 AML 将持续监控被盗资金的转移，拉黑攻击者控制的所有钱包地址，提醒交易所、钱包注意加强地址监控，避免相关恶意资金流入平台。[2021/11/3 6:28:49]

以上是FurucomboProxy合约的batchExec函数的具体实现，其中_preProcess和_postProcess合约分别是对调用前后做一些数据上的处理，不涉及具体的调用逻辑，这边可以先忽略。我们主要观察核心的_execs函数：

慢雾: 警惕比特币RBF风险:据BitMEX消息，比特币于区块高度666833出现陈腐区块，并产生了一笔 0.00062063 BTC 的双花交易。根据 BitMEX提供的交易内容来看，双花的两笔交易的nSequence字段的值都小于0xffffffff -1。慢雾安全团队初步认为此次双花交易有可能是比特币中的RBF交易。[2021/1/20 16:38:01]

通过对execs代码的分析不难发现，函数的主要逻辑是对configs数组的数据做检查，并根据configs数组的数据对data进行一些处理。但是回顾上文中攻击者的调用数据，不难发现攻击者的调用数据中，configs的数据是一个0地址：

这里有一个trick，由于?0地址是一个EOA地址，所有对EOA地址的函数调用都会成功，但是不会返回任何结果。结合这个trick，execs函数中的关于configs数据的部分可以先暂时忽略。直接看到最后的核心_exec函数：

动态 | 慢雾： 警惕利用EOS及EOS上Token的提币功能恶意挖矿:近期由于EIDOS空投导致EOS主网CPU资源十分紧张，有攻击者开始利用交易所/DApp提币功能恶意挖矿，请交易所/DApp在处理EOS及EOS上Token的提币时，注意检查用户提币地址是否是合约账号，建议暂时先禁止提币到合约账号，避免被攻击导致平台提币钱包的CPU资源被恶意消耗。同时，需要注意部分交易所的EOS充值钱包地址也是合约账号，需要设置白名单避免影响正常用户的提币操作。[2019/11/6]

_exec函数的逻辑也很简单，在校验了_to地址后，直接就将data转发到指定的_to地址上了。而通过对攻击交易的分析，我们能发现这个_to地址确实是官方指定的合法地址。

声音 | 慢雾：采用链上随机数方案的 DApp 需紧急暂停:根据近期针对EOS DApp遭遇“交易排挤攻击”的持续性威胁情报监测：EOS.WIN、FarmEOS、影骰、LuckBet、GameBet、Fishing、EOSDice、STACK DICE、ggeos等知名DAPP陆续被攻破，该攻击团伙（floatingsnow等）的攻击行为还在持续。在EOS主网从根本上解决这类缺陷之前，慢雾建议所有采用链上随机数方案的DAPP紧急暂停并做好风控机制升级。为了安全起见，强烈建议所有竞技类DAPP采用EOS官方很早就推荐的链下随机种子的随机数生成方案[2019/1/16]

最后一步，便是调用_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

标签：FURUCOCOMCOMBFUR价格UCO价格COINCOMEKarate Combat

Ethereum热门资讯