安全生产简析下meerkat跑路事件
一、核心问题
1.AdminUpgradeabilityProxy天然的负面影响一代理的逻辑合约可以被替换
2.AdminUpgradeabilityProxy权限没有移交timelock一项目方不受时间锁约束，可以随意使用1。所说的能力，替换逻辑合约最终项目方无限制地将正常合约替换成了攻击合约，卷款跑路。
安全团队：Rubic被攻击事件简析:金色财经报道，据区块链安全审计公司Beosin旗下Beosin EagleEye安全风险监控、预警与阻断平台监测显示，Rubic项目被攻击，Beosin安全团队分析发现RubicProxy合约的routerCallNative函数由于缺乏参数校验，_params可以指定任意的参数，攻击者可以使用特定的integrator来让RubicProxy合约可以几乎零成本的调用自己传入的函数data。攻击者通过调用routerCallNative函数，把所有授权给RubicProxy合约的USDC全部通过transferFrom转入了0x001B地址，被盗资金近1100个以太坊，通过Beosin Trace追踪发现被盗资金已经全部转入了Tornado cash。[2022/12/25 22:06:32]
二、现场还原(以BUSD池为例)?
Beosin：SEAMAN合约遭受漏洞攻击简析:金色财经报道，根据区块链安全审计公司Beosin旗下Beosin EagleEye 安全风险监控、预警与阻断平台监测显示，2022年11月29日，SEAMAN合约遭受漏洞攻击。Beosin分析发现是由于SEAMAN合约在每次transfer函数时，都会将SEAMAN代币兑换为凭证代币GVC，而SEAMAN代币和GVC代币分别处于两个交易对，导致攻击者可以利用该函数影响其中一个代币的价格。
攻击者首先通过50万BUSD兑换为GVC代币，接下来攻击者调用SEAMAN合约的transfer函数并转入最小单位的SEAMAN代币，此时会触发合约将能使用的SEAMAN代币兑换为GVC，兑换过程是合约在BUSD-SEAMAN交易对中将SEAMAN代币兑换为BUSD，接下来在BUSD-GVC交易对中将BUSD兑换为GVC，攻击者通过多次调用transfer函数触发_splitlpToken()函数，并且会将GVC分发给lpUser，会消耗BUSD-GVC交易对中GVC的数量，从而抬高了该交易对中GVC的价格。最后攻击者通过之前兑换的GVC兑换了50.7万的BUSD，获利7781 BUSD。Beosin Trace追踪发现被盗金额仍在攻击者账户（0x49fac69c51a303b4597d09c18bc5e7bf38ecf89c），将持续关注资金走向。[2022/11/29 21:10:04]
1.项目方故意“坦诚”给出合约的timelock转移权限记录，展示的确执行了changeAdmin方法移交权限给timelock地址，用于混淆视听
安全团队：获利约900万美元，Moola协议遭受黑客攻击事件简析:10月19日消息，据Beosin EagleEye Web3安全预警与监控平台监测显示，Celo上的Moola协议遭受攻击，黑客获利约900万美元。Beosin安全团队第一时间对事件进行了分析，结果如下：
第一步：攻击者进行了多笔交易，用CELO买入MOO,攻击者起始资金（182000枚CELO）.
第二步：攻击者使用MOO作为抵押品借出CELO。根据抵押借贷的常见逻辑，攻击者抵押了价值a的MOO，可借出价值b的CELO。
第三步：攻击者用贷出的CELO购买MOO，从而继续提高MOO的价格。每次交换之后，Moo对应CELO的价格变高。
第四步：由于抵押借贷合约在借出时会使用交易对中的实时价格进行判断，导致用户之前的借贷数量，并未达到价值b，所以用户可以继续借出CELO。通过不断重复这个过程，攻击者把MOO的价格从0.02 CELO提高到0.73 CELO。
第五步：攻击者进行了累计4次抵押MOO，10次swap（CELO换MOO），28次借贷，达到获利过程。
本次遭受攻击的抵押借贷实现合约并未开源，根据攻击特征可以猜测攻击属于价格操纵攻击。截止发文时，通过Beosin Trace追踪发现攻击者将约93.1%的所得资金 返还给了Moola Market项目方，将50万CELO 捐给了impact market。自己留下了总计65万个CELO作为赏金。[2022/10/19 17:32:31]
2.0x7E0c621Ea9F7aFD5b86A50B0942eAee68B04A61Cproxy合约，changeAdmin方法内部调用追踪到304行，实际写入key为ADMIN_SLOT，但读取key却为ADMIN_SLOT。即O(欧)和0(零)的一个细微差异，让changeAdmin方法完全失效，从而达到了已经移交权限的假象
三、结论和经验
1.高度警惕任何包含proxy方式合约的项目，若未经timelock约束，合约有被瞬间替换的风险
2.nevertrust，alwaysverify！不要相信项目方给出的timelock“证据”，对于未经审计的fork项目，务必逐个contract做好与原项目的diff(如果你做到了，就可以躲过meerkat的障眼法)
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。