区块链应急救援行动复盘:经验与启示

2022年1月18日,我们的异常交易监测系统发现了针对AnySwap项目(即Multichain)的攻击。由于合约函数存在漏洞,用户授权给该项目的代币可被攻击者提取。尽管项目方尝试提醒用户,仍有很多用户未能及时撤销授权,导致攻击者持续获利。

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

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

主要发现:

• Flashbots的广泛使用导致白帽和攻击者之间,以及各自群体内部出现激烈竞争。支付给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抢跑,但实际操作并不容易。我们也使用mempool发送普通交易,需考虑交易在mempool中的位置和顺序。此外还要面对其他"白帽"的竞争。

竞争情况

我们尝试保护171个潜在受害账户,其中10个自行撤销授权,在剩余161个中我们仅成功救援14个。失败原因包括与3个救援账户和16个攻击账户的竞争。

经验教训

Flashbots费用设置

我们采用较保守策略设置Flashbots费用,以尽可能保护受害者利益。然而这种策略效果不佳,对手往往更激进,费用比例曾高达70%-86%。

这似乎是个零和博弈,需要在降低成本和赢得竞争间寻求平衡。

Mempool交易安排

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

有攻击者成功运用此策略获利312 ETH,且无需支付Flashbots费用。这种巧妙做法值得关注学习。

其他思考

区分白帽与攻击者

识别白帽并非总是直观。某些最初被标记为攻击者的账户,后来通过与项目方协商返还部分获利而"洗白"。这种做法在社区引发争议。

白帽间竞争

有必要建立协调机制减少白帽间竞争,避免资源浪费和成本提高。在本次行动中,多个白帽组织同时试图保护同一批受害者,加剧了Flashbots费用上涨。

优化救援行动

建议:

• 白帽在不泄露敏感信息前提下公开宣告行为,以取信社区
• Flashbots/矿工为可信白帽提供绿色通道
• 项目方承担Flashbots费用
• 项目方改进用户预警机制
• 项目方在代码中加入应急措施

总之,社区各方协作可使救援更快速有效。本次经验对未来类似情况的处理具有重要参考价值。