The Vulnerability: == Balance Check

A common approach in Solidity is to check if the balance of tokens held by a contract matches an expected value after certain operations, such as transferring or minting tokens. This might look like the following code:

require(balance == IERC20(token).balanceOf(address(this)), "Unexpected balance");

This logic appears straightforward: after a token transfer or minting process, the contract checks if the balance equals the expected value. If the balance doesn't match, the transaction is reverted, ensuring the expected state.

However, this exact balance comparison (==) introduces a vulnerability: any external party can send tokens to the contract, modifying its balance without triggering any internal function. Once the contract balance has been altered in this way, the comparison will fail, causing the contract to become unusable because the condition balance == IERC20(token).balanceOf(address(this)) will never hold true.

---

How the Attack Works

Let’s explore how this vulnerability can be exploited.

Attack Steps:

1. Token Transfer: A malicious actor can send any non-zero amount of tokens to the contract’s address directly. Since this token transfer is done externally, the contract has no control over it.

2. Balance Check Fails: The contract, when executing a function that involves checking the balance, expects the balance to match a predefined value after some operation. However, due to the external transfer, the balance will no longer match the expected value.

3. DoS Attack: The require() statement will continuously fail, rendering the contract's critical functions unusable for all users. Any transaction relying on the exact balance comparison will be blocked, effectively causing a Denial of Service (DoS).

Example Scenario:

Consider a contract designed to handle staking tokens. After a user stakes tokens, the contract checks if its internal balance matches the total staked tokens:

uint256 initialBalance = IERC20(token).balanceOf(address(this));
// Perform staking logic
uint256 finalBalance = IERC20(token).balanceOf(address(this));

require(finalBalance == initialBalance + amount, "Staking failed: unexpected balance");

An attacker could send tokens directly to the contract's address before or during the staking process. As a result, the balance comparison will fail because finalBalance will now include the attacker’s tokens, not just the tokens involved in the staking operation.

---

Impact of the Vulnerability

When a contract uses exact balance checks, the following issues can occur:

1. Denial of Service (DoS): A malicious actor can disrupt the normal operation of the contract by causing balance checks to fail. This could lock users out from critical functions such as staking, minting, or withdrawing tokens.

2. Loss of Functionality: Legitimate users may be unable to interact with the contract, preventing them from participating in key operations like claiming rewards, transferring tokens, or executing transactions.

3. Security Concerns: If the balance check is used as a form of security validation, attackers could bypass these checks by artificially modifying the contract's token balance, undermining the integrity of the system.

---

Mitigation Strategies

To protect contracts from this vulnerability, developers should avoid using exact balance comparisons.