如何从完美无瑕的智能合约中窃取 1 亿美元

如何从完美智能合约中窃取 1 亿美元

PWNING

我的区块链冒险之旅还在继续！这次我通过披露一个严重的设计缺陷保护了 Moonbeam 网络，保护了各种 DeFi 项目中面临风险的超过 1 亿美元的资产。我获得了他们在Immunefi上的漏洞赏金计划的最高奖励金额 100 万美元，以及来自Moonwell的 5 万美元奖金（我猜这也是前 10 大最高的漏洞赏金之一？）

Delegatecall 和 Native Contracts

在报告了 Aurora 引擎中的漏洞 之后，我开始思考原生合约的 delegatecall 的其他潜在误用。delegatecall 的最初目的是提供一种机制，通过该机制，一个智能合约可以共享和重用另一个智能合约的代码，以避免重复代码存储的开销。原生合约通常是预构建的合约，它们实现特殊功能作为原始 EVM 的扩展。

现在，棘手的部分是：如果你 delegatecall 到一个原生合约，你可能会执行一些意想不到的功能，甚至是特权功能！但是，这些原生合约的开发者可能没有意识到这些功能的实际用户可能是其他人。在 Aurora 漏洞的案例中，原生合约只是假设调用者将始终是一个神奇的地址，因此硬编码的日志发射器导致了恶意提款漏洞。

还有哪些其他假设可能是错误的？当你执行 delegatecall 时，调用上下文是从前一个上下文继承的，包括 msg.sender 和 msg.value。从原生合约的角度来看，调用 delegatecall 的合约是透明的：它的调用者将被视为真正的用户。因此，如果调用了一个恶意合约，它可以冒充其调用者来操作原生合约！

Moonbeam 中的阴影

Moonbeam 和 Moonriver 都是与 EVM 兼容的平台。在 Moonbeam 运行时中，有一些预编译合约在 Moonbeam 和 Moonriver 之间共享。

Balance ERC-20 预编译为余额的原生代币（MOVR 和 GLMR）提供了一个 ERC-20 接口。实现 Erc20BalancesPrecompile 位于 moonbeam/precompiles/balances-erc20/src/lib.rs 中。

设计者没有考虑到 EVM 中 `delegatecall` 的用法。恶意合约可以将其 msg.sender 传递给预编译合约，以冒充其调用者。在这种情况下，预编译合约无法确定实际的调用者。攻击者可以增加受害者的授权额度，或者立即转移可用余额。

Asset ERC-20 预编译中也存在类似的问题，它提供了可互操作代币（xcKSM、xcDOT 等）的 ERC-20 原生实现。实现 Erc20AssetsPrecompileSet 位于 moonbeam/precompiles/assets-erc20/src/lib.rs 中。

但是，设计者确实考虑了 EVM 中 delegatecall 的用法。测试中的 ERC20Instance 合约已经实现了 approve_delegate()、transfer_delegate() 和 transferFrom_delegate()，并有测试用例来确保它们的有效性。不幸的是（或者，对我们来说，幸运的是！），事实证明设计逻辑无法正常工作，因此他们在他们的补丁中删除了相关代码。

这是一个简单的漏洞利用，可以在两种情况下重复使用：原生代币的 asset 地址是 0x0000000000000000000000000000000000000802，而原生代币的 asset 地址可能是 0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080。

Exploit.sol

完美的合约，还是完美的受害者？

我们如何利用这个设计缺陷？基本思路是请某人来触发你的恶意合约，例如，调用 POC 合约中的 trap()。

我们如何说服用户调用一些神秘的合约？通过空投！UNIH 代币背后的黑客已经展示了加密原生解决方案的网络钓鱼！任何想要在 uniswap 中出售空投代币的用户都必须调用恶意代币合约，以批准 DEX 花费他们的余额。由于 RUNE 代币的漏洞设计，其中只检查 tx.origin 而不是 msg.sender 是否获得批准，因此所有 RUNE 代币都可能被木马合约窃取。

网络钓鱼的想法很有创意，但它强烈限制了漏洞的潜在危害。我们希望找到一个更好的受害者，他：

1. 愿意调用你的合约
2. 不像用户那么聪明
3. 有钱！

谁是贫穷黑客最好的朋友？闪电贷提供商！他们持有大量资金，并根据你的意愿调用你的合约回调！在闪电贷回调中，他们被迫批准你未来转移他们的资产代币，即使它们是完美的合约！

一些 DEX 交易对支持回调到任意合约，例如 MoonRiver 上的 SolarBeam 和 Moonbeam 上的 StellaSwap。由于支持闪电贷，xcKSM 和 stKSM 之间的稳定币交易对也存在漏洞。如果一种代币可以从交易对中耗尽，那么另一种代币可以在一次兑换中移出，所有流动性将被清除。

现在，完美编写的合约变成了完美的受害者。在我报告时，最富有的漏洞合约是：

