TL;DR#

On March 21, 2024, Super Sushi Samurai (SSS) was exploited on the Blast network due to a smart contract vulnerability, which resulted in a loss of over 1,310 ETH worth approximately $4.6 million.

Introduction to SSS#

Super Sushi Samurai is an on-chain social strategy-focused idle game played on Telegram and powered by the Blast network.

Vulnerability Assessment#

The root cause of the exploit is a double-token transfer vulnerability.

Steps#

Step 1:

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

Step 2:

The SSS token was deployed with a transfer logic bug that allowed anyone to transfer tokens to themselves, thereby creating an infinite mint scenario.

Step 3:

The transfer function makes an internal call to the `_update` function from within the contract.

/**
 * @dev Moves a `value` amount of tokens from `from` to `to`.
 *
 * This internal function is equivalent to {transfer}, and can be used to
 * e.g. implement automatic token fees, slashing mechanisms, etc.
 *
 * Emits a {Transfer} event.
 *
 * NOTE: This function is not virtual, {_update} should be overridden instead.
 */
function _transfer(address from, address to, uint256 value) internal {
  if (from == address(0)) {
    revert ERC20InvalidSender(address(0));
  }
  if (to == address(0)) {
    revert ERC20InvalidReceiver(address(0));
  }
  _update(from, to, value);
}

Step 4:

This update function is responsible for updating the balances of the sender and receiver and is customizable for token transfers, minting, and burning.

function _update(address from, address to, uint256 amount) internal virtual override {
  // don't check if it is minting or burning
  if (from == address(0) || to == address(0) || to == address(0xdead)) {
    super._update(from, to, amount);
    return;
  }

  _botCheck(from, to);
  uint256 fromBalanceBeforeTransfer = _preCheck(from, to, amount);

  uint256 amountAfterTax = amount - _taxApply(from, to, amount);
  uint256 toBalance = _postCheck(from, to, amountAfterTax);

  _balances[from] = fromBalanceBeforeTransfer - amount;
  _balances[to] = toBalance;

  _unlockTokenForDev(from, to, amount);

  emit Transfer(from, to, amountAfterTax);
}

Here, the `amountAfterTax` is a value that is equal to the `amount` value after tax deduction, as the `taxPercent` is zero in this call.

Step 5:

Within the  `_postCheck` function, the ‘toBalance’ value will be equal to the current `_balances[to]` plus `amountAfterTax` values.

function _postCheck(address from, address to, uint256 amount) internal view returns (uint256 toBalance) {
  // check if buyer have too much token
  toBalance = _balances[to] + amount;
  if (
    limitIsInEffect() && maxAmountPerAccount > 0 && ((isLiquidityPool(from) && !isUnlimited(to))) // buy
  ) {
    uint256 limit = maxAmountPerAccount + LIMIT_ROUND_DEC;
    require(toBalance < limit, "Max token per account");
  }
}

Step 6:

The ‘_balances[from]` and `_balances[to]` values in the underlying `update` function are updated after the `_postCheck` implementation is completed. And, since the `from` and `to` addresses are the same in the transfer operation, both the `_balances[from]` and `_balances[to]` point to the same storage location.

Step 7:

Therefore, as the `_balances[to]` value is updated to the original value of `_balances[to]` plus the `amountAfterTax` value, which is equal to the `amount` value as stated in the above steps, anyone would effectively have doubled their token holdings each time a transfer call is made.

Aftermath#

The team acknowledged the exploit and stated that they have paused token transfers to further investigate the issue. On-chain data reveals that the incident was a whitehack rescue, and the hacker has asked the team to collectively work on reimbursing the affected users.

The white-hat rescue was successful in recovering 1,310.04 ETH worth of assets, while 40.28 ETH were stolen by some other black hat hackers. The team was also able to remove 29.09 ETH worth of liquidity. They also shared the details of the funds recovery for all of the affected users in this incident.

Solution#

To mitigate the exploit encountered by Super Sushi Samurai and prevent similar vulnerabilities in the future, a multi-faceted approach incorporating code refinement, diligent auditing, and ongoing security measures is vital. The immediate solution for the specific issue faced by SSS would have involved adding a conditional check within the transfer function to prevent transactions where the sender and receiver are the same address. This simple yet effective measure could have blocked the loophole that allowed for the unintended doubling of tokens.

The failure of the audit by Verichains to detect this critical vulnerability underscores the importance of carefully evaluating the credibility and effectiveness of auditing partners. Engaging multiple auditing firms can offer varied perspectives on security, potentially uncovering issues missed by others. Moreover, encouraging community reviews and offering rewards for discovered vulnerabilities can leverage the collective expertise of a broader audience, complementing formal audits. Keeping updated with the latest security practices and vulnerabilities is also crucial for developers and auditors.

Despite having strong security measures, the possibility of exploiting vulnerabilities persists. In these scenarios, Neptune Mutual plays a crucial role. By creating a dedicated cover pool with Neptune Mutual, the adverse effects of events like the Super Sushi Samurai exploit can be significantly minimized. Neptune Mutual focuses on offering coverage for losses that arise from smart contract vulnerabilities, utilizing parametric policies designed for these distinct risks.

Working with Neptune Mutual makes it easier for users to navigate the recovery process by eliminating the need for detailed proof of loss paperwork. Once an event is confirmed and resolved using our comprehensive incident resolution process, we quickly focus on providing compensation and financial aid to those affected. This method ensures swift support for users impacted by such security flaws.

Our services span several of the top blockchain platforms including Ethereum, Arbitrum, and the BNB chain, offering extensive support to a broad spectrum of DeFi users. This extensive coverage helps us protect against a variety of vulnerabilities, thereby increasing safety for our varied clientele.

Reference Source CertiK