🛑Example Vulnerability

Book an audit with Zokyo

Incorrect assumpiton of Ethereum client implementation

Bug bounty payouts

  1. lido: $100k

  2. rocket finance $100k

  3. Tranches: 44.8 eth

Current TVL of effected projects at the time of writing:

  1. $15.03 Billion

  2. $1.89 Billion

  3. $10.88 Million

Refrences and further reading links:

LogoRocketPool and Lido Frontrunning Bugfix ReviewMedium
LogoCode4renaCode4rena

In the ever-evolving world of blockchain, liquid staking has emerged as a transformative solution for participants unable to stake the required 32 ETH in the Ethereum 2.0 network. As a significant upgrade, Ethereum 2.0 is designed not only to enhance transaction processing capabilities but also to introduce improved security and scalability. Transitioning from Proof of Work (PoW) to Proof of Stake (PoS), Ethereum 2.0 ditches miners for validators. To become one, participants need to stake a significant 32 ETH, which given the price of Ether can be prohibitively expensive for many.

Liquid staking represents an innovative approach to traditional staking mechanisms on prominent blockchain networks. Rather than merely staking assets and waiting for returns, liquid staking introduces a layer of flexibility and liquidity that benefits users in multiple ways.

Users can stake their assets, contributing to the network's stability, and in return, they earn rewards. But what sets liquid staking apart is its ability to tokenize these staked assets. By turning them into tokens of equivalent value, users gain the ability to move, trade, or use these tokens as they wish, all while continuing to earn staking rewards.

Here's a step-by-step of how the process typically unfolds:

  1. Users initiate the process by depositing their assets into the liquid staking platform.

  2. The platform, in turn, pools these deposits and stakes these assets on the ethereum network to generate rewards.

  3. A portion of the rewards generated is allocated to users in proportion to their deposits.

  4. In parallel, the deposited assets are tokenized into a specific type of token, often compliant with popular standards like ERC-20. This token essentially represents a user's staked assets in a liquid form.

  5. Users can store, trade, or use this token like any other digital asset in their portfolio, offering unprecedented flexibility.

  6. Whenever users desire, they can convert these tokens back to their original assets.

In essence, liquid staking seamlessly merges the benefits of staking for network stability and rewards with the advantages of tokenized assets' liquidity.

Unmasking the Attack Vector

The upcoming vulnerability discussion stems from inherent structural issues between Liquid Staking Platforms (LSP) and outsourced node operators, coupled with certain challenges in the Ethereum 2.0 Beacon client.

To truly grasp the depth of this vulnerability, we must first acquaint ourselves with the inner workings of a typical Liquid Staking Platform.

Initially, like many, I was under the impression that the core team behind these platforms directly operated nodes. This understanding, however, proved to be a misconception. Instead of direct node operation, many LSP teams delegate this crucial task to third-party entities.

This operational model isn't exclusive to one platform; even some of the leading competitors in the liquid staking space follow a similar structure, entrusting third parties with node operations.

For a more detailed partnership example within the industry, you can refer to the relevant partnership announcements made by these platforms.

Let's delve into the architecture of the Ethereum 2.0 Beacon client.

As Ethereum evolves to its 2.0 version, it's pivoting from the Proof-of-Work (PoW) consensus to the Proof-of-Stake (PoS) mechanism. Integral to this transition is the introduction of an official Deposit Contract, designated by the address: 0x00000000219ab540356cBB839Cbe05303d7705Fa.

Below, you'll find the official code for this Deposit contract.

// https://github.com/prysmaticlabs/prysm/blob/develop/contracts/deposit/deposit_contract.sol#L101-L159
function deposit(
    bytes calldata pubkey,
    bytes calldata withdrawal_credentials,
    bytes calldata signature,
    bytes32 deposit_data_root
) override external payable {
    // Extended ABI length checks since dynamic types are used.
    require(pubkey.length == 48, "DepositContract: invalid pubkey length");
    require(withdrawal_credentials.length == 32, "DepositContract: invalid withdrawal_credentials length");
    require(signature.length == 96, "DepositContract: invalid signature length");

    // Check deposit amount
    require(msg.value >= 1 ether, "DepositContract: deposit value too low");
    require(msg.value % 1 gwei == 0, "DepositContract: deposit value not multiple of gwei");
    uint deposit_amount = msg.value / 1 gwei;
    require(deposit_amount <= type(uint64).max, "DepositContract: deposit value too high");

    // Emit `DepositEvent` log
    bytes memory amount = to_little_endian_64(uint64(deposit_amount));
    emit DepositEvent(
        pubkey,
        withdrawal_credentials,
        amount,
        signature,
        to_little_endian_64(uint64(deposit_count))
    );

    // Compute deposit data root (`DepositData` hash tree root)
    bytes32 pubkey_root = sha256(abi.encodePacked(pubkey, bytes16(0)));
    bytes32 signature_root = sha256(abi.encodePacked(
            sha256(abi.encodePacked(signature[:64])),
            sha256(abi.encodePacked(signature[64:], bytes32(0)))
        ));
    bytes32 node = sha256(abi.encodePacked(
            sha256(abi.encodePacked(pubkey_root, withdrawal_credentials)),
            sha256(abi.encodePacked(amount, bytes24(0), signature_root))
        ));

    // Verify computed and expected deposit data roots match
    require(node == deposit_data_root, "DepositContract: reconstructed DepositData does not match supplied deposit_data_root");

    // Avoid overflowing the Merkle tree (and prevent edge case in computing `branch`)
    require(deposit_count < MAX_DEPOSIT_COUNT, "DepositContract: merkle tree full");

    // Add deposit data root to Merkle tree (update a single `branch` node)
    deposit_count += 1;
    uint size = deposit_count;
    for (uint height = 0; height < DEPOSIT_CONTRACT_TREE_DEPTH; height++) {
        if ((size & 1) == 1) {
            branch[height] = node;
            return;
        }
        node = sha256(abi.encodePacked(branch[height], node));
        size /= 2;
    }
    // As the loop should always end prematurely with the `return` statement,
    // this code should be unreachable. We assert `false` just to be safe.
    assert(false);
}

