据链闻消息，著名DeFi项目Furucombo被黑，损失超1500万美元。慢雾安全团队第一时间介入分析，并将攻击细节分享给大家。攻击细节分析
本次发生问题的合约在Furucombo本身的代理合约当中。整个攻击流程很简单。攻击者通过设置了Furucombo的AaveV2Proxy的逻辑地址导致后续通过Furucombo代理合约调用的逻辑全部转发到攻击者自己的恶意合约上，导致任意资金被盗。
慢雾：Uwerx遭受攻击因为接收地址会多销毁掉from地址转账金额1%的代币:金色财经报道，Uwerx遭到攻击，损失约174.78枚ETH，据慢雾分析，根本原因是当接收地址为 uniswapPoolAddress（0x01）时，将会多burn掉from地址的转账金额1%的代币，因此攻击者利用uniswapv2池的skim功能消耗大量WERX代币，然后调用sync函数恶意抬高代币价格，最后反向兑换手中剩余的WERX为ETH以获得利润。据MistTrack分析，黑客初始资金来自Tornadocash转入的10 BNB，接着将10 BNB换成1.3 ETH，并通过Socket跨链到以太坊。目前，被盗资金仍停留在黑客地址0x605...Ce4。[2023/8/2 16:14:10]
但是如果事情那么简单，那么本次分析不值一提。问题远比想象的复杂得多。如上图所示攻击者的入口在Furucombo的batchExec函数，我们先对batchExec函数进行分析：
慢雾：警惕Web3钱包WalletConnect钓鱼风险:金色财经报道，慢雾安全团队发现 Web3 钱包上关于 WalletConnect 使用不当可能存在被钓鱼的安全风险问题。这个问题存在于使用移动端钱包 App 内置的 DApp Browser + WalletConnect 的场景下。
慢雾发现，部分 Web3 钱包在提供 WalletConnect 支持的时候，没有对 WalletConnect 的交易弹窗要在哪个区域弹出进行限制，因此会在钱包的任意界面弹出签名请求。[2023/4/17 14:08:53]
以上是FurucomboProxy合约的batchExec函数的具体实现，其中_preProcess和_postProcess合约分别是对调用前后做一些数据上的处理，不涉及具体的调用逻辑，这边可以先忽略。我们主要观察核心的_execs函数：
慢雾：昨日MEV机器人攻击者恶意构造无效区块，建议中继运营者及时升级:金色财经报道，慢雾分析显示，昨日MEV机器人被攻击的问题原因在于即使信标区块不正确，中继仍将有效载荷（payload）返回给提议者，导致了提议者在另一个区块被最终确定之前就能访问区块内容。攻击者利用此问题，恶意构造了无效的区块，使得该区块无法被验证，中继无法进行广播（状态码为202）从而提前获得交易内容。mev-boost-relay昨日已紧急发布新版本缓解此问题，建议中继运营者及时升级中继。
据此前报道，昨日夹击MEV机器人的恶意验证者已被Slash惩罚并踢出验证者队列。[2023/4/4 13:43:37]
慢雾：Ribbon Finance遭遇DNS攻击，某用户损失16.5 WBTC:6月24日消息，Ribbon Finance 发推表示遭遇 DNS 攻击，慢雾MistTrack通过链上分析发现攻击者与今天早前的Convex Finance 攻击者是同一个，地址 0xb73261481064f717a63e6f295d917c28385af9aa 是攻击者共用的用来调用恶意合约的钱包地址。同时分析发现，Ribbon Finance某用户在攻击中损失了 16.5 WBTC，具体交易为：https://etherscan.io/tx/0xd09057f1fdb3fa97d0ed7e8ebd8fd31dd9a0b5b61a29a22b46985d6217510850。[2022/6/24 1:29:35]
通过对execs代码的分析不难发现，函数的主要逻辑是对configs数组的数据做检查，并根据configs数组的数据对data进行一些处理。但是回顾上文中攻击者的调用数据，不难发现攻击者的调用数据中，configs的数据是一个0地址：
慢雾：BTFinance被黑，策略池需防范相关风险:据慢雾区情报，智能DeFi收益聚合器BT.Finance遭受闪电贷攻击。受影响的策略包括ETH、USDC和USDT。经慢雾安全团队分析，本次攻击手法与yearnfinance的DAI策略池被黑的手法基本一致。具体分析可参考慢雾关于yearnfinace被黑的技术分析。慢雾安全团队提醒，近期对接CurveFinance做相关策略的机池频繁遭受攻击。相关已对接CurveFinance收益聚合器产品应注意排查使用的策略是否存在类似问题，必要时可以联系慢雾安全团队协助处理。[2021/2/9 19:19:41]
这里有一个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
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。