Audit Anomalies Archive — Issue#6
Smart contract developers sometimes make excessive assumptions when writing a contract. One specific instance I’d like to highlight involves declaring an address as immutable or missing a function to update the address. The address could serve various purposes, such as calling specific functions, collecting fees, or changing crucial parameters in the code.
Before diving into the actual issue, it’s important to note that tokens like USDT and USDC have functions that allow them to blacklist an address. The consequence of this action is that a blacklisted user can no longer transfer the tokens, effectively rendering them stuck forever.
Now, let’s return to the problem at hand. Imagine an address responsible for fee collection within a contract, by provide a service such as escrow or trade. If, for any reason, this address gets blacklisted, the entire protocol comes to a halt, resulting in a denial-of-service (DoS) scenario. The code snippet below illustrates this example.
function performTrade() public {
require(balances[msg.sender] > 0, "Balance > 0");
uint256 fee_to_pay = balances[msg.sender] * FEE;
//Imagine "platformTreasury" is BlackListed
IERC20(usdtToken).transferFrom(msg.sender, platformTreasury, fee_to_pay);
//rest of the code
}A similar issue related to the one mentioned above is the compromise of a private key. Envision a situation where the address responsible for fee collection becomes compromised. In this scenario, a hacker could deploy a bot to transfer the collected trading fees to an address they control.
Here’s a valuable tip for both developers and auditors: thoroughly analyze the risks associated with using tokens that possess blacklisting capabilities or the potential compromise of keys within a protocol.
For a practical demonstration of this issue via Foundry, you can find more details in this link.