Once the deposit function is invoked, using parameters like pubkey, withdrawal_credentials, signature, and deposit_data_root, and the deposit finalizes, a DepositEvent is triggered.

This event prompts Ethereum 2.0 Beacon clients, including the likes of Prysm and Lighthouse, to refresh their staking states.

Below is the code implementation for the Prysm client.

// https://github.com/prysmaticlabs/prysm/blob/797cc360c77c650751499e375da2c96be9b32b69/beacon-chain/execution/log_processing.go#L89-L106
// ProcessLog is the main method which handles the processing of all
// logs from the deposit contract on the eth1 chain.
func (s *Service) ProcessLog(ctx context.Context, depositLog gethtypes.Log) error {
    s.processingLock.RLock()
    defer s.processingLock.RUnlock()
    // Process logs according to their event signature.
    if depositLog.Topics[0] == depositEventSignature {
        if err := s.ProcessDepositLog(ctx, depositLog); err != nil {
            return errors.Wrap(err, "Could not process deposit log")
        }
        if s.lastReceivedMerkleIndex%eth1DataSavingInterval == 0 {
            return s.savePowchainData(ctx)
        }
        return nil
    }
    log.WithField("signature", fmt.Sprintf("%#x", depositLog.Topics[0])).Debug("Not a valid event signature")
    return nil
}
...
// https://github.com/prysmaticlabs/prysm/blob/797cc360c77c650751499e375da2c96be9b32b69/beacon-chain/execution/log_processing.go#L108-L225
func (s *Service) ProcessDepositLog(ctx context.Context, depositLog gethtypes.Log) error {
    pubkey, withdrawalCredentials, amount, signature, merkleTreeIndex, err := contracts.UnpackDepositLogData(depositLog.Data)
    if err != nil {
        return errors.Wrap(err, "Could not unpack log")
    }
    // If we have already seen this Merkle index, skip processing the log.
    // This can happen sometimes when we receive the same log twice from the
    // ETH1.0 network, and prevents us from updating our trie
    // with the same log twice, causing an inconsistent state root.
    index := int64(binary.LittleEndian.Uint64(merkleTreeIndex)) // lint:ignore uintcast -- MerkleTreeIndex should not exceed int64 in your lifetime.
    if index <= s.lastReceivedMerkleIndex {
        return nil
    }

    if index != s.lastReceivedMerkleIndex+1 {
        missedDepositLogsCount.Inc()
        return errors.Errorf("received incorrect merkle index: wanted %d but got %d", s.lastReceivedMerkleIndex+1, index)
    }
    s.lastReceivedMerkleIndex = index

    // We then decode the deposit input in order to create a deposit object
    // we can store in our persistent DB.
    depositData := &ethpb.Deposit_Data{
        Amount:                bytesutil.FromBytes8(amount),
        PublicKey:             pubkey,
        Signature:             signature,
        WithdrawalCredentials: withdrawalCredentials,
    }

    depositHash, err := depositData.HashTreeRoot()
    if err != nil {
        return errors.Wrap(err, "unable to determine hashed value of deposit")
    }

    // Defensive check to validate incoming index.
    if s.depositTrie.NumOfItems() != int(index) {
        return errors.Errorf("invalid deposit index received: wanted %d but got %d", s.depositTrie.NumOfItems(), index)
    }
    if err = s.depositTrie.Insert(depositHash[:], int(index)); err != nil {
        return err
    }

    deposit := &ethpb.Deposit{
        Data: depositData,
    }
    // Only generate the proofs during pre-genesis.
    if !s.chainStartData.Chainstarted {
        proof, err := s.depositTrie.MerkleProof(int(index))
        if err != nil {
            return errors.Wrap(err, "unable to generate merkle proof for deposit")
        }
        deposit.Proof = proof
    }

    // We always store all historical deposits in the DB.
    root, err := s.depositTrie.HashTreeRoot()
    if err != nil {
        return errors.Wrap(err, "unable to determine root of deposit trie")
    }
    err = s.cfg.depositCache.InsertDeposit(ctx, deposit, depositLog.BlockNumber, index, root)
    if err != nil {
        return errors.Wrap(err, "unable to insert deposit into cache")
    }
    validData := true
    if !s.chainStartData.Chainstarted {
        s.chainStartData.ChainstartDeposits = append(s.chainStartData.ChainstartDeposits, deposit)
        root, err := s.depositTrie.HashTreeRoot()
        if err != nil {
            return errors.Wrap(err, "unable to determine root of deposit trie")
        }
        eth1Data := &ethpb.Eth1Data{
            DepositRoot:  root[:],
            DepositCount: uint64(len(s.chainStartData.ChainstartDeposits)),
        }
        if err := s.processDeposit(ctx, eth1Data, deposit); err != nil {
            log.WithError(err).Error("Invalid deposit processed")
            validData = false
        }
    } else {
        root, err := s.depositTrie.HashTreeRoot()
        if err != nil {
            return errors.Wrap(err, "unable to determine root of deposit trie")
        }
        s.cfg.depositCache.InsertPendingDeposit(ctx, deposit, depositLog.BlockNumber, index, root)

Upon examining the section that manages the Deposit Event, it's clear that the balance in the Beacon state, corresponding to the initially set Withdrawal credential for a specific pubkey, continues to augment. This indicates that the first-set Withdrawal credential remains persistent and dominant, even if there are subsequent attempts to alter it.

Vulnerability Overview: A malicious third-party node operator can exploit the Ethereum 2.0 Beacon client's Deposit Event handling mechanism. The attack revolves around "frontrunning" legitimate deposit transactions to manipulate the withdrawal credentials for the staked Ether.

Attack Breakdown:

  1. Initiation: A rogue validator, intending to exploit the system, prepares malicious deposit data.

  2. Frontrunning: Before a legitimate deposit transaction of 32 ETH takes place, the malicious node operator "frontruns" it by executing their prepared transaction.

  3. Malicious Deposit Data: This malicious transaction utilizes the same validator's public key (pubkey) as the upcoming legitimate deposit. However, it only deposits a minimum required amount (e.g., 1 ETH or 16 ETH in the case of certain platforms like RocketPool). Crucially, the withdrawal credential in this transaction is different from the one originally agreed upon with the protocol.

  4. System Behavior Exploitation: Due to how the Beacon client operates, if a pubkey hasn't been previously registered, the system would prioritize and process this new malicious deposit first, believing it to be the first time this validator's key is seen. As a result, when the genuine 32 ETH deposit transaction follows, the Beacon client simply adds this amount to the malicious operator's deposit.

  5. Outcome: The net result is that the staked 32 ETH now has the withdrawal credentials set by the attacker. Essentially, the malicious operator can now control and potentially withdraw these funds.

Impact: By exploiting this vulnerability, the malicious node operator can effectively divert and control staked assets meant for a legitimate node. This means the funds from unsuspecting pool users, expecting to stake under a set withdrawal credential, are now under the control of the attacker.

(If you haven't read our article on front running you can find it here)

Mitigation Steps for Frontrunning Attack in Ethereum 2.0 Staking Contracts:

  1. Verification of Node Operators' Keys:

    • Contracts must have the capability to verify that Node Operators' keys have not been used for any malicious pre-deposits. This can be done by cross-referencing with a predefined list of authorized keys.

  2. Establish a Deposit Security Committee:

    • Form a committee responsible for monitoring all deposit activities.

    • Their role includes validating the current state of deposits and affirming that available staking keys are safe for use.

  3. Use Merkle Root for Key Verification:

    • The staking contract (like Lido in the example) should fetch the Merkle root encoding of all keys used in staking deposits.

    • This Merkle root data will act as a point of reference to verify the authenticity of staking keys.

  4. Off-Chain Guardian Committee Verification:

    • To conserve gas costs, the Merkle root data should be checked and signed by an off-chain guardian committee. This committee will ensure that the data is accurate and untampered.

  5. Enforce Secure Deposit Transaction:

    • Implement a function named depositBufferedEther. This function ensures that buffered ether can only be sent to the staking contract if the following conditions are met:

      • The Merkle root data from the staking contract matches the on-chain Merkle root data.

      • Staking hasn't been paused.

      • A quorum of guardians has provided their signatures, ensuring the transaction's legitimacy.

      • There's a minimum block distance between deposits to prevent rapid, frequent deposits.

      • The block hash provided matches the expected hash for the given block number.

      • The staking keys operation index has not been tampered with.

  6. Transaction Verification:

    • The provided signatures should be verified against the staking contract's current state. If all conditions are met, the deposit transaction is approved and executed.

    • Otherwise, if any data point changes (due to a deposit, modification of approved staking keys, or a blockchain reorganization) before the deposit transaction, the staking contract will reject the transaction.

  7. Routine Updating of Deposit Transactions:

    • Regularly update the block number of the last deposit to monitor deposit frequency and maintain security measures.

By following these steps, staking platforms can significantly minimize the risk associated with the frontrunning attack, ensuring the integrity of staking operations.

PreviousUnderstanding Liquid Staking VulnerabilitiesNextExample Vulnerability 2

Last updated