Analysis of the FS Operations Group Incentive Pool Attack Process

TL;DR

由于激励池合约的 initialize 方法没有加上只能执行一次的限制,导致攻击者通过这个方法修改了合约的退款权限,将合约中 882 USDC 转走。

攻击过程分析

阿车在 2025-3-11 11:16:07(以下时间都是北京时间) 创建运营组激励池合约,创建合约的交易为:https://optimistic.etherscan.io/tx/0x5e400a4b58d2bc6b4a6cd9bd2605ffbedd79f1f95c2c11aca7950f7b90f91c82,激励池合约地址为:https://optimistic.etherscan.io/address/0x58717c5702bf611aeb8f4fd0a83ee32fc66078e8

然后经过国库在 2025-3-12 22:43:25 向激励池中转入 1800 USDC,交易为:https://optimistic.etherscan.io/tx/0x701518e762f1e1b73802191c99335d789084dfea99317b7f1a89da736d4d2cc5

激励池总共向 4 名 Builder 发放激励,其中两名分别在 2025-3-13 00:43:352025-03-13 10:41:19 完成激励的 Claim,激励池剩下 882 USDC。

攻击者在 2025-3-13 11:20:17 完成攻击合约的部署,交易为 https://optimistic.etherscan.io/tx/0x873527630b7c608507e12b7b656547a3b71086a36f2f3fc55dfb09efc85841fd,部署完成之后,向合约从充值了少量 eth。

然后在这笔交易中发起攻击:https://optimistic.etherscan.io/tx/0x61f97b5e1143eddc13379879eb4e771a20a7da78bfa5720450c6be855df7be73,通过这笔交易的状态变化可知,是在一笔交易中完成了对 initialize 方法的调用,并立即完成退款操作,导致合约中 882 USDC 被转走:

阿车在 2025-03-13 21:08 在 FS 开发群发出了这笔被攻击的交易,通过在线会议分析,在 2025-03-13 22:20 左右基本确定合约是被攻击了,随后阿车在活跃群让大家 claim 激励,并将无法立即 claim 的激励发起退款,最终确定损失 882 USDC。

后续处理方案

  • 剩余没有 Claim 的激励已经通过 safe 多签发给个人
  • FS 开发组会修复已经发现的安全问题,测试完成之后会重新部署代码和合约
  • FS 开发组会对这个安全问题负责,后续安全的修复工作无法获取激励
1 Like

上周六才听说了,被攻击事件。首先感觉还是挺惋惜的。不过还是引以为戒好。最后资金去了Li.Fi(似乎也无法继续追踪)。很多这种事真的是防不胜防!

同时,在上周六会议也提到是否可以通过,监控智能合约来实现对于安全事件或其他情况进行预警并自动推送通知。
目前市面上,市面上已经这样商业监控智能合约服务(如Tenderly、Moralis等平台已有提供,并实行阶梯收费)。当然自建监控服务其实难度也不大。理论上可以对一些智能合约变化(如:交易,事件)是能做到具体监控,第一时间了解相关情况。
下面是一个简单交易监听自动推送飞书服务:



但是现实实践还是有一些问题。

在自建监控服务中,通常是利用web3库(如:ethers.js,web3.js,viem等)连接节点JSON-RPC(如:Infura,Alchemy)的服务进行构建,通过定期轮询事件监听交易监听实现监控智能合约变化,并通知相关社交软件(如:email,feishu,TG等)。

由于现在市面上节点免费提供JSON-RPC服务并不稳定,做到一定有效频率定期轮询监控智能合约关键变量状态变化(如:owner/admin operators initialized等)比较不稳定或者麻烦。剩下就只有事件监听交易监听。相对来说交易监听某意义在安全上属于事后了解了,无法达到真正预警事件监听则需要合约暴露关键变量变化进行监听。例如在上周安全事件中,即使有了一定的外部监控,可能也只能监控已转账与转账事件,无法第一时间得知具体的地址被修改。

如果未来要进行外部进行合约监控,还要进行事件暴露等其他方式,同时还需要提供ABI(以及关键字段说明与定制等等),这些可能都需要沟通协调

合约监听似乎无法解决这个案例?

这事就要看怎么弄了!如果是上面的那个案例。确实没什么办法,从外部监控第一时间发现(当然启用定期轮询方式能够知道,但是不稳定)。如果在合约内部,对关键可变更状态变量增加了一旦变更,然后就执行事件,外部自然能够第一时间获取并推送。(当然这个可能增加一点执行GAS(这个不重要),关键都知道是敏感变量,也自然加强防护与限制了,比如设置了owner权限或者执行条件限制了。一般也不会出问题。就怕不知道哪儿是关键部位,啥都没有!最后只能看着第一时间被转账才知道)。所以说,需要合约开发者,检索合约,梳理关键变量,并把大多数情况增设事件化。

看到黑手册群里的一个分享:

团队做了个链上监控的工具 https://tenmonitor.com/ ,欢迎有需要的朋友试试哈

https://x.com/TenArmorAlert/status/1902197107445882910

1 Like

其实TenMonito上主要是做的资金追踪,漏洞追踪好像也不是太稳定(需要单独定制)。其实一般情况下拿玩意主要做的还是来追踪巨鲸(我一般看这种应用比较多)。类似下面这种:

1 Like