安全生产简析下meerkat跑路事件
一、核心问题
1.AdminUpgradeabilityProxy天然的负面影响一代理的逻辑合约可以被替换
2.AdminUpgradeabilityProxy权限没有移交timelock一项目方不受时间锁约束，可以随意使用1。所说的能力，替换逻辑合约最终项目方无限制地将正常合约替换成了攻击合约，卷款跑路。
Beosin：UVT项目被黑客攻击事件简析，被盗资金已全部转入Tornado Cash:金色财经报道，据Beosin EagleEye 安全预警与监控平台检测显示，UVT项目被黑客攻击，涉及金额为150万美元。攻击交易为0x54121ed538f27ffee2dbb232f9d9be33e39fdaf34adf993e5e019c00f6afd499
经Beosin安全团队分析，发现攻击者首先利用开发者部署的另一个合约的具有Controller权限的0xc81daf6e方法，该方法会调用被攻击合约的0x7e39d2f8方法，因为合约具有Controller权限，所以通过验证直接转走了被攻击合约的所有UVT代币，Beosin安全团队通过Beosin Trace进行追踪，发现被盗资金已全部转入Tornado Cash。[2022/10/27 11:48:46]
二、现场还原(以BUSD池为例)?
安全团队：LPC项目遭受闪电贷攻击简析，攻击者共获利约45,715美元:7月25日，据成都链安“链必应-区块链安全态势感知平台”安全舆情监控数据显示，LPC项目遭受闪电贷攻击。成都链安安全团队简析如下：攻击者先利用闪电贷从Pancake借入1,353,900个LPC，随后攻击者调用LPC合约中的transfer函数向自己转账，由于 _transfer函数中未更新账本余额，而是直接在原接收者余额recipientBalance值上进行修改，导致攻击者余额增加。随后攻击者归还闪电贷并将获得的LPC兑换为BUSD，最后兑换为BNB获利离场。本次攻击项目方损失845,631,823个 LPC，攻击者共获利178 BNB，价值约45,715美元，目前获利资金仍然存放于攻击者地址上（0xd9936EA91a461aA4B727a7e3661bcD6cD257481c），成都链安“链必追”平台将对此地址进行监控和追踪。[2022/7/25 2:36:51]
1.项目方故意“坦诚”给出合约的timelock转移权限记录，展示的确执行了changeAdmin方法移交权限给timelock地址，用于混淆视听
Harvest.Finance被黑事件简析:10月26号，据慢雾区消息 Harvest Finance 项目遭受闪电贷攻击，损失超过 400 万美元。以下为慢雾安全团队对此事件的简要分析。
1. 攻击者通过 Tornado.cash 转入 20ETH 作为后续攻击手续费；
2. 攻击者通过 UniswapV2 闪电贷借出巨额 USDC 与 USDT；
3. 攻击者先通过 Curve 的 exchange_underlying 函数将 USDT 换成 USDC，此时 Curve yUSDC 池中的 investedUnderlyingBalance 将相对应的变小；
4. 随后攻击者通过 Harvest 的 deposit 将巨额 USDC 充值进 Vault 中，充值的同时 Harvest 的 Vault 将铸出 fUSDC，而铸出的数量计算方式如下：
amount.mul(totalSupply()).div(underlyingBalanceWithInvestment());
计算方式中的 underlyingBalanceWithInvestment 一部分取的是 Curve 中的 investedUnderlyingBalance 值，由于 Curve 中 investedUnderlyingBalance 的变化将导致 Vault 铸出更多的 fUSDC；
5. 之后再通过 Curve 把 USDC 换成 USDT 将失衡的价格拉回正常；
6. 最后只需要把 fUSDC 归还给 Vault 即可获得比充值时更多的 USDC；
7. 随后攻击者开始重复此过程持续获利；
其他攻击流程与上诉分析过程类似。参考交易哈希：0x35f8d2f572fceaac9288e5d462117850ef2694786992a8c3f6d02612277b0877。
此次攻击主要是 Harvest Finance 的 fToken(fUSDC、fUSDT...) 在铸币时采用的是 Curve y池中的报价(即使用 Curve 作为喂价来源)，导致攻击者可以通过巨额兑换操控预言机的价格来控制 Harvest Finance 中 fToken 的铸币数量，从而使攻击者有利可图。[2020/10/26]
2.0x7E0c621Ea9F7aFD5b86A50B0942eAee68B04A61Cproxy合约，changeAdmin方法内部调用追踪到304行，实际写入key为ADMIN_SLOT，但读取key却为ADMIN_SLOT。即O(欧)和0(零)的一个细微差异，让changeAdmin方法完全失效，从而达到了已经移交权限的假象
三、结论和经验
1.高度警惕任何包含proxy方式合约的项目，若未经timelock约束，合约有被瞬间替换的风险
2.nevertrust，alwaysverify！不要相信项目方给出的timelock“证据”，对于未经审计的fork项目，务必逐个contract做好与原项目的diff(如果你做到了，就可以躲过meerkat的障眼法)
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。