Multichain攻击事件分析：白帽救援过程与DeFi安全启示

2022年1月18日，某异常交易监测系统发现了针对AnySwap项目（即Multichain）的攻击。由于合约函数存在漏洞，导致用户授权给该项目的代币可被攻击者取出。

尽管项目方尝试通过多种方式提醒受影响用户，仍有许多用户未能及时撤回授权，攻击者得以持续获利。

鉴于攻击持续进行，某安全团队决定采取应急响应措施。此次救援针对以太坊上受影响的账户，相关资金被转移到专门设立的多签白帽账户中。为保证行动透明性，相关计划的文件哈希（而非内容）向社区公开。救援行动于2022年1月21日开始，3月11日正式结束。

应急救援面临诸多技术和非技术挑战。现将整个过程的心得与体会分享如下,希望对DeFi生态安全有所帮助。

简要总结：

• 白帽和攻击者之间,以及各自群体内部对Flashbots的使用产生激烈竞争,支付费用也迅速增长。

• Flashbots并非万能,某些攻击者转而使用mempool,通过巧妙策略成功实施攻击。

• 部分攻击者与项目方达成协议,归还部分所得并保留部分作为奖励,从而洗白。这种做法在社区引发争议。

• 白帽可在不泄露敏感信息的同时向社区公开行为,这种取信方式效果良好。

• 社区各方力量协作可使救援更加迅速有效,如白帽之间开展协同以减少无效竞争。

以下从四个方面展开讨论:事件总体回顾、实施救援方法及面临挑战、心得体会,以及相关建议。

攻击和救援情况概览

总体结果:

在观察范围内(2022年1月18日至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费用为0,表明攻击者尚未使用Flashbots,竞争不激烈。随后费用占比快速上升,如在某区块达到80%,之后甚至达91%。这表明已演变为Flashbots上链权之争导致的费用军备竞赛。

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

救援基本思路:监控潜在受害账户,当WETH转入时利用漏洞将其转出至白帽多签钱包。关键在于:

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

前两点对我们而言不构成障碍。第三点仍具挑战性:

• 虽可用Flashbots抢跑,但攻击者也可能使用,费用设置策略需额外考虑
• 竞争激烈时Flashbots并非最佳选择,也需使用mempool发送普通交易
• 与其他"白帽"产生竞争,某些行为可能存在争议

我们尝试保护171个潜在受害账户。10个自行撤销授权,在余下161个中我们仅成功救援14个。失败情况涉及3个救援账户和16个攻击账户。

经验教训

如何确定Flashbots费用?

我们采取较为保守策略,尽量少设置费用以保护受害者利益。仅在出现成功攻击交易后才会略微提高费用比例。然而这策略并不太成功,对手通常更为激进:

• 某攻击者将比例设为70%
• 某白帽将比例设为79%、80%
• 另一白帽将比例设为81%
• 攻击者进一步提高至86%

这似乎成为零和游戏,需要在降低成本和赢得竞争间寻求平衡。

如何在mempool中正确安排交易位置?

由于激烈竞争,Flashbots并非总有效。通过mempool发送普通交易也是可行方法,关键在于安排在合适位置(紧随转账交易之后)。

某攻击者采用此策略成功获利312 ETH且无需支付Flashbots费用。如在某区块,受害者转账交易位于65,攻击交易位于66,成功获利50 ETH。

这种巧妙策略值得关注和学习。

其他思考

如何区分白帽和攻击者?

识别白帽并非总是直观。某账户最初被标记为攻击者,后经与项目方协商同意保留50 ETH作为奖励并返还其他获利,随后被重新标记为白帽。这种现象引发社区对激励公平性的讨论。

白帽之间的竞争

社区应建立协调机制以减少白帽间竞争。竞争会浪费救援资源,也会推高Flashbots费用。如不同白帽相继将费用比例提高至80%、81%。没有协调机制,白帽难以停止这种竞争。

如何更好地开展救援行动?

• 白帽可在不泄露敏感信息的同时向社区公开行为,以取信于社区
• 社区各方可携手合作:
  • Flashbots/矿工为可信白帽提供绿色通道
  • 项目方承担Flashbots费用成本
  • 项目方采用便捷机制及时预警用户
  • 项目方在代码中采取必要应急措施