Smart Contract Vulnerabilities: Types & How to Prevent Them

• By Paramjit Singh

• 12th June 2024

Smart contracts have transformed the way transactions occur across the web. These are self-implementing agreements among stakeholders without the interference of intermediaries on Web 3.0. It is important to note that smart contracts are built and run on top of blockchain.

Most commonly, users deploy smart contracts on Ethereum. A smart contract consists of a set of conditions and once these conditions are met, it launches automatically. Sounds easy and safe, right? Even though the smart contract is executed in the correct way, hackers have found their way into this ‘immutable’ blockchain system!

Why does this happen? 

This is because there are many vulnerabilities or weaknesses in a smart contract that need to be identified. Therefore, smart contract auditing is the answer to recognizing the smart contract vulnerabilities and eliminating them.

You can refer to this guide to understand in-depth about the top smart contract vulnerabilities and what you can do to avoid them.

What is Smart Contract Auditing?

Smart contract auditing is the process of performing a thorough and comprehensive analysis of a smart contract in an application. The objective of smart contract auditing is to look for vulnerabilities and act on them robustly. 

According to a CertiK report of 2023, the Web3 landscape lost a total of $1.84 billion across 751 security incidents. With such a huge number lost in the market, there is a grave need for performing security audits in smart contracts. 

There are numerous tests that a smart contract auditor performs to identify these smart contract vulnerabilities. We’ll discuss more about these tests in the later part of this blog.

Watch Out for These Smart Contract Vulnerabilities 

Here’s a list of top smart contract vulnerabilities that you need to watch out for in a target smart contract.

1. Reentrancy

When talking about Ethereum vulnerabilities, reentrancy is one of the most common types of smart contract vulnerabilities. This is a kind of vulnerability where an attacker tries to push in a malicious smart contract before a transaction is made. The reentrancy smart contract vulnerability can cause heavy financial loss as the attacker can get the ‘malicious’ smart contract implemented.

The reentrancy attack is one of the most common malicious attacks found in smart contract implementation. 

The following are the main types of reentrancy attacks:

• External Call

In this type of reentrancy attack, an attacker looks for the availability of an external call through a malicious contract.  The external call befools the callee to execute the arbitrary code. Therefore, you must be aware if there is any external call getting executed in your smart contract.

• Single Function Reentrancy

When an attacker is trying to call the exact vulnerable function again and again, it is called single function reentrancy. The scariest part about this attack is that the balance is only modified after the funds are transferred.

• Cross-Function Reentrancy

This kind of reentrancy test is a complex version of the attack. It occurs when a vulnerable function shares its state with a function that can be potentially exploited by an attacker.

• Read-Only Reentrancy

This is a new type of reentrancy test in which the attacker cannot directly enter and exploit a smart contract. Instead, he enters into another smart contract which then reads the state of the original smart contract. This reentrancy attack is quite hideous in nature as it doesn’t attack directly on the target smart contract.

How to Prevent Reentrancy Attacks?

• For Other Reentrancy Attacks

One of the simplest ways to prevent reentrancy attacks, other than read-only reentrancy attacks, is to use ReentrancyGuard. It allows you to add a modifier to the functions that are vulnerable in nature. For example, you can use the nonReentrant modifier to stave off single-function and cross-function reentrancy attacks.

• For Ready-Only Reentrancy Attacks

To avoid read-only reentrancy attacks, you can leverage the checks-effects-interactions pattern for the highest level of security. The trick is to make the state changes prior to an attacker enters the smart contract. 

The checks-effects-interactions pattern follows the below-mentioned sequence to order smart contract functions:

1. Begin the function with checks, such as assert or require statements.
2. Perform the state of the smart contract, that is, you need to make state modifications.
3. Lastly, you need to perform interactions with other smart contracts. External function calls are a great example.

The implementation looks as follows:

function withdraw() external {

  uint256 amount = balances[msg.sender];

  balances[msg.sender] = 0;

  (bool success,) = msg.sender.call{value: balances[msg.sender]}(“”);

  require(success);

}

Here, the balance is set to 0 and nothing can be transferred after the first interaction.

2. Gas Grieving

Gas grieving is another significant and commonly found smart contract vulnerability, especially on the Ethereum platform. Let’s understand what it means. Whenever a user has to make a transaction or execute a smart contract, a certain fee must be paid. This fee is called a gas fee. The price of this gas fee is decided based on the demand, supply and network capacity during a transaction.

Sometimes, the gas fee is enough to implement the smart contract but not enough to make calls to other smart contracts, which are called sub-calls. When these sub-calls fail to happen, either the execution is continued or the transaction fails. 

This is when gas grieving, a significant smart contract vulnerability occurs. For example, a relayer contract allows a user to make and sign a transaction. This usually happens when users are not able to pay for the gas.

How to Prevent Gas Grieving?

Although there is no definite way to prevent gas grieving smart contract vulnerabilities, you can do the following:

• You can code the smart contract or get it coded by a blockchain developer and set the amount of gas fee to be sent. This way, the user doesn’t have to send the gas fee dedicatedly.
• Only the trusted users should be allowed to relay the transactions. 
• Another way to prevent gas grieving is to provide enough gas. It can be done with the following code:

// contract called by Relayer

contract Executor {

    function execute(bytes _data, uint _gasLimit) {

        require(gasleft() >= _gasLimit);

        …

    }

}

Source: GitHub

3. Integer Overflows and Underflows

Integer overflows and underflows occur in a smart contract when the result of an arithmetic operation exceeds or remains below the fixed-size ranges. Older smart contracts leveraged the SafeMath library to prevent exceeding or ‘less than’ values. However, in the Solidity blockchain platform, there is a built-in SafeMath logic that prevents integer overflowing and underflowing.

We’ll take the case of Solidity, where integer types have the following maximum values.

• Unit8 => 255
• Unit16 => 65535 
• Unit24 => 16777215
• Unit256 =>  (2^256) – 1

So, when do the overflows and underflows occur? When the value goes beyond the maximum value, integer overflow happens. This is when the value is taken back to zero. 

On the contrary, when the value is even below the minimum value limit, integer underflow happens. This is when the value goes up to the maximum value limit.

Overflow bugs especially occur with small integer types such as unit8, unit16, etc. as these integer types have smaller maximum values that get overflowed easily. Therefore, these values should be used with utmost care.

How to Prevent Integer Overflows and Underflows?

Here are the two approaches you can use to prevent integer overflows and underflows:

• You can use the SafeMath library if you’re working on older smart contracts.
• The 0.8.0 version of Solidity does not allow any occurrence of integer overflows and underflows as it comes with a built-in SafeMath logic.

Note: You can avoid the SafeMath logic by using unchecked blocks.

4. Unencrypted Private Data

Blockchain is an immutable technology however, it is completely transparent in nature. All the information stored on the blockchain is readable, accessible and visible to everyone on the network. Therefore, it is not advisable to add confidential or sensitive information on the blockchain network.

Smart contracts built on top of blockchain often contain sensitive functions and variables. To give you an idea, the smart contract code, storage and data can always be read by anyone. Malicious attackers can decompile the code and gain sensitive transaction information. 

How to Prevent Private Data Leaks?

You can follow the below-mentioned tips to prevent data leaks:

• Smart contract developers must implement specific access controls.
• You can also use the principle of least privilege by leveraging Solidity’s variable and function visibility modifiers. This allows you to offer minimum-level visibility to the smart contract.

5. Denial of Service (DoS) Attack

There are many reasons for a Denial of Service attack, one of which is when logic cannot be executed. This often occurs as a result of unexpected revert. Some of the prominent reasons for the logic to get reverted are as follows:

• Integer Overflow/Underflow

If you’re using anything below Solidity 0.8.0 where the SafeMatch library is missing, there are many chances of creating integer overflows and underflows while performing arithmetic operations. These overflows and underflows can cause a revert that can gradually lead to a Denial of Service (DoS).

However, it doesn’t mean that the usage of checked math will always lead to DoS attacks. You just need to take care while working with small integers such as int8/uint8, int16/uint16, int24/uint24, etc.

• Reverting Funds Transfer

Sometimes, when you try to send funds to a user with functions, Denial of Service (DoS) attacks can occur. The attacks occur in these functions when the functionality depends on the successful transfer of the funds.

An attacker can act to send funds to a smart contract and then simply create a fallback function that reverts the complete payment. This way, the attacker can revert all the payments and those payments can never be refunded.

Note: You can prevent the reverted payments by using a pull function rather than a push function. This way, the recipient can call the function for payment.

• Unexpected Balances 

Sometimes, an attacker deliberately increases your account funds to cause an unexpected revert. He can either do so by simply transferring ERC20 tokens into the contract or by forcibly sending Ether to a contract.

For example, an attacker may forcibly send Ether to a contract even before the first deposit which can cause all the deposits to revert.

How to Prevent Denial of Service (DoS) Attacks?

The following are the best ways to prevent Denial of Service (DoS) attacks:

• You must never call external smart contracts that cannot be fully trusted. On the flip side, you should also stay away from granting access to untrusted accounts.
• It is advisable to use multi-signature wallets that use multiple private keys to access or transfer cryptocurrency assets.
• You can set a gas limit to prevent the exhaustion of gas units through malicious recursive calls.

Bottom Line

With the emerging use of blockchain technology, smart contracts are emerging as a significant entity to enable transactions. However, hackers have still made their way to detect poignant smart contract vulnerabilities to parse their way into the technology. This is the reason why it is important to adopt smart contract vulnerability detection techniques to identify bugs in smart contracts and act on them robustly.

Are you an enterprise or business organization looking for smart contract testing services? Deftsoft is here to help cross-check your smart contract against all the above-mentioned smart contract vulnerabilities. Contact us now!

FAQs: