💀First Depositor Inflation Attack in Staking Contracts

Book an audit with Zokyo

First Depositor Inflation Attack in Staking Contracts

Overview:

The First Depositor Inflation Attack is a sophisticated vulnerability that allows the first depositor in a staking contract to manipulate the distribution of staking shares. This attack leverages the fact that the first depositor holds a significant advantage when no prior assets exist in the contract (i.e., totalSupply is 0). By strategically inflating the contract’s assets and exploiting share calculations, the attacker can drain future depositors' assets. A key challenge with this attack is its potential for front-running, which makes it difficult for regular users to avoid.

Attack Flow in a Staking Contract:

1. First Depositor Advantage:

   • Alice, as the first depositor, sends 10 wei of ETH to the staking contract.

   • Since the contract’s totalSupply is 0 (i.e., no assets have been staked), Alice receives an equivalent amount of staking shares—10 wei—due to the 1:1 ratio between deposited ETH and staking shares.

2. Inflating the Assets:

   • Alice then transfers a large amount of a staking derivative token (e.g., 99,999,999 wei of a staking token) directly to the contract. This dramatically inflates the contract’s total assets but does not proportionally mint new shares.

   • Now, the staking contract has 10 wei of staking shares but 100e18 wei worth of staking token assets.

3. Front-Running the Next Depositor:

   • A malicious attacker can use front-running techniques to monitor the blockchain for incoming transactions. This allows them to strategically place their deposit ahead of a legitimate user’s deposit, ensuring they secure the first depositor advantage.

   • Bob, an honest user, tries to deposit 19 ETH into the contract. However, Alice (or another attacker) can front-run Bob's transaction, ensuring that they benefit from manipulating the share-to-asset ratio before Bob's transaction is processed.

4. New Depositor’s Loss:

   • Bob deposits 19 ETH, expecting to receive shares proportional to his deposit.

   • Due to the inflated assets and manipulated share-to-asset ratio from Alice’s transfer, Bob receives only 1 wei of staking shares instead of the expected amount.

   • Alice can now claim the majority of the staking contract’s assets—108 ETH from 10 shares—while Bob only receives 10.81 ETH worth of assets despite depositing 19 ETH.

5. Bob’s Loss:

   • Bob suffers an immediate loss of approximately 8 ETH because the initial inflation caused by Alice’s manipulation of the asset-to-share ratio unfairly benefits the first depositor.

   • The front-running nature of this attack makes it difficult for honest users like Bob to avoid, as attackers can use faster transaction times and gas bidding to insert their transactions first.

Vulnerability Components:

• TotalSupply at 0: The attack is facilitated by the fact that the staking contract’s totalSupply is 0 when the first depositor enters, allowing them to mint a disproportionate amount of shares compared to future depositors.

• Asset Inflation: The attacker inflates the total assets by transferring large amounts of a token into the contract, causing an imbalance in the ratio of total shares to total assets, without minting additional shares.

• Front-Running: Attackers use front-running to monitor blockchain activity and strategically become the first depositor, ensuring they can execute the inflation attack before honest users deposit their funds.

• Rounding Errors: Due to rounding down in share calculations, subsequent depositors receive far fewer shares than they should, further compounding the loss to honest users.

Example of the Attack:

• Alice deposits 10 wei to mint 10 shares.

• Alice transfers 100e18 of a staking token to the staking contract, inflating the total assets.

• Bob attempts to deposit 19 ETH, but Alice front-runs Bob's transaction and ensures she benefits from the manipulated share-to-asset ratio.

• Bob receives only 1 wei of shares due to the rounding errors, and Alice withdraws 108 ETH, resulting in an 8 ETH loss for Bob.

Mitigation Strategies:

1. Seeding the Staking Pool:

   • To mitigate this attack, it’s recommended to seed the staking pool during the contract's deployment, ensuring that the totalSupply is non-zero. By having initial assets already in the pool, the first depositor loses the advantage of manipulating share distribution. This also discourages front-running by making the first deposit less valuable to potential attackers.

