安全生产简析下meerkat跑路事件
一、核心问题
1.AdminUpgradeabilityProxy天然的负面影响一代理的逻辑合约可以被替换
2.AdminUpgradeabilityProxy权限没有移交timelock一项目方不受时间锁约束，可以随意使用1。所说的能力，替换逻辑合约最终项目方无限制地将正常合约替换成了攻击合约，卷款跑路。
安全团队：Defrost Finance被攻击事件简析:金色财经报道，据区块链安全审计公司Beosin旗下Beosin EagleEye安全风险监控、预警与阻断平台监测显示，Defrost Finance预言机被恶意修改，并且添加了假的抵押token清算当前用户，损失超1300万美元。攻击者通过setOracleAddress函数修改了预言机的地址，随后使用joinAndMint函数铸造了100,000,000个H20代币给0x6f31地址，最后调用liquidate函数通过虚假的价格预言机获取了大量的USDT。后续攻击者通过跨链的方式将被盗资金转移到了以太坊的0x4e22上，目前有490万美元的DAI在0x4e22地址上，有500万美元的DAI在0xfe71地址上，剩余300万美元的ETH被转移到了0x3517地址上。[2022/12/25 22:06:35]
二、现场还原(以BUSD池为例)?
慢雾：跨链互操作协议Nomad桥攻击事件简析:金色财经消息，据慢雾区消息，跨链互操作协议Nomad桥遭受黑客攻击，导致资金被非预期的取出。慢雾安全团队分析如下：
1. 在Nomad的Replica合约中，用户可以通过send函数发起跨链交易，并在目标链上通过process函数进行执行。在进行process操作时会通过acceptableRoot检查用户提交的消息必须属于是可接受的根，其会在prove中被设置。因此用户必须提交有效的消息才可进行操作。
2. 项目方在进行Replica合约部署初始化时，先将可信根设置为0，随后又通过update函数对可信根设置为正常非0数据。Replica合约中会通过confirmAt映射保存可信根开始生效的时间以便在acceptableRoot中检查消息根是否有效。但在update新根时却并未将旧的根的confirmAt设置为0，这将导致虽然合约中可信根改变了但旧的根仍然在生效状态。
3. 因此攻击者可以直接构造任意消息，由于未经过prove因此此消息映射返回的根是0，而项目方由于在初始化时将0设置为可信根且其并未随着可信根的修改而失效，导致了攻击者任意构造的消息可以正常执行，从而窃取Nomad桥的资产。
综上，本次攻击是由于Nomad桥Replica合约在初始化时可信根被设置为0x0，且在进行可信根修改时并未将旧根失效，导致了攻击可以构造任意消息对桥进行资金窃取。[2022/8/2 2:52:59]
1.项目方故意“坦诚”给出合约的timelock转移权限记录，展示的确执行了changeAdmin方法移交权限给timelock地址，用于混淆视听
Force DAO 代币增发漏洞简析:据慢雾区消息，DeFi 量化对冲基金 Force DAO 项目的 FORCE 代币被大量增发。经慢雾安全团队分析发现： 在用户进行 deposit 操纵时，Force DAO 会为用户铸造 xFORCE 代币，并通过 FORCE 代币合约的 transferFrom 函数将 FORCE 代币转入 ForceProfitSharing 合约中。但 FORCE 代币合约的 transferFrom 函数使用了 if-else 逻辑来检查用户的授权额度，当用户的授权额度不足时 transferFrom 函数返回 false，而 ForceProfitSharing 合约并未对其返回值进行检查。导致了 deposit 的逻辑正常执行，xFORCE 代币被顺利铸造给用户，但由于 transferFrom 函数执行失败 FORCE 代币并未被真正充值进 ForceProfitSharing 合约中。最终造成 FORCE 代币被非预期的大量铸造的问题。 此漏洞发生的主要原因在于 FORCE 代币的 transferFrom 函数使用了`假充值`写法，但外部合约在对其进行调用时并未严格的判断其返回值，最终导致这一惨剧的发生。慢雾安全团队建议在对接此类写法的代币时使用 require 对其返回值进行检查，以避免此问题的发生。[2021/4/4 19:45:30]
2.0x7E0c621Ea9F7aFD5b86A50B0942eAee68B04A61Cproxy合约，changeAdmin方法内部调用追踪到304行，实际写入key为ADMIN_SLOT，但读取key却为ADMIN_SLOT。即O(欧)和0(零)的一个细微差异，让changeAdmin方法完全失效，从而达到了已经移交权限的假象
三、结论和经验
1.高度警惕任何包含proxy方式合约的项目，若未经timelock约束，合约有被瞬间替换的风险
2.nevertrust，alwaysverify！不要相信项目方给出的timelock“证据”，对于未经审计的fork项目，务必逐个contract做好与原项目的diff(如果你做到了，就可以躲过meerkat的障眼法)
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。