事件概述

    今年五月底Optimism基金会聘请做市商Wintermute为op代币提供流动性，Optimism基金会为Wintermute团队提供2000万op代币用于做市。此过程中出现了沟通失误，Wintermute团队向Optimism基金会提供了Layer1(eth)上的收款账户，而此账户尚未在Layer2(Optimism)上部署，Optimism基金会向Layer2账户打款后，Wintermute团队发现了该问题，但在账户修复之前，攻击者提前取得了该账户权限，开始抛售账户中的op代币。

    时间线

    ●05.26&05.27-Optimism基金会向Wintermute团队提供的地址0x4f3a120e72c76c22ae802d129f599bfdbc31cb81分别打款1op和100万op作为账户测试。

    ●05.27-Optimism基金会向该地址打款剩余1900万op。

    ●05.30-Wintermute团队发现账户错误，联系Optimism基金会，并联系GnosisSafe团队请求协助取回资金。Wintermute团队在与Optimism基金会和GnosisSafe团队协商后，评估该账户目前仍是安全的，不会被Wintermute团队之外的人控制，在GnosisSafe团队的帮助下可以取回资金。并计划在06.07日修复账户权限。

    ●06.01-攻击者部署攻击合约，合约内硬编码了factory地址，说明此时攻击者已确定了完整的攻击流程。

    ●06.05-攻击者发起攻击，取得目标账户权限。并转出100万op到tornado进行兑换。

    ●06.09-Wintermute团队发表声明对此过失负全责，并会回购所有攻击者抛售的代币，同时要求攻击者归还剩余代币。声明发表4小时后，攻击者再次转出100万op到某私人账户。

    攻击路线

    1、所有GnosisSafe保险箱合约均由GnosisSafeproxyfactory合约部署，要获得目标地址控制权需要调用proxyfactory在此地址上部署proxy合约。

    2、攻击发生前，Layer2(Optimism)上的proxyfactory合约尚未部署，攻击者通过重放Layer1上factory合约的部署交易，在Layer2上部署新的factory合约。

    3、在Layer2上通过多次调用factory合约的createProxy方法部署proxy合约，不断累加factory合约的nonce，直到将proxy部署到目标地址。

    4、在调用createProxy部署proxy时，将masterCopy参数设置为攻击者控制的合约地址，masterCopy将作为proxy的implementation。至此攻击者得到目标地址的控制权。

    以太坊合约地址生成

    为了解释上述攻击路线为何可以在特定地址部署合约，我们需要了解一下以太坊的合约地址生成机制。