撰文：CertiK
背景
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 我们可以看到这笔攻击交易.
受损合约（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）对应的逻辑合约被升级了。
逻辑合约升级交易。
逻辑合约被更新至 0xe7..f1。
最初的逻辑合约地址在这里能看到，为 0x9e..CD。
此时，我们怀疑黑客是更新代理合约的逻辑实现合约，将为 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 天前）的交易中，
我们可以看到受损合约 (0x29..1F) 合约最初的逻辑合约是 0x91..11，而在仅仅四分钟后，就在
被升级为了 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。
并且攻击 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。
救援交易：
原本攻击者是打算盗取这些资产的，可以看到 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 就停下来了，我们不得而知，可能需要知名链上侦探深入内部的调查了。
为什么攻击者没有把 17413ETH 转到 Ethereum 主网？
众所周知，Blast 主网是有可能通过中心化的方式拦截这些 ETH，让它永久停留在这里，从而不会造成实质上的用户损失，但是一旦这些 ETH 进入 Ethereum 主网，就没有办法拦截了。
我们评估了当前 Blast 的跨链桥，官方跨链桥没有限制数量，但是需要 14 天的退出时间，因此足以让 Blast 官方来准备拦截的计划。
而第三方的跨链桥是可以接近实时到账的，就像攻击者的手续费来源一样，很快完成跨链，为什么攻击者没有第一时间进行跨链？
实际上攻击者在第一时间（攻击的 2 分钟内）进行了跨链：
而且资金花了 20 秒就在 Ethereum 主网到账了，理论上攻击者可以持续不断进行跨链，可以在跨链桥人工干预之前，将大量 ETH 跨链转走。
至于为什么只能每次 3 ETH，原因是跨链桥的流动性限制，从 Blast 上跨到 ETH 上：
另一家支持 Blast 的跨链桥则支持的更少：
而在这一笔跨链交易后，攻击者没有继续其他的跨链操作，原因我们不得而知，看上去「某国黑客」似乎是没有为资金退出 Blast 进行充足的准备。
攻击后的事件发展
根据社区用户 Nearisbuilding 的反馈，他找到了攻击者的更多身份信息，并且想办法促使攻击者归还资金。
最终，在加密社区的关注和努力下，「某国黑客」也许因为害怕暴露身份，向项目方提供了以上 3 个攻击者地址的私钥，并归还了所有资金，项目方也进行了救援交易，把受损合约的资金全部转到多签合约进行保管。
