Web3应急救援行动回顾与反思

2022年1月18日，我们的异常交易监测系统发现了针对AnySwap项目(即Multichain)的攻击。由于anySwapOutUnderlyingWithPermit()函数存在漏洞，用户授权给该项目的token可被攻击者盗取。

尽管项目方采取了多种方式提醒受影响用户(如发送交易提醒)，仍有许多用户未及时撤回授权，攻击者得以持续获利。

鉴于攻击仍在进行，为保护潜在受害者，BlockSec团队决定采取应急响应措施。我们主要针对以太坊上受影响的账户,将相关资金转移至专门设立的多签白帽账户中。为确保行动透明,我们将计划概要的文件哈希(非内容)向社区公开,既可区分我们与攻击者的行为,又不会泄露细节。救援行动从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费用占比。

最初一些攻击交易的Flashbots费用为0,表明攻击者尚未使用Flashbots。随后费用占比快速上升,在某些区块甚至达到80%和91%。这表明已演变为争夺Flashbots上链权的费用军备竞赛。

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

救援行动的基本思路

我们监控了一批已将WETH授权给问题合约的潜在受害账户。当有WETH转入这些账户时,我们利用合约漏洞将其转出到白帽多签钱包。关键是要满足以下三点:

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

前两点对我们而言不构成障碍,因为我们有监控mempool的系统和自动构造救援交易的工具。但第三点仍具挑战性。

虽然理论上可用Flashbots赢得抢跑,但实践中并非易事。首先,攻击者也可能用Flashbots,成功率取决于出价高低。其次,激烈竞争使Flashbots并非总是最佳选择,我们也会通过mempool发送普通交易。最后,我们还与其他"白帽"产生了竞争,而某些所谓"白帽"的行为其实颇为可疑。

竞争情况

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

经验教训

Flashbots费用设置

救援过程中,我们曾12次被其他竞争者击败,包括2个救援账户和10个攻击账户。

我们的策略较为保守,倾向于设置较低的Flashbots费用以保护受害者利益。除非已有成功使用Flashbots的攻击交易出现,否则我们不会主动使用或增加费用。然而,这种策略效果不佳,对手往往更为激进:

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

这似乎是一个零和博弈,需要建模探索各方行为模式。实践中既要尽量降低成本,又要找到最优策略赢得竞争,是一项极具挑战的任务。

Mempool交易排序

激烈竞争使Flashbots并非总能奏效。通过mempool发送普通交易,如果能安排在合适位置(紧随转账交易之后),也可能实现目标。

某攻击者运用这一策略成功获利312 ETH,且无需支付Flashbots费用。例如:

• 区块14051020:受害者转账交易位于65,攻击交易位于66
• 区块14052155:受害者转账交易位于161,攻击交易位于164

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

其他思考

白帽与攻击者的界定

识别白帽并非总是直截了当。例如,某账户最初被标记为攻击者,后来经与项目方协商,同意保留50 ETH作为奖励并返还其他获利,随后被重新标记为白帽。

这种现象并非首次出现,其激励机制的公平性在社区引发争议。

白帽间竞争

社区有必要建立协调机制以减少白帽间的竞争。这种竞争不仅浪费资源,还会推高救援成本。例如,我们与其他三个白帽组织同时试图保护54个受害者(涉及450 ETH)。没有协调机制,白帽们难以放弃或停止这种竞争。

改进救援行动

1. 白帽可在不泄露敏感信息的前提下向社区公开行动,这种做法效果良好。

2. 社区各方可携手合作提高救援效率:

   • Flashbots/矿工为可信白帽提供绿色通道
   • 项目方承担Flashbots费用
   • 项目方采用更便捷的用户预警机制
   • 项目方在代码中加入应急措施

通过各方共同努力,我们可以更好地应对Web3生态中的安全挑战,保护用户利益。