著名 DeFi 项目 Furucombo 被黑，损失超 1500 万美元。慢雾安全团队第一时间介入分析，并将攻击细节分享给大家。
本次发生问题的合约在 Furucombo 本身的代理合约当中。整个攻击流程很简单。攻击者通过设置了 Furucombo 的 AaveV2 Proxy 的逻辑地址导致后续通过 Furucombo 代理合约调用的逻辑全部转发到攻击者自己的恶意合约上，导致任意资金被盗。
但是如果事情那么简单，那么本次分析不值一提。问题远比想象的复杂得多。
慢雾：NimbusPlatform遭遇闪电贷攻击，损失278枚BNB:据慢雾安全团队情报，2022 年 12 月 14 日， BSC 链上的NimbusPlatform项目遭到攻击，攻击者获利约278枚BNB。慢雾安全团队以简讯的形式分享如下：
1. 攻击者首先在 8 天前执行了一笔交易（0x7d2d8d），把 20 枚 BNB 换成 NBU_WBNB 再换成 GNIMB 代币，然后把 GNIMB 代币转入 Staking 合约作质押，为攻击作准备；
2. 在 8 天后正式发起攻击交易（0x42f56d3），首先通过闪电贷借出 75477 枚 BNB 并换成 NBU_WBNB，然后再用这些 NBU_WBNB 代币将池子里的绝大部分 NIMB 代币兑换出；
3. 接着调用 Staking 合约的 getReward 函数进行奖励的提取，奖励的计算是和 rate 的值正相关的，而 rate 的值则取决于池子中 NIMB 代币和 GNIMB 代币的价格，由于 NIMB 代币的价格是根据上一步闪电贷中被操控的池子中的代币数量来计算的，导致其由于闪电贷兑换出大量的代币而变高，最后计算的奖励也会更多；
4. 攻击者最后将最后获得的 GNIMB 代币和拥有的 NIMB 代币换成 NBU_WBNB 代币后再换成 BNB，归还闪电贷获利；
此次攻击的主要原因在于计算奖励的时候仅取决于池子中的代币数量导致被闪电贷操控，从而获取比预期更多的奖励。慢雾安全团队建议在进行代币奖计算时应确保价格来源的安全性。[2022/12/14 21:44:29]
如上图所示攻击者的入口在 Furucombo 的 batchExec 函数，我们先对 batchExec 函数进行分析：
慢雾：Transit Swap事件中转移到Tornado Cash的资金超过600万美元:金色财经报道，慢雾 MistTrack 对 Transit Swap 事件资金转移进行跟进分析，以下将分析结论同步社区：
Hacker#1 攻击黑客（盗取最大资金黑客），获利金额：约 2410 万美元
1: 0x75F2...FFD46
2: 0xfa71...90fb
已归还超 1890 万美元的被盗资金；12,500 BNB 存款到 Tornado Cash；约 1400 万 MOONEY 代币和 67,709 DAI 代币转入 ShibaSwap: BONE Token 合约地址。
Hacker#2 套利机器人-1，获利金额：1,166,882.07 BUSD
0xcfb0...7ac7(BSC)
保留在获利地址中，未进一步转移。
Hacker#3 攻击模仿者-1，获利金额：356,690.71 USDT
0x87be...3c4c(BSC)
Hacker#4 套利机器人-2，获利金额：246,757.31 USDT
0x0000...4922(BSC)
已全部追回。
Hacker#5 套利机器人-3，获利金额：584,801.17 USDC
0xcc3d...ae7d(BSC)
USDC 全部转移至新地址 0x8960...8525，后无进一步转移。
Hacker#6 攻击模仿者-2，获利金额：2,348,967.9 USDT
0x6e60...c5ea(BSC)
Hacker#7 套利机器人-4，获利金额：5,974.52 UNI、1,667.36 MANA
0x6C6B...364e(ETH)
通过 Uniswap 兑换为 30.17 ETH，其中 0.71 支付给 Flashbots，剩余 ETH 未进一步转移。[2022/10/6 18:41:10]
慢雾：iCloud 用戶的MetaMask钱包遭遇钓鱼攻击是由于自身的安全意识不足:据官方消息，慢雾发布iCloud 用戶的MetaMask钱包遭遇钓鱼攻击简析，首先用户遭遇了钓鱼攻击，是由于自身的安全意识不足，泄露了iCloud账号密码，用户应当承担大部分的责任。但是从钱包产品设计的角度上分析，MetaMask iOS App 端本身就存在有安全缺陷。
MetaMask安卓端在AndroidManifest.xml中有android:allowBackup=\"false\" 来禁止应用程序被用户和系统进行备份，从而避免备份的数据在其他设备上被恢复。
MetaMask iOS端代码中没有发现存在这类禁止钱包数据(如 KeyStore 文件)被系统备份的机制。默认情况下iCloud会自动备份应用数据，当iCloud账号密码等权限信息被恶意攻击者获取，攻击者可以从目标 iCloud 里恢复 MetaMask iOS App 钱包的相关数据。
慢雾安全团队经过实测通过 iCloud 恢复数据后再打开 MetaMask 钱包，还需要输入验证钱包的密码，如果密码的复杂度较低就会存在被破解的可能。[2022/4/18 14:31:38]
以上是 Furucombo Proxy 合约的 batchExec 函数的具体实现，其中 _preProcess 和 _postProcess 合约分别是对调用前后做一些数据上的处理，不涉及具体的调用逻辑，这边可以先忽略。我们主要观察核心的 _execs 函数：
慢雾：ERC721R示例合约存在缺陷，本质上是由于owner权限过大问题:4月12日消息，据@BenWAGMI消息，ERC721R示例合约存在缺陷可导致项目方利用此问题进行RugPull。据慢雾安全团队初步分析，此缺陷本质上是由于owner权限过大问题，在ERC721R示例合约中owner可以通过setRefund Address函数任意设置接收用户退回的NFT地址。
当此退回地址持有目标NFT时，其可以通过调用refund函数不断的进行退款操作从而耗尽用户在合约中锁定的购买资金。且示例合约中存在owner Mint函数，owner可在NFT mint未达总供应量的情况下进行mint。因此ERC721R的实现仍是防君子不防小人。慢雾安全团队建议用户在参与NFTmint时不管项目方是否使用ERC721R都需做好风险评估。[2022/4/12 14:19:58]
声音 | 慢雾：EOS假充值红色预警后续:慢雾安全团队今早发布了 EOS 假充值红色预警后，联合 EOSPark 的大数据分析系统持续跟踪和分析发现：从昨日开始，存在十几个帐号利用这类攻击技巧对数字货币交易所、钱包等平台进行持续性攻击，并有被真实攻击情况。慢雾安全团队在此建议各大交易所、钱包、DApp 做好相关防御措施，严格校验发送给自己的转账交易在不可逆的状态下确认交易的执行状态是否为 executed。除此之外，确保以下几点防止其他类型的“假充值”攻击： 1. 判断 action 是否为 transfer 2. 判断合约账号是否为 eosio.token 或其它 token 的官方合约 3. 判断代币名称及精度 4. 判断金额 5. 判断 to 是否是自己平台的充币账号。[2019/3/12]
通过对 execs 代码的分析不难发现，函数的主要逻辑是对 configs 数组的数据做检查，并根据 configs 数组的数据对 data 进行一些处理。但是回顾上文中攻击者的调用数据，不难发现攻击者的调用数据中，configs 的数据是一个 0 地址：
这里有一个 trick，由于 0 地址是一个 EOA 地址，所有对 EOA 地址的函数调用都会成功，但是不会返回任何结果。结合这个 trick，execs 函数中的关于 configs 数据的部分可以先暂时忽略。直接看到最后的核心 _exec 函数：
_exec 函数的逻辑也很简单，在校验了 _to 地址后，直接就将 data 转发到指定的 _to 地址上了。而通过对攻击交易的分析，我们能发现这个 _to 地址确实是官方指定的合法地址。
最后一步，便是调用 _to 地址，也就是官方指定的 AaveV2 Proxy 合约的 initialize 函数，将攻击者自己的恶意地址设置成 AaveV2 Proxy 合约的逻辑地址。通过对 Furucombo 合约的分析，可以发现整个调用流程上没有出现严重的安全点，对调用的地址也进行了白名单的检查。那么问题只能是出在了对应要调用的代理逻辑上，也就是 AaveV2 Proxy 合约。
我们直接分析 AaveV2 Proxy 合约的 initialize 函数的逻辑：
可以看到 initialize 函数是一个 public 函数，并在开头就检查了 _implementation 是否是 0 地址，如果是 0 地址，则抛出错误。这个检查的目的其实就是检查了 _implementation 是否被设置了，如果被设置了，就无法再次设置。根据这个设置，不难想出 initialize 这个函数只能调用一次。除非 AaveV2 Proxy 从来没有设置过 _implementation，否则这个调用是不会成功的。难道 Furucombo 真的没有设置过对应的 _implementation 吗？带着这样的疑问，我们检查了交易内的状态变化。如下：
可以看到，交易中改变了存储位置为 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc 的内容，而写入的内容正是攻击者自己的恶意合约地址 0x86765dde9304bea32f65330d266155c4fa0c4f04。
而 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc 这个位置，正是 _implementation 数据的存储地址。
也就是说，官方从来没有设置过 AaveV2 Proxy 合约的 _implementation 地址，导致攻击者钻了这个空子，造成了 Furucombo 资产损失。
通过对整个事件的分析来看，Furucombo 此次事故并不在安全漏洞的范畴内，主要的原因在于官方将未启用的 AaveV2 Proxy 合约添加进了自己的白名单中，并且未对 AaveV2 Proxy 合约进行初始化，导致攻击者有机可乘。
目前，由于 Furucombo 遭受攻击，导致任何将代币授权过给 Furucombo 合约 (0x17e8ca1b4798b97602895f63206afcd1fc90ca5f) 的用户都将面临资金损失的风险。
慢雾安全团队建议与 Furucombo 交互过的用户检查是否有将相关代币授权给 Furucombo 合约。如有授权，应及时撤销相关授权，避免进一步损失。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。