How Was Sumer Money Exploited?

TL;DR

On April 12, 2024, Sumer Money was exploited on the Base chain due to a smart contract vulnerability, which resulted in a loss of assets worth approximately $310,000.

Introduction to Sumer

Sumer is a cross-chain synthetic asset protocol with a lending and borrowing market deployed simultaneously on major chains.

Vulnerability Assessment

The root cause of the exploit is a lack of reentrancy protection, which led to the manipulation of the underlying assets.

Steps

Step 1:

We attempt to analyze the attack transaction executed by the exploiter.

Step 2:

The exploiter initially took a flash loan of a substantial amount of assets from Balancer Vault, including 150 WETH and 645,000 USDC.

Step 3:

Using the borrowed assets, the attacker first interacted with sdrETH and then with sdrUSDC markets to mint the associated tokens. At this point of time, the exchange rate between ETH and sdrETH tokens was 1:1.

Step 4:

In the vulnerable contract, the repayBorrowBehalf function allows external callers to repay a loan on behalf of another borrower. Within this function, if the received ETH amount is greater than the borrowed balance, the excess ETH is sent back to the sender using a low-level call with an empty data payload.

function repayBorrowBehalf(address borrower) external payable {
  uint256 received = msg.value;
  uint256 borrows = CEther(payable(this)).borrowBalanceCurrent(borrower);
  if (received > borrows) {
    // payable(msg.sender).transfer(received - borrows);
    (bool success, ) = msg.sender.call{value: received - borrows}("");
    require(success, "Address: unable to send value, recipient may have reverted");
  }
  (uint256 err, ) = repayBorrowBehalfInternal(borrower, borrows);
  requireNoError(err, "repayBorrowBehalf failed");
}

Step 5:

The attacker then manipulates the exchange rate and the internal state of the contract by borrowing against all of the assets held in the contract. A reentrancy call was triggered by repaying a very small amount of underlying assets, allowing the attacker to manipulate the state mid-transaction.

Step 6:

Due to a stale and incorrectly updated exchange rate, the attacker was able to redeem all tokens. The borrowed flash loan was repaid, and they were able to retain approximately $310,930 worth of assets.

Aftermath

The team has yet to make an official announcement regarding the occurrence of the incident. At the time of this writing, all of the stolen assets are held at this address, likely controlled by the hacker.

Solution

To protect smart contracts against vulnerabilities such as those exploited in the case of Sumer Money, several comprehensive strategies can be deployed. One effective method to prevent reentrancy attacks involves the implementation of reentrancy guards. A mutual exclusion lock, or mutex, can be integrated into functions that make external calls, ensuring that these functions are not re-enterable while they’re still in execution. This simple boolean lock/unlock mechanism is crucial in maintaining state consistency throughout the transaction’s lifecycle.

Adhering to the checks-effects-interactions pattern is another critical security practice. Functions should be structured so that all validations are performed first (checks), followed by state modifications (effects), and only then should interactions with external contracts occur. This sequence minimizes the risk of state changes being exploited through reentrant calls.

Accurate and timely updates of critical financial information, such as balances and exchange rates, are essential. These updates should be handled atomically and secured within the transaction flow to ensure that they reflect the actual system state before any external interactions take place.

Testing and simulations form the backbone of a robust security framework. Utilizing the available development frameworks like Hardhat enables developers to write comprehensive tests that cover various attack vectors, including reentrancy. Fuzzing, a technique used to test contracts under extreme conditions, and formal verification, a process that mathematically proves contract correctness under specific conditions, should also be employed to ensure contract resilience.

This article was originally published by Pukar Acharya elsewhere.