背景
Blast是由Blur的创始人Pacman(Tieshun Roquerre、aka.铁顺)推出的Ethereum Layer2网络,在2月29日启动主网,目前约有19500 ETH和640000 stETH质押在Blast主网。
被攻击的项目Munchables是Blast举办的Bigbang竞赛胜出的优质项目。
Blast官方对质押ETH在Blast主网的用户会发放普通积分:
为了鼓励用户参与Blast生态上的DeFi项目,Blast官方会挑选出优质项目进行推荐,并鼓励用户将ETH二次质押到DeFi里,可以获得更快的积分增加速度以及黄金积分,因此有相当多的用户将质押在Blast主网的ETH质押到了新创建的DeFi项目。
而这些DeFi项目的成熟度、安全性还有待考察,这些合约是否具有足够的安全考虑来保管用户的数千万、甚至上亿美元。
事件概述
Blast主网上线不到一个月,在2024年3月21日就发生了针对SSS Token(Super Sushi Samurai)的攻击,Token合约中存在一个转账逻辑错误,导致攻击者可以凭空增加指定账户的SSS Token余额,最终项目损失了超过1310 ETH(约460万美元)。
而在SSS Token攻击事件过去不到一周的时间,Blast上又发生了一起更大的攻击事件,Munchables项目被攻击者一把卷走了17413.96 ETH,共约6250万美元。
在这笔攻击交易发生的半小时后,项目方合约里的73.49 WETH也被黑客盗取到的另外一个地址。
此时项目方的合约地址上,还存着7276个WETH、7758267个USDB、4个ETH,随时会落入黑客手里,而黑客拥有拿走整个项目的所有资金的权限,共计约9700万美元暴露于风险之中。
在事件后发生的第一时间,X(Twitter)的知名链上侦探zachXBT指出本次攻击的根本原因是由于雇佣了某国黑客所致。
让我们深入看看,“某国黑客”是如何完成一次接近一亿美元的攻击。
现场还原
- 受害者发声
[UTC+0]2024年3月26日21点37分(攻击发生5分钟后),Munchables官方在X(Twitter)发文表示遭到攻击。
按链上侦探ZachXBT的调查,是因为他们有一位开发者是“某国黑客”,aavegotchi的创始人coderdannn也在X(Twitter)上表示:“Aavegotchi的开发团队Pixelcraft Studios在2022时曾短期雇用过Munchables攻击者来进行一些游戏开发工作,他技术很糙,感觉确实像一名某国黑客,我们在一个月内解雇了他。他还试图让我们雇用他的一位朋友,那个人很可能也是一名黑客。”
由于这次攻击让社区的用户损失巨大,我们立即启动了链上调查,让我们深入看看这个“某国黑客”的攻击细节。
- 第一现场
[UTC+0]2024年3月26日21点32分,涉及17413.96 ETH的攻击发生了。
通过Blastscan我们可以看到这笔攻击交易:https://blastscan.io/tx/0x9a7e4d16ed15b0367b8ad677eaf1db6a2a54663610696d69e1b4aa1a08f55c95
受损合约(0x29..1F)是一个代理合约,存放了用户质押的资金,我们可以看到,攻击者调用了质押合约的unlock函数,并通过了所有的权限校验,转走了合约中所有的ETH到攻击者地址1(0x6E..c5)。
看上去攻击者调用了一个类似withdraw行为的unlock函数,取走了受损合约(0x29..1F)上大部分ETH。
是项目方的金库忘了上锁吗?
受损合约(0x29..1F)中的unlock存在两个相关校验,我们一个一个来看。
首先,我们发现在校验权限的流程中,调用了合约(0x16..A0)的isRegistered方法来查看当前的msg.sender,也即是黑客地址1(0x6E..c5)是否已经被注册过:
答案是:通过了验证。
这里涉及到了合约(0x16..A0)以及其对应的最新的逻辑合约(0xe7..f1)
[UTC+0]2024年3月24日08点39分(攻击发生的2天前),合约(0x16..A0)对应的逻辑合约被升级了。
逻辑合约升级交易:
https://blastscan.io/tx/0x9c431e09a80d2942319853ccfdaae24c5de23cedfcef0022815fdae42a7e2ab6
逻辑合约被更新至0xe7..f1。
最初的逻辑合约地址在这里能看到,为0x9e..CD。
https://blastscan.io/tx/0x7ad050d84c89833aa1398fb8e5d179ddfae6d48e8ce964f6d5b71484cc06d003
此时,我们怀疑黑客是更新代理合约的逻辑实现合约,将为0x9e..CD变成恶意的0xe7..f1,完成了验证权限的绕过。
真的是这样吗?
在Web3.0从来不需要猜测和听信别人,你只需要掌握技术就能自己得到答案。
我们通过对比两份合约(未开源合约),最初的0x9e..CD合约与更新后0xe7..f1存在一些明显的区别:
0xe7..f1的initialize函数部分实现如下:
0x9e..CD的initialize函数部分实现如下:
可以看到,攻击者在最初的逻辑合约(0x9e..CD)中,将攻击者地址(0x6e..c5)设置为register,同时还有其他两个攻击者地址0xc5..0d、0xbf..87也被register了,并且它们的field0被设置为初始化时的区块时间,field0后面会解释用处。
实际上,和我们猜测的恰好相反,真正的藏有后门的逻辑合约,反而是最初就存在,而后面更新的反而是正常的!
等等,这个更新出现在[UTC+0]2024年3月24日08点39分(攻击发生的2天前),也就是在这个事件之前,逻辑合约已经变成没有后门的合约了,为什么后面攻击者还可以完成攻击?
这是因为delegatecall的原因,所以实际的状态存储更新是在合约(0x16..A0)中,这也就导致了即使之后逻辑合约被更新至没有后门的逻辑合约0xe7..f1,合约(0x16..A0)中被更改的slot依然不会恢复。
我们来验证一下:
可以看到,合约(0x16.....A0)中对应的slot是有数值的。
这使得攻击者能够通过isRegistered方法的校验:
攻击者之后再将后门合约更换为正常合约掩人耳目,其实此时后门早已种下。
另外,在unlock的流程中,还涉及到第二个校验:
对于lock时间的检查,这一部分是保证锁定的资产不会在未到期就被转走。
攻击者需要保证当unlock被调用时的区块时间大于要求的锁定过期时间(field3)。
这一部分校验就涉及到受损合约(0x29..1F)以及对应的逻辑合约0xf5..cd。
在[UTC+0]2024年3月21日11点54分(攻击发生的5天前)的交易中,
https://blastscan.io/tx/0x3d08f2fcfe51cf5758f4e9ba057c51543b0ff386ba53e0b4f267850871b88170
我们可以看到受损合约(0x29..1F)合约最初的逻辑合约是0x91..11,而在仅仅四分钟后,就在
https://blastscan.io/tx/0xea1d9c0d8de4280b538b6fe6dbc3636602075184651dfeb837cb03f8a19ffc4f
被升级为了0xf5..cd。
我们同样来对比两份合约,可以发现攻击者和之前一样,也在initialize函数做了手脚,
0xf5..cd的initialize函数部分实现:
0x91..11的initialize函数部分实现:
可以看到,很明显的,又是运用了同样的手法,将自己持有的ETH数量&解锁时间都进行了篡改,之后再替换回正常合约掩人耳目,当项目方和安全研究人员在Debug的时候,看到的逻辑合约全是正常的,而且由于合约均为未开源合约,更难以看清问题的核心。
至此,我们了解了这笔涉及17413 ETH的交易,攻击者是如何做到的,但是这个事件背后的信息,只有这么多吗?
我们上面的分析中,其实看到黑客在合约内部内置了3个地址:
0x6e..c5(攻击者地址1)
0xc5..0d(攻击者地址2)
0xbf..87(攻击者地址3)
而我们上面发现的攻击交易中只看到0x6e..c5,其他两个地址都做了什么?而且里面的address(0)、_dodoApproveAddress、_uniswapV3Factorty到底还隐藏着什么秘密?
- 第二现场
我们先来看看攻击者地址3(0xbf..87),通过同样的手法盗取了73.49 WETH:
https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233
并且攻击gas的来源地址(0x97..de),同时给0xc5..0d(攻击者地址2)和0xbf..87(攻击者地址3)都提供了手续费。
而攻击gas来源地址(0x97..de)的0.1 ETH的资金源头来自owlto.finance(跨链桥)。
0xc5..0d(攻击者地址2)收到手续费后,并未进行任何攻击,但它其实肩负了一个隐藏的计划,我们继续看下去。
实际上,根据官方的事后救援交易,原来受损合约(0x29..1F)地址上并不止73.49枚weth,直到攻击结束,也仍有7276.5 WETH & 7758267 USDB。
救援交易:
https://blastscan.io/tx/0x1969f10af9d0d8f80ee3e3c88d358a6f668a7bf4da6e598e5be7a3407dc6d5bb
原本攻击者是打算盗取这些资产的,可以看到0xc5..0d(攻击者地址2)这个地址原本是用来偷取USDB的。
这里的_dodoApproveAddress为0x0000000000000000000000004300000000000000000000000000000000000003
为usdb的address
0xbf..87(攻击者地址3)这个地址是用来偷取weth的:
这里的_uniswapV3Factory为0x0000000000000000000000004300000000000000000000000000000000000004
为weth的address
而0x6e..c5(攻击者地址1)负责盗取的是address(0),即是原生资产ETH。
攻击者通过设置field0,即可通过如下逻辑对对应资产进行盗取:
问题
- 为什么攻击者没有盗走所有资产?
理论上他可以盗取所有的资产,即剩下的WETH和USDB。
0xbf..87(攻击者地址3)只盗取了73.49 WETH,0xbf..87(攻击者地址3)其实完全可以把所有的7350 WETH拿走,也可以借助0xc5..0d(攻击者地址2)把7758267 USDB全部拿走,为什么只拿了一点点WETH就停下来了,我们不得而知,可能需要知名链上侦探深入内部的调查了。
https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233
- 为什么攻击者没有把17413ETH转到Ethereum主网?
众所周知,Blast主网是有可能通过中心化的方式拦截这些ETH,让它永久停留在这里,从而不会造成实质上的用户损失,但是一旦这些ETH进入Ethereum主网,就没有办法拦截了。
我们评估了当前Blast的跨链桥,官方跨链桥没有限制数量,但是需要14天的退出时间,因此足以让Blast官方来准备拦截的计划。
而第三方的跨链桥是可以接近实时到账的,就像攻击者的手续费来源一样,很快完成跨链,为什么攻击者没有第一时间进行跨链?
实际上攻击者在第一时间(攻击的2分钟内)进行了跨链:
https://blastscan.io/tx/0x10cf2f2b884549979a3a1dd912287256229458ef40d56df61738d6ea7d9d198f
而且资金花了20秒就在Ethereum主网到账了,理论上攻击者可以持续不断进行跨链,可以在跨链桥人工干预之前,将大量ETH跨链转走。
至于为什么只能每次3 ETH,原因是跨链桥的流动性限制,从Blast上跨到ETH上:
另一家支持Blast的跨链桥则支持的更少:
而在这一笔跨链交易后,攻击者没有继续其他的跨链操作,原因我们不得而知,看上去“某国黑客”似乎是没有为资金退出Blast进行充足的准备。
攻击后的事件发展
根据社区用户Nearisbuilding的反馈,他找到了攻击者的更多身份信息,并且想办法促使攻击者归还资金。
https://twitter.com/Nearisbuilding/status/1772812190673756548
最终,在加密社区的关注和努力下,“某国黑客”也许因为害怕暴露身份,向项目方提供了以上3个攻击者地址的私钥,并归还了所有资金,项目方也进行了救援交易,把受损合约的资金全部转到多签合约进行保管。
所有评论