Mobius代币爆炸性漏洞利用：铸造数万亿MBU的漏洞

Mobius Token 爆炸性漏洞：铸造了数万亿 MBU 的 Bug

Mobius 是一家 Stellar 生态系统中的区块链公司，旨在“弥合”传统互联网与去中心化应用程序世界之间的差距。 他们的 MOBI 代币为生态系统内的支付提供支持，并支撑着一系列服务：

• 钱包 — 一款移动应用程序，用于在 Stellar 网络上存储、发送、接收和交换加密货币；
• DApp 商店 — 一个去中心化的 DApp 市场，所有交易均以 MOBI 结算；
• 支付基础设施 和 SDK/API，用于将加密货币支付无缝集成到 Web 和移动应用程序中；
• Oracles（预言机） 和 Smart Markets（智能市场） — 用于将链下数据传递到智能合约并构建交易平台的模块。

根据 Cyvers Alerts 在 2025 年 5 月 11 日的报告，攻击者设法从 Mobius 智能合约中抽取了大约 215 万美元。

让我们来分析一下该项目的智能合约以及漏洞的核心。

首先，我们将确定关键地址和交易：

• MBU 代币地址： 0x0dFb6Ac3A8Ea88d058bE219066931dB2BeE9A581
• Mobius（受害者）合约： 0x95e92B09b89cF31Fa9F1Eca4109A85F88EB08531
• 攻击者的地址： 0xB32A53Af96F7735D47F4b76C525BD5Eb02B42600
• 漏洞利用合约（由攻击者部署）： 0x631adFF068D484Ce531Fb519Cda4042805521641
• 攻击交易的链接： https://bscscan.com/tx/0x2a65254b41b42f39331a0bcc9f893518d6b106e80d9a476b8ca3816325f4a150

现在让我们在 Tenderly 中检查此交易的详细信息。

代币流动

让我们分解一下此交易的关键步骤：

将 1 BNB 兑换为 stablecoin（稳定币）：

–1 BNB → +≈ 2 157 126 BSC-USD

大规模 MBU 铸造：

从零地址 (0x000…000) 铸造了天文数量的代币：+9 731 099 540 720 980 659 843 835 099 042 677 MBU

通过零地址发行：

零地址充当“minter（铸币者）”。

• –0.001 WBNB → +0.001 WBNB (通过 ERC1967Proxy)
• –9 731 099 570 720 980 600 000 000 MBU → +9 731 099 570 720 980 600 000 000 MBU (到实现合约)

Proxy（代理）合约收到铸造的 WBNB：

作为 BNB 包装流程的一部分，+0.001 WBNB 落在代理上。

Dust-size（小额） MBU 分配给 EOAs：

几个外部账户收到少量 MBU：400 005 MBU、266 670 MBU、333 330 MBU、333 330 MBU、166 665 MBU

限制范围内的合法铸造：

第二次 mint（铸造）调用发行 +28 500 000 MBU 以换取 –2 157 126 BSC-USD。

将 WBNB 解包回 BNB

代理/路由器转换 0.001 WBNB 并返回几乎所有原始 BNB：+0.001 WBNB 和 +0.999 BNB

该交易由地址 0xB32A53Af96F7735D47F4b76C525BD5Eb02B42600 发起，该地址首先在 0x631adFF068D484Ce531Fb519Cda4042805521641 上调用了该函数。与 Mobius 协议的所有交互都通过该合约进行。为了揭示其内部运作方式，我从 BscScan 获取了它的 bytecode（字节码）并通过 Dedaub 反编译器运行它。

结果，很明显该合约公开了三个关键函数：

• receive(): 使合约能够接受 BNB (ETH) — 如果没有它，任何简单的 ETH 转移到合约都会 revert（回滚）。

• withdrawERC20(address tokenAddress, address to): 一个通用的“sweep（清扫）”函数，用于合约持有的任何 ERC-20 代币：

  1. 在 tokenAddress 上调用 balanceOf(this) 以检索合约的整个代币余额。
  2. 将全部金额转移到指定的 to 地址。
  3. 在漏洞利用结束时使用，用于将任何剩余资金（USDT、WBNB、MBU 等）转移到攻击者的钱包。

withdrawERC20

• 函数 0xcd60b03d(address targetContract, address tokenAddress): 主要的漏洞利用入口点

用于漏洞利用的函数

从 BscScan 我们知道攻击期间使用的 calldata 是：

0xcd60b03d
00000000000000000000000095e92b09b89cf31fa9f1eca4109a85f88eb08531
0000000000000000000000000dfb6ac3a8ea88d058be219066931db2bee9a581

这解码为：

• _targetContract = 0x95e92B09b89cF31Fa9F1Eca4109A85F88EB08531 — 发生错误 mint（铸造）的“受害者”Mobius 合约；
• _tokenAddress = 0x0dFb6Ac3A8Ea88d058bE219066931dB2BeE9A581 — MBU 代币本身。

核心逻辑按以下步骤展开：

1. 检查和设置

• 验证调用是否来自授权地址（与 withdrawERC20 中使用的地址相同），以及 msg.value 是否大于 0 BNB。
• 确认 WBNB 地址 (0xbb4CdB…) 处有代码，因为包装 ETH 需要有效的 WBNB 合约。

2. 包装 BNB → WBNB

3. 利用 Vulnerable（有漏洞的）合约：

• 执行：varg0(_targetContract).deposit(WBNB, 10** 15);

4. 交换铸造的 MBU

5. 排干剩余的 BNB

换句话说，这个 helper（辅助）合约本身所做的仅仅是编排调用——漏洞利用并不存在于此。接下来，我们将深入研究处理 deposit（存款）的实际 Mobius implementation（实现）合约。

Proxy（代理）合约地址： 0x95e92B09b89cF31Fa9F1Eca4109A85F88EB08531

在撰写本文时，它已经切换了其实现。为了发现哪些参数在部署时传递给 proxy（代理），我找到了合约创建交易并提取了其 calldata。

在 proxy（代理）创建 calldata 的最末尾 — 在标准 bytecode（字节码）前缀和 metadata（元数据）之后 — 出现了 constructor（构造函数）参数：

...000000000000000000000000637d8ce897bb653cb83ba436cdf76bbe158f05b100000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000064c0c53b8b0000000000000000000000004cbbb1b6ab63b6b01f9309b0aa53a05962a4a66b00000000000000000000000036b7ec863c846d6050e489db1985e7f21a6c90d40000000000000000000000002a8f6052263ef761109d1cae051e9f4f49cffaf200000000000000000000000000000000000000000000000000000000

在最开始，我们看到了我们需要的 implementation（实现）地址：0x637d8Ce897bb653Cb83Ba436CDf76bBe158f05B1

我从 BscScan 获取了这个 implementation（实现）合约的运行时 bytecode（字节码），并通过 Dedaub 反编译器运行它。输出是可读的 pseudocode（伪代码） — 这就是漏洞隐藏的地方。

让我们仔细看看 deposit（存款）函数：

deposite 函数

deposit（存款）函数非常简洁，你可以清楚地看到 mint(msg.sender, v4) 处的代币 mint（铸造）。

我们可以注意到，在私有调用 0x3039 之后，v4 的值再也不会改变，这表明 v4 的计算方式存在错误。有两个函数处理此计算 — 0x3039 和 0x371b。让我们首先检查 0x3039。

0x3039

在快速审查中，我没有发现任何问题 — 0x3039 在逻辑上看起来不错。所以我立即将注意力转向 0x371b 函数。

0x371b

在这里，很明显该函数只是将代币数量乘以它们的价格：

v3 = v1 * varg1;

并且永远不会将结果除以 10**18 以调整小数位数。请记住，代币的价格和代币数量都使用它们自己的 decimal（小数）缩放。因此，v3 最终会被精确地膨胀 1⁰¹⁸ — 这正是使攻击者能够铸造天文数量的代币的原因。

感谢你的关注！😊

P.S. 在区块链中，没有 floating-point numbers（浮点数）：所有值都通过乘以 10**(decimals) 来缩放。在进行算术运算时，你必须始终记得除以（或乘以）相同的 10**(decimals) 以使结果保持在正确的缩放比例中。在这种情况下，缺少除以 10¹⁸ 是关键的 vulnerability（漏洞）。

P.P.S. 我自己得出这些结论 — 直接分析交易和合约 — 然后对照外部来源进行交叉检查以完成整个过程。

• 原文链接： coinsbench.com/explosive...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～