攻击分析 | 未经检查的映射导致Nomad桥损失2亿美元

摘要

2022年8月2日，名为Nomad Bridge的跨链桥遭到攻击，损失近2亿美元。根本原因是链上智能合约升级版本中的检查不正确。

背景

Nomad Bridge是一个新兴的跨链资产桥，采用防欺诈证明设计。其工作原理如下：

Nomad在每个支持的区块链上部署一个名为Replica的核心合约，作为任何跨链消息的邮箱。
链下代理在默克尔树中传递和安排跨链消息，并通过向该合约发布签名的新的树根哈希来更新树根。
需要在链上确认的新消息必须经过prove()和process()两个步骤。
1. prove()步骤验证默克尔树中的消息和证明，然后将消息标记为已证明。
2. process()步骤在消息先前已证明且关联的树根已确认的情况下，检查并执行消息。

代码

在以太坊中，Replica是一个Beacon代理，部署在0x5d94309e5a0090b165fa4181519701637b6daeba。逻辑合约有两个版本，第一个版本部署在0x7f58bb8311db968ab110889f2dfa04ab7e8e831b，第二个版本部署在0xb92336759618f55bd0f8313bd843604592e27bd8。

我们首先检查逻辑合约的先前版本，特别是process()函数：

function process(bytes memory _message) public returns (bool _success) {
    bytes29 _m = _message.ref(0);
    // 确保消息是为该域名设计的
    require(_m.destination() == localDomain, "!destination");
    // 确保消息已被证明
    bytes32 _messageHash = _m.keccak();
    require(messages[_messageHash] == MessageStatus.Proven, "!proven");
    // 检查重入保护
    require(entered == 1, "!reentrant");
    entered = 0;
    // 更新消息状态为已处理
    messages[_messageHash] = MessageStatus.Processed;

我们只展示了这个函数的一部分。在这段代码中，计算了消息哈希，并对照messages映射检查该哈希，以确保此消息先前已证明，然后进行重入检查，最后更新消息状态。

我们还简要回顾了旧的prove()函数：

function prove(
    bytes32 _leaf,
    bytes32[32] calldata _proof,
    uint256 _index
) public returns (bool) {
    // 确保消息未被证明或处理
    require(messages[_leaf] == MessageStatus.None, "!MessageStatus.None");
    // 根据证明计算预期的根
    bytes32 _calculatedRoot = MerkleLib.branchRoot(_leaf, _proof, _index);
    // 如果根有效，则将状态更改为Proven
    if (acceptableRoot(_calculatedRoot)) {
        messages[_leaf] = MessageStatus.Proven;
        return true;
    }
    return false;
}

这里没什么特别的：重复检查，计算树根，如果可接受，则标记为已证明。因此，在Replica合约的旧版本中，所有已证明的消息都有一个特殊的标记（MessageStatus.Proven = 1）。

然后我们检查逻辑合约的第二个版本。对于新版本，我们首先检查prove()函数：

function prove(
    bytes32 _leaf,
    bytes32[32] calldata _proof,
    uint256 _index
) public returns (bool) {
    // 确保消息未被处理
    // 注意，这允许在新的根下重新证明。
    require(
        messages[_leaf] != LEGACY_STATUS_PROCESSED,
        "already processed"
    );
    // 根据证明计算预期的根
    bytes32 _calculatedRoot = MerkleLib.branchRoot(_leaf, _proof, _index);
    // 如果根有效，则将状态更改为Proven
    if (acceptableRoot(_calculatedRoot)) {
        messages[_leaf] = _calculatedRoot;
        return true;
    }
    return false;
}

我们立即注意到这里有一个重大变化：不知何故，开发人员决定将计算出的根记录为已证明状态，而不是特殊标记。对于这个函数来说，这没关系，因为默克尔树根哈希保证不为零。这也是合理的，因为一旦树根得到确认，任何使用此树根证明的新消息就可以执行。

然后我们检查新版本中的process()函数：

function process(bytes memory _message) public returns (bool _success) {
    // 确保消息是为该域名设计的
    bytes29 _m = _message.ref(0);
    require(_m.destination() == localDomain, "!destination");
    // 确保消息已被证明
    bytes32 _messageHash = _m.keccak();
    require(acceptableRoot(messages[_messageHash]), "!proven");
    // 检查重入保护
    require(entered == 1, "!reentrant");
    entered = 0;
    // 更新消息状态为已处理
    messages[_messageHash] = LEGACY_STATUS_PROCESSED;

我们注意到messages[_messageHash]这一行。检索不存在的映射条目会返回零，这是一个常见的陷阱。 在这个上下文中，这意味着与此消息哈希关联的默克尔树根为零。我们需要进一步检查这个零的结果。所以我们应该仔细检查新的acceptableRoot()函数。

function acceptableRoot(bytes32 _root) public view returns (bool) {
    // 这是为了向后兼容在先前版本下证明/处理的消息
    if (_root == LEGACY_STATUS_PROVEN) return true;
    if (_root == LEGACY_STATUS_PROCESSED) return false;

    uint256 _time = confirmAt[_root];
    if (_time == 0) {
        return false;
    }
    return block.timestamp >= _time;
}

基本上，这个函数检查confirmAt映射，以查看默克尔树根是否已确认。

不幸的是，在Replica合约的两个版本中，零哈希在初始化时都设置为1：

function initialize(
    uint32 _remoteDomain,
    address _updater,
    bytes32 _committedRoot, // 初始化时为零
    uint256 _optimisticSeconds
) public initializer {
    __NomadBase_initialize(_updater);
    // 设置存储变量
    entered = 1;
    remoteDomain = _remoteDomain;
    committedRoot = _committedRoot;
    // 预先批准已提交的根。
    confirmAt[_committedRoot] = 1;
    _setOptimisticTimeout(_optimisticSeconds);
}