据链闻消息，著名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函数：
慢雾：pGALA合约黑客已获利430万美元:11月4日消息，安全团队慢雾在推特上表示，pGALA合约黑客已将大部分GALA兑换成13,000枚BNB，获利超430万美元，该地址仍有450亿枚Gala，但不太可能兑现，因为资金池基本已耗尽。此外，黑客的初始资金来自几个币安账户。
今日早些时候消息，一个BNB Chain上地址在BNB Chain上地址凭空铸造了超10亿美元的pGALA代币，并通过在PancakeSwap上售出获利。pNetwork表示此为跨链桥配置错误所致，GALA跨链桥已暂停，请用户不要在BNB Chain上DEX中交易pGALA。[2022/11/4 12:16:04]
慢雾：Transit Swap黑客攻击交易被抢跑，套利机器人获利超100万美元:10月1日消息，据慢雾安全团队情报，Transit Swap 黑客转移用户 BSC 链 BUSD 资产时被套利机器人抢跑，区块高度为21816885，获利107万BUSD。套利机器人相关地址列表如下：0xa957...70d2、0x90b5...8ff4、0xcfb0...7ac7、
截止到目前，在各方的共同努力下，黑客已将 70% 左右的被盗资产退还到Transit Swap开发者地址，建议套利机器人所属人同样通过service@transit.finance或链上地址与Transit Swap取得联系，共同将此次被盗事件的受害用户损失降低到最小。[2022/10/2 18:37:44]
通过对execs代码的分析不难发现，函数的主要逻辑是对configs数组的数据做检查，并根据configs数组的数据对data进行一些处理。但是回顾上文中攻击者的调用数据，不难发现攻击者的调用数据中，configs的数据是一个0地址：
慢雾：美国演员SethGreen的NFT遭钓鱼攻击，资金已跨链到 BTC 并混币:5月18日消息，美国演员SethGreen遭遇钓鱼攻击致4个NFT（包括1个BAYC、2个MAYC和1个Doodle）被盗，钓鱼者地址已将NFT全部售出，获利近160枚ETH（约33万美元）。
慢雾MistTrack对0xC8a0907开头的钓鱼地址分析后，发现总共有8个用户的NFT被盗，包含MAYC、Doodle、BAYC、VOX等12类NFT，全部售出后总获利194ETH。同时，该钓鱼地址初始资金0.188ETH来自Change NOW。钓鱼者地址将大部分ETH转换为renBTC后跨链到6个BTC地址，约14BTC均通过混币转移以躲避追踪。NFT钓鱼无处不在，请大家保持怀疑，提高警惕。[2022/5/18 3:24:23]
慢雾：Cover协议被黑问题出在rewardWriteoff具体计算参数变化导致差值:2020年12月29日，慢雾安全团队对整个Cover协议被攻击流程进行了简要分析。
1.在Cover协议的Blacksmith合约中，用户可以通过deposit函数抵押BPT代币；
2.攻击者在第一次进行deposit-withdraw后将通过updatePool函数来更新池子，并使用accRewardsPerToken来记录累计奖励；
3.之后将通过_claimCoverRewards函数来分配奖励并使用rewardWriteoff参数进行记录；
4.在攻击者第一次withdraw后还留有一小部分的BPT进行抵押；
5.此时攻击者将第二次进行deposit，并通过claimRewards提取奖励；
6.问题出在rewardWriteoff的具体计算，在攻击者第二次进行deposit-claimRewards时取的Pool值定义为memory，此时memory中获取的Pool是攻击者第一次withdraw进行updatePool时更新的值；
7.由于memory中获取的Pool值是旧的，其对应记录的accRewardsPerToken也是旧的会赋值到miner；
8.之后再进行新的一次updatePool时，由于攻击者在第一次进行withdraw后池子中的lpTotal已经变小，所以最后获得的accRewardsPerToken将变大；
9.此时攻击者被赋值的accRewardsPerToken是旧的是一个较小值，在进行rewardWriteoff计算时获得的值也将偏小，但攻击者在进行claimRewards时用的却是池子更新后的accRewardsPerToken值；
10.因此在进行具体奖励计算时由于这个新旧参数之前差值，会导致计算出一个偏大的数值；
11.所以最后在根据计算结果给攻击者铸造奖励时就会额外铸造出更多的COVER代币，导致COVER代币增发。具体accRewardsPerToken参数差值变化如图所示。[2020/12/29 15:58:07]
这里有一个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
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。