Multichain项目漏洞攻防分析:从应急救援看Web3生态安全

2022年1月18日,我们的异常交易监测系统发现了针对Multichain项目的攻击。由于相关函数未能正确实现校验机制,导致用户授权给该项目的token可被攻击者取出。

虽然项目方尝试通过多种方式提醒受影响用户,仍有许多用户未能及时响应,攻击者得以持续实施攻击获利。

鉴于攻击持续进行,为保护潜在受害者,我们决定采取应急响应措施。本次救援针对以太坊上受影响的账户,我们将相关账户资金转移到专门设立的多签白帽账户中。为保证行动透明,我们将相关计划的文件哈希值(而非内容)向社区公开。我们的救援行动从2022年1月21日开始,到2022年3月11日结束。

应急救援面临诸多技术和非技术挑战。现在行动已结束,我们得以重新复盘整个过程,并将相关心得与社区分享。我们希望这样的分享对社区及DeFi生态的安全有所帮助。

简要总结

• 不同参与者对Flashbots的广泛使用产生了激烈竞争,包括白帽和攻击者两个群体之间及各自群体内部,向Flashbots支付的费用也随时间迅速增长。

• Flashbots并非总是有效。部分攻击者转而使用mempool,通过巧妙策略安排攻击交易,成功实施攻击。

• 某些攻击者与项目方达成协议,归还部分攻击所得,保留部分作为奖赏,得以成功"洗白"。这种现象引发了社区对其激励公平性的争议和讨论。

• 从透明性考量,白帽可在不泄露敏感信息的同时向社区宣告自身行为,这种取信于社区的方式在实践中表现良好。

• 社区各方力量可携手合作,使救援行动更为迅速和有效。例如可在白帽之间开展协同,减少或避免无效竞争。

攻击和救援情况概览

总体结果

在我们观察范围内(2022年1月18日至2022年3月20日),总体攻击和救援情况如下:

• 9个救援账户保护了483.027693 ETH,其中支付给Flashbots费用为295.970554 ETH(占比61.27%)
• 21个攻击账户获利1433.092224 ETH,其中支付给Flashbots费用为148.903707 ETH(占比10.39%)

值得注意的是,由于存在一些复杂交互情况(如某些攻击者与项目方协商后返还部分获利,相关地址标签可能变化),上述数据仅为大致统计。

Flashbots费用的变化趋势

白帽需要和攻击者竞争发送Flashbots交易来实施救援,支付给Flashbots的费用变化趋势可反映竞争激烈程度。我们按交易区块,对攻击和救援交易分别统计了Flashbots费用占比。

分析表明,早期攻击交易的Flashbots费用为0,表示当时攻击者尚未使用Flashbots。随后Flashbots费用占比快速上升,在某些区块甚至达到80%-91%。这一趋势反映了由于Flashbots上链权之争而导致的费用军备竞赛。

我们实施的救援行动和面临的挑战

救援行动的基本思路

我们的救援思路是监控一批潜在受害者账户,这些账户已将WETH授权给有问题的项目合约。当有WETH转入该账户时,我们利用合约漏洞将其转出至白帽多签钱包。关键是要满足以下要求:

1. 有效定位转账给受害者账户的交易(转账交易)
2. 正确构造交易实施拯救(拯救交易)
3. 成功抢跑攻击者(或其它第三方)交易(攻击交易)

前两项要求对我们而言不构成阻碍。然而第三项仍然是一个挑战,即便使用Flashbots也不总能保证成功。我们还需考虑费用设置策略、交易在mempool中的位置和顺序等因素。

竞争情况

我们尝试保护171个独立的潜在受害者账户。其中10个及时撤销授权实现了自我保护,在余下的161个账户中,由于各类竞争的存在,我们仅成功救援了14个。失败情况涉及3个救援账户和16个攻击账户。

经验教训

Flashbots费用设置策略

在救援过程中,我们先后被12个使用Flashbots的竞争者击败,包括2个救援账户和10个攻击账户。

我们的Flashbots费用设置策略较为保守,倾向于尽可能少地设置费用以保护受害者利益。然而实践证明这样的策略并不太成功,攻击者(甚至部分白帽)通常采用更激进的策略设置费用以赢得竞争。

我们观察到的一些案例显示,竞争者将Flashbots费用比例设置在70%-86%之间。这似乎是一个零和游戏,需要建模来探索各参与方的行为模式。在实践中,既要尽可能降低代价,又要找到较优策略赢得竞争,是一项具有挑战性的任务。

Mempool交易安排策略

由于多方引发的激烈竞争,Flashbots并非总是有效。在这种情况下,即便设置最高的Flashbots费用,也无法保证赢得竞争。

另一个可行方法是通过mempool发送普通交易,如果交易被安排在合适位置(即紧跟在转账交易之后),也可能实现目标。我们观察到一个攻击者运用这种策略成功获利312 ETH,且未支付任何Flashbots费用。

这种巧妙策略兼具实用性和启发性,值得关注和学习。

其他思考

白帽与攻击者的界定

识别白帽及其行为可能并不简单直白。我们观察到一个案例,某地址最初被标记为攻击者,后来被重新标记为白帽。这源于该地址与项目方达成协议,同意保留部分获利作为奖赏,返还其他获利。

这种现象不是首次出现,其激励的公平性在社区内引发了较大争议和讨论。

白帽间的协调机制

社区有必要建立沟通协调机制来降低/避免白帽之间的竞争。这种竞争不仅会浪费救援资源,还会提高救援成本。例如,在本次救援中,我们和其他三个白帽(组织)同时试图保护54个受害者(涉及450 ETH损失)。

如果没有相应协调机制,白帽们难以放弃/停止这样的竞争。

改进救援行动的建议

1. 白帽可在不泄露敏感信息的同时向社区公开宣告自身行为,以取信于社区。

2. 社区各方力量可携手合作,使救援更为迅速和有效:

   • Flashbots/矿工可向认证的可信白帽提供绿色通道
   • 被攻击项目方承担Flashbots费用成本
   • 项目方采用更便捷的机制及时向用户预警
   • 项目方在代码中采取必要的应急措施

通过各方协作,我们有望构建一个更安全、更高效的Web3生态系统。