项目漏洞救援行动回顾与思考

2022年1月18日，我们的异常交易监测系统发现了针对某跨链项目的攻击。由于项目合约中的一个函数未正确实施校验机制，导致用户授权给该项目的代币可被攻击者提取。

尽管项目方尝试多种方式提醒受影响用户,仍有许多用户未能及时响应,攻击者得以持续实施攻击获利。鉴于攻击持续进行,为保护潜在受害者,我们决定采取应急响应措施。本次救援针对以太坊上受影响的账户,我们将相关账户资金转移到专门设立的多签白帽账户中。为确保行动透明,我们将相关计划的文件哈希向社区公开,既区分了我们与攻击者的行为,又不会泄露细节。救援行动从2022年1月21日开始,3月11日结束。

应急救援面临诸多技术和非技术挑战。行动结束后,我们复盘了整个过程,希望分享相关经验,为社区和DeFi生态安全提供帮助。

救援情况概述

在我们观察的时间范围内(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费用占比。

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

救援行动实施与挑战

救援的基本思路是监控潜在受害账户,当有WETH转入时,利用合约漏洞将其转出至白帽多签钱包。关键是要满足以下要求:

1. 有效定位转账给受害者的交易
2. 正确构造拯救交易
3. 成功抢跑攻击者交易

前两项对我们而言不构成障碍,但第三项仍具挑战性。虽然可用Flashbots抢跑,但由于采用费用竞拍模式,成功率取决于费用高低,策略设置需额外考量。此外,mempool发送普通交易时交易位置和顺序也是关键因素。我们还与其他"白帽"产生了竞争,部分"白帽"行为较为可疑。

总体而言,我们试图保护171个潜在受害账户。其中10个及时撤销授权自我保护,在剩余161个中,由于各类竞争存在,我们仅成功救援14个。

经验教训

Flashbots费用设置

我们的费用策略较为保守,倾向于设置较低费用以保护受害者利益。然而这种策略并不太成功,攻击者和部分白帽通常采用更激进策略。例如:

• 某攻击者将费用比例设为70%
• 某白帽将费用比例设为79%-81%
• 另一攻击者将费用比例提高到86%

这似乎成为一个零和游戏,需要建模探索各方行为模式,在降低成本和赢得竞争间寻求平衡。

Mempool交易排序

由于多方激烈竞争,Flashbots并非总有效。使用mempool发送普通交易,如果安排在合适位置,也可能实现目标。一名攻击者运用这种策略成功获利312 ETH,且无需支付Flashbots费用。

其攻击交易巧妙地安排在受害者转账交易之后的相邻位置。这种策略兼具实用性和启发性,值得关注。

其他思考

白帽与攻击者的界定

识别白帽并非总是简单直白。例如,某地址最初被标记为攻击者,后来改为白帽。这源于项目方与攻击者协商,攻击者同意保留部分获利作为奖赏并返还其他获利。这种现象在社区引发了对激励公平性的讨论。

白帽间竞争

社区有必要建立协调机制以减少白帽间竞争。这种竞争会浪费救援资源,提高救援成本。例如,我们与其他三个白帽组织同时试图保护54个受害者,涉及450 ETH损失。

改进救援行动

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

2. 社区各方可携手合作,使救援更快速有效:

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

通过总结经验教训,我们希望未来的救援行动能更加高效,最大程度保护用户利益。