How Was Steam Swap Exploited?

TL;DR

On June 6, 2024, Steam Swap was exploited across two different transactions on the BNB chain due to a smart contract vulnerability, which resulted in a loss of assets worth approximately $105,000.

Introduction to Steam Swap

Steam Swap is a decentralized digital asset trading platform dedicated to bridging the global digital asset trading markets.

Vulnerability Assessment

The root cause of the exploit is due to the price manipulation of the underlying assets.

Steps

Step 1:

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

Step 2:

The vulnerable MineSTM contract has a sell function that uses a reserve pair for liquidity calculation. Notably, this exploited contract was deployed roughly 16 hours before the incident took place.

function sell(uint256 amount) external {
  eve_token_erc20.transferFrom(msg.sender, address(this), amount);
  (, uint256 r1, ) = inner_pair.getReserves();
  uint256 lpAmount = (amount * inner_pair.totalSupply()) / (2 * r1);
  uniswapV2Router.removeLiquidity(address(usdt_token_erc20), address(eve_token_erc20), lpAmount, 0, 0, msg.sender, block.timestamp);
}

Step 3:

The exploiter initially took a flash loan of 500,000 BSC-USD and used it to purchase roughly 2,740,041 STM tokens. The exploiter was able to manipulate this reserve balance by swapping a large amount of these tokens, and then ultimately called the above sell function to complete their attack.

Step 4:

The excess of the STM tokens were sold for profits worth approximately $91,670 before repaying the borrowed flash loan.

Step 5:

Another attacker, likely a copycat of the original exploiter, executed yet another attack transaction to profit by roughly $13,892.

Solution

The recent exploit of Steam Swap underscores the vital need for comprehensive security measures in smart contracts, especially given the sophisticated nature of this particular attack. Addressing the vulnerability observed in the reserve liquidity pair requires implementing stricter validations when processing sell functions in contracts. This could involve more robust calculations of liquidity based on accurate, real-time reserve checks, potentially integrating mechanisms like time-weighted averages to mitigate the risk of price manipulation.

Preventing price manipulation is critical, and one effective strategy is employing ChainLink like Oracle services to provide reliable price feeds rather than solely depending on internal reserves, which can be easily distorted through market maneuvers such as flash loans.

The fact that the contract was exploited shortly after its deployment raises concerns about its initial security measures. It suggests the possibility of an inside job or a deliberate act to deceive, leading to a potential rug-pull. These suspicions are compounded by the absence of a prior security audit, a standard practice that was surprisingly overlooked. Given the associations with reputable names like Uniswap, Binance, Metamask, and Andreessen Horowitz, the lack of initial auditing raises questions about the legitimacy of the operation and whether these partnerships were superficially used to gain trust.

In response to the attack, the team’s decision to conduct a post-incident audit, although a step in the right direction, comes too late for those affected by the exploit. The timeline for this audit, set at 7–10 business days, reflects urgency but also highlights the absence of proactive security measures. This incident serves as a stark reminder of the need for thorough vetting and continuous security assessments of smart contracts to avoid such vulnerabilities and maintain trust within the trading community. The ultimate determination of whether this was a high-level scam designed to lure traders and liquidity providers will depend on the outcomes of the ongoing investigations and audits.

This article was originally published by Pukar Acharya for Neptune Mutual.