Analysis of the Miner Exploit

TL;DR#

On February 14, 2024, Miner was exploited on the Ethereum Mainnet due to a smart contract vulnerability, which resulted in a loss of 168.8 ETH, worth approximately $466,000.

Introduction to Miner#

MINER is a collection of 100,000 avatars tied to the first tokens built on ERC-X, a fully optimized, experimental standard that enables the use of multiple token standards.

Vulnerability Assessment#

The root cause of the exploit is a double-transfer vulnerability caused by a lack of input validation.

Steps#

Step 1:

We attempt to analyze one of the attack transactions executed by the exploiter.

Step 2:

The affected and vulnerable contract had set its transfer functionality in such a way that it would only check to validate non-zero sender and receiver addresses without preventing the same address from being both sender and receiver.

function _transfer(address from, address to, uint256 value, bool mint) internal {
  if (from == address(0)) {
    revert ERC20InvalidSender(address(0));
  }
  if (to == address(0)) {
    revert ERC20InvalidReceiver(address(0));
  }
  _update(from, to, value, mint);
}

Step 3:

The transfer function would then invoke a call to the update function, which would permit the self-transfer of the tokens. Meaning anyone could effectively double their holdings by transferring the tokens to themselves.

function _update(address from, address to, uint256 value, bool mint) internal virtual {
  uint256 fromBalance = _balances[from];
  uint256 toBalance = _balances[to];
  if (fromBalance < value) {
    revert ERC20InsufficientBalance(from, fromBalance, value);
  }

  unchecked {
    // Overflow not possible: value <= fromBalance <= totalSupply.
    _balances[from] = fromBalance - value;

    // Overflow not possible: balance + value is at most totalSupply, which we know fits into a uint256.
    _balances[to] = toBalance + value;
  }

  emit Transfer(from, to, value);

  if (mint) {
    // Skip burn for certain addresses to save gas
    bool wlf = whitelist[from];
    if (!wlf) {
      uint256 tokens_to_burn = (fromBalance / tokensPerNFT) - ((fromBalance - value) / tokensPerNFT);
      if (tokens_to_burn > 0) _burnBatch(from, tokens_to_burn);
    }

    // Skip minting for certain addresses to save gas
    if (!whitelist[to]) {
      if (easyLaunch == 1 && wlf && from == owner()) {
        //auto-initialize first (assumed) LP
        whitelist[to] = true;
        easyLaunch = 2;
      } else {
        uint256 tokens_to_mint = ((toBalance + value) / tokensPerNFT) - (toBalance / tokensPerNFT);
        if (tokens_to_mint > 0) _mintWithoutCheck(to, tokens_to_mint);
      }
    }
  }
}

Step 4:

In this function, the `_balances[from]` parameter calculates the sender's balance minus the tokens sent but is then immediately overwritten by the cached `_balances[to]` parameter, which adds the sent value to the sender's balance, effectively doubling their holdings.

Aftermath#

The team acknowledged the occurrence of the exploit and urged users to refrain from buying the MINER tokens. According to them, they have saved roughly 130 ETH worth of liquidity. The team will likely redeploy a new contract or continue with the existing one if a fix can be initiated without redeploying.

They have also sent an on-chain message to the hacker offering a bounty of $120,000, equivalent to 30% of the exploited funds, with hopes of recovering the stolen assets.

Reportedly, one of their team members tried to blacklist the hacker but instead ended up whitelisting them first and then blacklisting them. The exploiter was quick to redeploy another contract to carry on exploiting. The social media channels of the protocol on X (formerly Twitter) list their creation date as February 2024. The underlying token of the exploited protocol was only launched three days prior to this exploit.

Solution#

In addressing the recent exploit of the Miner, it's crucial to reflect on the comprehensive measures that can be adopted to mitigate such vulnerabilities in the future and ensure a more robust security framework for smart contracts. A pivotal aspect that came to light was the engagement of an audit firm that, despite its efforts, overlooked some common bugs. This highlights the essential need for thorough and rigorous auditing processes. Choosing well-established and reputable audit companies with a proven track record of identifying vulnerabilities in smart contracts is paramount. However, the responsibility does not solely lie with the audit firms; smart contract developers should engage multiple auditors to cross-verify the security of their code. This multi-layered approach to auditing can significantly reduce the risk of overlooking critical vulnerabilities.

The incident also underscores the inherent risks associated with newly launched protocols and tokens. The Miner protocol, having been created recently with its token deployed merely days before the exploit, serves as a stark reminder of the volatility and uncertainty surrounding new projects. Investors should exercise caution and conduct extensive research before investing in newly minted assets. A critical evaluation of the project's development team, audit reports, and security practices can provide valuable insights into its credibility and stability.

To mitigate and prevent such issues, adopting best practices in smart contract development is crucial. Ensuring rigorous input validation, implementing secure coding standards, and avoiding common pitfalls such as the double-transfer vulnerability are fundamental steps.

The exploit could have been prevented by adhering to a more comprehensive security protocol that includes formal verification. Formal verification is a mathematical approach to verifying the correctness of algorithms underlying a smart contract, ensuring that it behaves as intended under all possible conditions. This method, alongside traditional auditing, can provide a more solid foundation for smart contract security by identifying logical errors and vulnerabilities that might be missed during manual code review.

Despite having stringent security measures, the possibility of vulnerabilities being exploited persists. In these scenarios, Neptune Mutual plays a crucial role. By establishing a dedicated cover pool with Neptune Mutual, the adverse effects of incidents akin to the Miner exploit can be significantly mitigated. Neptune Mutual focuses on offering coverage for losses due to smart contract vulnerabilities, utilizing parametric policies designed specifically for these distinctive risks.

Collaborating with Neptune Mutual streamlines the recovery process for users by eliminating the necessity for comprehensive loss documentation. After an incident is confirmed and resolved through our comprehensive incident resolution framework, we immediately focus on the swift distribution of compensation and financial support to those affected. This method ensures quick aid for users impacted by such security breaches.

Our marketplace spans across several major blockchain platforms, including Ethereum, Arbitrum, and the BNB chain, offering extensive support to a broad spectrum of DeFi users. Our extensive network enables us to deliver protective measures against a variety of vulnerabilities, thereby increasing the safety for our varied clientele.

Reference Source BlockSec