9 smart contract vulnerabilities and how to mitigate them

Smart contracts execute processes, transactions, and other tasks when specific events, conditions, and logic are met, depending on how they are programmed. Smart contracts are deployed on a blockchain, such as Ethereum or other distributed ledger infrastructure, where they listen for events and updates from cryptographically secure data feeds called oracles. These contracts often control the flow of large amounts of valuable data and resources, such as the transfer of money, the delivery of services and the unlocking of protected content. This naturally makes them an attractive target for malicious actors.

Security should be a top priority when designing and developing a smart contract. Once a smart contract is deployed to a blockchain, it is difficult or impossible to patch; it must be removed, recreated and redeployed. Plus, vulnerabilities in a smart contract will be accessible to anyone once the smart contract is on a blockchain.

When deploying a smart contract written in Solidity on the popular smart contract platform Ethereum, development teams should be especially aware of the following attack vectors and how to eliminate them.

1. Re-entry attacks

Reentrancy attack vectors exist because Solidity smart contracts execute imperatively: Each line of code must be executed before the next one starts. This means that when a contract makes an external call to another contract, execution of the calling contract is suspended until the call returns. This effectively gives the invoked contract temporary control over what happens next, creating the possibility of an infinite loop.

For example, a malicious contract can make a recursive call back to the original contract to extract resources without waiting for the first call to complete, so the original contract is never allowed to update its balance before the function completes is not. Several forms of reentry attacks exist, including single-function, cross-function, cross-contract, and read-only reentry attacks. A list of exploits is maintained on GitHub.

Solution: This vulnerability occurs when the code logic of a smart contract is flawed. Developers should carefully design external calls and always check and update the contract’s state, such as reducing the Ether balance, before honoring requests to send funds. Adding a re-entry guard can prevent more than one function from executing at a time by closing the contract. Various auditing tools, such as Slither, Mythril and Securify, can check for the presence of the various types of re-entry vulnerabilities.

2. Oracle manipulation

Smart contracts access external data from outside the blockchain and consume it via an oracle. This allows them to interact with off-chain systems, such as stock markets. Incorrect or manipulated oracle data can erroneously trigger the execution of smart contracts; this is known as the oracle issue. Many decentralized finance applications have been exploited using this method, the favorite being a flash loan attack. Flash loans are essentially unsecured loans with no limit on how much can be borrowed as long as the loan is repaid in the same transaction. Attacks use these loans to distort asset prices to generate profits while still adhering to a blockchain’s rules.

Solution: Using a decentralized oracle, such as Chainlink or Tellor, or even multiple oracles, is the easiest way to ensure that a contract receives accurate data. Such oracles make it more difficult and expensive for an attacker to tamper with the data.

3. Gas raw

To execute a transaction or execute a smart contract on the Ethereum blockchain platform, users must pay a gas fee. It is paid to incentivize validators (miners) to commit the resources needed to verify transactions. The price of gas is determined by supply, demand and network capacity at the time of the transaction.

Gas grievance occurs when a user sends the amount of gas needed to execute the target smart contract, but not enough to execute subcalls—calls he makes to other contracts. If the contract does not check whether the required guest to perform a subcall is available, the subcall will not be performed as expected. This can have a significant effect on the application’s logic.

Correction: There is no effective technique for preventing gas. All a developer can do is code the contract so that it determines the amount of gas to be sent, not the user. However, a rise in gas costs could mean the deal fails.

4. Transaction Order Dependency Attacks (advance)

Smart contracts are publicly visible from the moment they are submitted to the network as a pending transaction. This allows a miner of a block to choose the transaction with the highest gas fees. For example, users can include a priority fee – a tip – to incentivize miners to prioritize their transaction over other transactions in the same block. However, this also allows attackers to look for opportunities where they can submit profitable contracts by submitting an identical contract, but with a higher gas fee, so that their contract is processed first. Because these attacks must be implemented in fractions of a second, they are usually carried out by bots or miners themselves.

Solution: Avoiding these attacks is difficult. One option is to only accept transactions with a gas price below a predetermined threshold. Or use a commit-and-publish scheme that involves a user first submitting a solution hash instead of the clear text solution so that the solution cannot be viewed by potential forerunners until it is too late. Several smart contract audit tools can detect or introduce code precursor vulnerabilities.

5. Force-feeding attacks

Force-feeding attacks take advantage of the fact that developers cannot prevent a smart contract from receiving Ether, Ethereum’s native cryptocurrency. This makes it easy to transfer Ether to any contract – force them – to change the balance of Ether it holds and thereby manipulate any function logic that relies solely on the expected balance for internal accounting, such as paying out a reward if a balance rises above a certain level.

Fix: It is impossible to stop contract balance manipulation this way. A contract’s balance should never be used as a check or wait inside a function because the actual Ether balance may be higher than the balance expected by the contract’s internal code.

6. Timestamp dependency

Timestamp values ​​are generated by the node executing the smart contract. Due to the distributed nature of the Ethereum platform, it is almost impossible to guarantee that the time on every node is correctly synchronized. A node can then manipulate the timestamp value which it uses to create a logical attack against any contract that relies on the block.timestamp variable to perform time-critical operations.

Fix: To avoid this vulnerability, developers should not use the block.timestamp function as a check or logic check, or as a source of randomness.

7. Denial of service

Like any online service, smart contracts are vulnerable to DoS attacks. By overloading services, such as authentication, an attacker can block other contracts from executing or generate unexpected contract rollbacks, for example where unused gas is returned and all state is returned to the state before the transaction started executing. This can lead to auction results or values ​​used in financial transactions being manipulated to the attacker’s advantage.

Solution: Making these attacks expensive for attackers is the best way to deter them. Timelock puzzles and gas fees are just a few of the ways to increase an attacker’s costs. Ensuring that calls are only made to trusted contracts also reduces the likelihood of a DoS attack causing serious problems.

8. Integer underflow and overflow

Integer underflow and overflow occur when the result of an arithmetic operation falls outside the fixed-size range of values: 0 to 255 in the case of integer type uint8. Values ​​higher than 255 overflow and are reset to 0, while values ​​lower than 0 are reset to 255. This causes unexpected changes to a contract’s state variables and logic and causes invalid operations.

Fix: Since version 0.8.0, the Solidity compiler no longer allows code that can lead to integer underflow and overflow. Check any contracts compiled with earlier versions for functions that involve arithmetic operations or use a library, such as SafeMath, to check for underflow and overflow issues.

9. Information and function exposure

Blockchains are accessible to anyone. Confidential or sensitive information should never be stored on a blockchain unless it is encrypted. Variables and functions within a smart contract may also be visible and accessible to other smart contracts, leaving them open to possible misuse or abuse.

Solution: Developers should always implement proper access controls and use the principle of least privilege by using Solidity’s variable and function visibility modifiers to grant the minimum level of visibility as needed and no more.

Keep smart contracts vulnerability free

For smart contracts to be smart and secure, development teams must build in security from the start and rigorously test their logic and code execution.

Contract code is difficult to patch after it is deployed. Getting security right the first time is essential. Always follow best practices for smart contract security. Unless the development team includes dedicated smart contract security specialists who can audit smart contract code for logic errors and other vulnerabilities by testing each function, use an auditing service that specializes in smart contracts to identify any security issues.