1. 0xea3d1e9e69addfa1ee5bbb89778decd862f1f7c5 在 Moonriver 上，SolarBeam LP 代币，价值 750 万美元
2. 0xa927e1e1e044ca1d9fe1854585003477331fe2af 在 Moonbeam 上，Stella LP 代币，价值 270 万美元
3. 0x77d4b212770a7ca26ee70b1e0f27fc36da191c53 在 Moonriver 上，xcKSM & stKSM 交易对，价值 240 万美元

这些代币价值约 1260 万美元，即使潜在损失为 10%，也已超过 100 万美元，这是 Moonbeam 提供的最高赏金奖励。但是真正的黑客不会被微不足道的成就所阻止，会有更疯狂的受害者吗？

Glimmer

原生代币 MOVR（在 Moonriver 上）和 GLMR（在 Moonbeam 上）相当于以太坊上的 ETH。要在 DeFi 协议中使用，它们必须包装在与 ERC-20 兼容的代币合约中，就像 WETH 一样。

Balance ERC-20 预编译提供了原生代币的原生包装器。没有任何已部署的协议使用它，因为官方包装的代币 WMOVR 和 WGLMR 被更广泛地采用。通过利用 Balance ERC-20 预编译的漏洞，我们能够从调用恶意合约的任何用户那里窃取原生代币余额。与 Asset ERC-20 预编译代币（例如 xcKSM 和 xcDOT，它们被 DEX 直接使用）不同，MOVR 和 GLMR 余额很少被智能合约使用。

大多数具有非零余额的合约都是多重签名钱包，这与外部拥有的帐户没有什么不同。唯一的例外，我们的一线希望，是 Moonwell 项目的 MGlimmer 合约。

Moonwell 项目是 Moonriver 上占主导地位的 DeFi 协议。它有近 2 亿美元的供应量和 1 亿美元可用于借款（在我报告时）。MGlimmer，或 Moonwell: mMOVR Token 是处理针对 MOVR 的借贷的特定合约，并且它的余额中有原生 MOVR。

MGlimmer.sol

很酷的是，当它将余额转移给用户时，它会将目标作为合约调用！这是一个简单的漏洞利用，可以获得花费所有 MGlimmer 余额的批准。

GlimmerExploit.sol

存储在漏洞合约中的余额不多（现在几千个MOVR）。尽管如此，你存入该合约的任何金额都将被视为此借贷协议中的抵押品。可以通过重复存款 -> 借款 -> 全部转回 -> 留下坏账程序来进一步增强漏洞利用。所有可借用的资产都可以被耗尽！

如果任何黑客拿走所有 1 亿美元的可借资产加上 DEX 交易对中 1200 万美元的漏洞代币，那么这绝对可以成为 DeFi 历史上前 10 名抢劫案之一！关于这些漏洞的另一个惊人的事实是，实际攻击可能非常隐蔽，仅保留未经授权的权限而不是立即窃取。由于合约本身是完美的，因此对于这些 DeFi 项目的开发者来说，几乎不可能找出问题所在！

负责任的披露

每个人都在熊市中挣扎。我不想伤害任何人，我想提供帮助，尤其是当他们是如此努力的团队时。因此，我尽力帮助项目团队了解根本原因并加快修补过程。

最初的情况非常复杂。缺陷在于区块链系统的深层核心，但受害者是建立在其之上的 DeFi 协议。一些协议可能有紧急出口来暂停和升级他们的合约，而另一些协议则是不可变的。

最终的补丁必须由 Moonbeam 团队制作，但最大的受害者 Moonwell 可以在 Moonbeam 采取行动之前缓解此漏洞。我注意到 Moonbeam 和 Moonwell 都在 Immunefi 上启动了他们的赏金计划，因此我与 Immunefi 团队讨论了潜在的特殊情况（没有透露项目的具体名称）。在意识到其他项目，例如 uniswap 风格的 DEX，实际上无法做任何有用的事情之后，我决定不向他们报告，以最大程度地减少泄露关键信息的风险。由于只有 Asset ERC-20 问题可能对 Moonwell 团队来说是个问题，所以我必须将 Moonbeam 的报告分为两部分，只向他们提交必要的信息和独有的 GlimmerExploit POC。

我对 Moonbeam 团队格外小心，即使他们可能没有意识到这一点。我花了更多的时间学习他们的代码库并编写了两个完整的测试用例（600+LOC），以防他们需要更多关于根本原因的解释。我在他们的 discord 中询问了 PureStake 团队的常用时区，以确保我在第一位工程师上班后立即提交报告。幸运的是，它奏效了：他们从星期五开始处理这个问题，并在周末之前完成了补丁，没有任何询问！

这是隐藏在基于区块链的智能合约核心设计附近的最后一个意想不到的缺陷吗？当然不是！对于每个 delegatecall，在黑暗中还隐藏着另一个更疯狂的问题。总有其他更奇特的问题等着我！在我的旅程中与我同行，我将找到这些错误，将它们推向光明，并使区块链对每个人都更安全！

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