2. Allocating Initial Shares to the Zero Address:

   • Consider sending a small amount of initial shares (e.g., 1000 wei) to the zero address upon the contract’s creation. This significantly increases the cost of the attack by requiring the first depositor to pay a much higher cost to achieve the same advantage. Honest users would only lose a negligible amount of shares (e.g., 1000 wei), which wouldn’t impact their staking rewards.

3. Preventing Large External Transfers:

   • Limit or add validation checks for large external transfers that inflate the contract’s assets without minting new shares. By implementing logic that restricts large token deposits or requires proportional share minting, the contract can maintain a balanced share-to-asset ratio, preventing attackers from exploiting inflation.

4. Delayed Share Minting for the First Depositor:

   • Implement a mechanism that delays the share minting for the first depositor until a minimum threshold of assets has been deposited. This can prevent the first depositor from immediately gaining an outsized advantage and give other users time to enter the contract under fairer conditions.

Here's an example of a vulnerable staking contract that could be exploited by a First Depositor Inflation Attack, along with comments explaining where and how the vulnerability arises.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract VulnerableStakingContract {
    mapping(address => uint256) public balanceOf;
    mapping(address => uint256) public shares;
    uint256 public totalShares;
    uint256 public totalAssets;

    event Deposited(address indexed user, uint256 amount);
    event Withdrawn(address indexed user, uint256 amount);

    // Vulnerable deposit function
    function deposit() public payable {
        uint256 sharesToMint;

        // Step 1: Check if this is the first deposit (no assets, no shares)
        if (totalShares == 0) {
            // First depositor receives shares equal to their deposit amount
            sharesToMint = msg.value; 
        } else {
            // Step 2: Convert the deposit to shares based on the current ratio
            sharesToMint = (msg.value * totalShares) / totalAssets;
        }

        // Step 3: Mint shares to the depositor
        shares[msg.sender] += sharesToMint;
        totalShares += sharesToMint;

        // Step 4: Add the deposit to total assets
        totalAssets += msg.value;

        emit Deposited(msg.sender, msg.value);
    }

    // Vulnerable withdrawal function
    function withdraw(uint256 _shares) public {
        require(_shares <= shares[msg.sender], "Insufficient shares");

        // Step 1: Calculate how much ETH the user can withdraw based on their shares
        uint256 ethAmount = (_shares * totalAssets) / totalShares;

        // Step 2: Reduce the user's shares and the total shares
        shares[msg.sender] -= _shares;
        totalShares -= _shares;

        // Step 3: Reduce the total assets and send the ETH back to the user
        totalAssets -= ethAmount;
        payable(msg.sender).transfer(ethAmount);

        emit Withdrawn(msg.sender, ethAmount);
    }
}

Vulnerable Parts:

1. Initial Share Minting for First Depositor:

   • In the deposit function, if totalShares == 0, the first depositor is given an amount of shares exactly equal to their deposit.

   • Problem: The first depositor can manipulate the total assets by later transferring a large number of assets directly into the contract, inflating the asset base without minting new shares. This will unfairly reduce the number of shares that future depositors receive.

2. Share Calculation Based on Total Assets:

   • The contract calculates shares using (msg.value * totalShares) / totalAssets for non-first depositors.

   • Problem: If an attacker (the first depositor) inflates the totalAssets by transferring external tokens or assets, the number of shares issued to subsequent depositors (e.g., Bob) will be much lower than it should be. This leads to unfair losses for honest depositors.

How the Attack Works:

1. Alice deposits first: If Alice is the first depositor, she deposits a small amount (e.g., 10 wei of ETH), receiving an equivalent number of shares.

2. Alice inflates the assets: After minting her shares, Alice sends a large amount of another asset (e.g., 100e18 of a staking token) directly to the contract, inflating the totalAssets without creating new shares.

3. Bob deposits second: When Bob deposits 19 ETH, the inflated totalAssets causes the share calculation to round down. Bob only receives 1 share instead of a fair amount, while Alice can later withdraw a disproportionately large share of the total assets, effectively stealing Bob’s funds.