Smart contracts have revolutionised blockchain technology, enabling decentralised applications (dApps), decentralised finance (DeFi), and a range of trustless transactions. Operating autonomously on blockchain networks like Ethereum, smart contracts eliminate intermediaries and offer transparency, immutability, and automation. However, their functionality carries inherent risks: a small coding mistake or vulnerability in a smart contract can lead to catastrophic financial losses or manipulation. In this article, we delve into the various types of attacks that smart contracts are vulnerable to, exploring the mechanics behind these attacks, real-world examples, and prevention strategies.
Different Types of Attacks in Smart Contracts
1. Re-entrancy Attack
One of the most notorious vulnerabilities in smart contracts, re-entrancy attacks occur when a contract allows external calls to other contracts before updating its own state. This delay in state changes can be exploited by an attacker, who repeatedly calls the contract’s function, manipulating the contract’s logic to withdraw funds or resources multiple times before the contract is aware of the state changes.
Example
Imagine a simple smart contract written in Solidity as shown below:
Before the contract updates the balance, the call to msg.sender occurs. If msg.sender is a malicious contract, it can re-enter the vulnerable contract and call withdraw recursively before the balance is reduced, ultimately draining all the Ether stored in the vulnerable smart contract.
Prevention
To prevent re-entrancy attacks, developers can adopt several strategies:
2. Arbitrary External Calls
Some smart contracts allow users to pass arbitrary data or addresses for function execution. If not carefully controlled, this can enable attackers to execute malicious external calls, leading to unexpected behavior. Attackers can exploit this vulnerability to trick the contract into interacting with malicious contracts or siphoning funds.
Example
In July 2024, Decentralized finance (DeFi) platform LI.FI protocol was exploited, resulting in the theft of roughly $11 million worth of crypto assets. The root cause of the attack was insufficient user input validation, which allowed arbitrary external calls.
Let’s take a look at the LI.FI’s vulnerable smart contract which was exploited:
Source: https://x.com/DecurityHQ/status/1813195945477087718/photo/1
The above depositToGasZipERC20 function from LI.FI protocol lacks user input validation on LibSwap.SwapData calldata _swapData parameter. An attacker could supply arbitrary _swapData parameter, which is later used in the _swap.callTo and _swap.callData parameters in the LibSwap.swap sub call function.
This flaw led to unauthorised calls to arbitrary contracts, affecting around 156 wallets that granted infinite token allowance approvals to this vulnerable contract.
A proof-of-concept exploit script for this attack has been reproduced by DeFiHackLabs:
https://github.com/SunWeb3Sec/DeFiHackLabs/blob/main/src/test/2024-07/Lifiprotocol_exp.sol
Prevention
3. Oracle Price Manipulation
Oracle manipulation occurs when an attacker exploits or manipulates the external data source (oracle) that a smart contract relies on for making critical decisions. Since smart contracts operate in isolated environments and cannot fetch data externally, they rely on oracles to provide external data, such as asset prices and interest rates.
If an oracle feeds inaccurate or malicious data to a smart contract, it can lead to incorrect or unintended outcomes, resulting in financial loss, unintended logic execution, or system exploitation. These attacks are particularly common in decentralised finance (DeFi) protocols, where the value of tokens, loans, or collateral depends on real-world data provided by oracles.
Example
On a decentralised lending platform, an attacker can take out a flash loan to manipulate the price of a low-liquidity asset, like ETH, on a decentralised exchange (DEX). By driving up the asset's price on the DEX, the attacker inflates the price reported by the platform's oracle. The attacker then uses this falsely inflated price to borrow more funds than they should be allowed based on the real collateral value. Once the loan is taken, the attacker repays the flash loan and keeps the profit difference, leaving the platform under-collateralised and at a loss.
Prevention
4. Lack of Access Control
Smart contracts often contain administrative functions that allow developers or designated individuals to change key parameters. If access control is improperly implemented, attackers can gain unauthorised control over these functions, leading to significant damage such as minting extra tokens or modifying contract logic.
Example
In October 2022, the TempleDAO hack occurred when attackers exploited a vulnerability in the staking contract. The issue stemmed from insufficient access controls, allowing the hacker to withdraw funds from the vulnerable staking contract. The breach resulted in a loss of approximately $2.3 million in crypto assets.
The issue originated from the migrateStake function as follows:
Source: https://etherscan.io/address/0xd2869042e12a3506100af1d192b5b04d65137941#code#F1#L241
The function lacked proper access control, allowing arbitrary addresses to call the function, not just the intended migrator contract. Additionally, there was no validation on the oldStaking parameter. By exploiting both vulnerabilities, the attacker was able to create a malicious contract, pass it as the oldStaking parameter, and specify an arbitrary amount, enabling them to withdraw assets from the vault and have the tokens minted to their address.
Prevention
5. Loss of Precision
Smart contracts often deal with fractional values, particularly in financial applications like decentralised exchanges or lending protocols. Due to limitations in the precision of floating-point arithmetic or integer division in Solidity, loss of precision can occur, leading to incorrect calculations. Attackers can exploit this by manipulating the rounding or precision errors to their advantage.
Example
Common scenarios of precision loss include token swaps or trades. For instance, a user swaps Token A for Token B, where the price of 1 Token A is 1.5 Token B. If the smart contract calculates the exchange rate using integer division, it might round the value down to 1 Token B, resulting in the user receiving less tokens than expected.
Additionally, precision loss can occur in payment-splitting systems. When splitting payments among multiple parties, the contract may not be able to divide a specific amount evenly, resulting in a discrepancy where one party may receive less than they are entitled to. For example, suppose a contract splits 100 tokens among 3 people. In Solidity, the result of (100 / 3) would be 33 tokens for each person, leaving 1 token unaccounted for, which may remain locked in the contract.
Prevention
6. Business Logic Flaw
Business logic flaws occur when a contract’s core rules or assumptions contain an error, leading to unexpected or unintended behavior. Unlike technical vulnerabilities, these flaws stem from incorrect assumptions made by the developer about how the contract should function. Attackers can exploit these logic flaws to bypass security mechanisms or manipulate the system.
Example
On 26 September 2024, the liquid staking protocol Bedrock DeFi was exploited, resulting in a loss of approximately $1.7 million. The exploit occurred due to a business logic flaw in the following function:
Source: https://x.com/CertiKAlert/status/1839403126694326374/photo/1
The function above was intended to allow users to mint uniBTC crypto assets with native BTC tokens at a 1:1 exchange rate. However, it incorrectly used msg.value in the internal _mint function. msg.value represents the amount of Ether (ETH) sent during a transaction, not BTC. As a result, users could swap 1 ETH (~2,600 USD during the exploit) for 1 uniBTC (~62,000 USD during the exploit), yielding a profit of roughly 59,400 USD in a single transaction.
Prevention
7. Frontrunning Attacks
Front-running occurs when an attacker observes a pending transaction and submits their own transaction with a higher gas fee to get processed first. This type of attack is possible on public blockchains, where transactions are visible before being mined.
Example
Malicious actors frequently monitor the mempool (a temporary holding area where pending transactions wait to be added to the blockchain), searching for transactions that could yield a profit. For instance, if they detect a large buy order, they can submit their own buy order ahead of it by offering a higher gas fee (transaction cost). This tactic pushes up the asset's price, enabling the front-runner to quickly sell their holdings after the original large order is executed, making a profit from the price increase.
Prevention
By staying ahead of these risks, developers can help ensure the safe and secure operation of their decentralised applications and smart contracts.
References
1. Proof of Concept Exploit Scripts for Past DeFi Hacking Incidents: https://github.com/SunWeb3Sec/DeFiHackLabs
2. Latest news on DeFi Exploits: https://rekt.news/
3. Defi Protocol LI.FI Struck by $11M Exploit: https://www.coindesk.com/business/2024/07/16/defi-protocol-lifi-struck-by-8m-exploit/
4. Temple DAO Hack Analysis: https://blog.solidityscan.com/temple-dao-hack-analysis-c96db856322c
5. Li.Fi bridge exploited for ~8M USD: https://x.com/DecurityHQ/status/1813195945477087718/photo/1
6. Bedrock_DeFi exploited for ~$1.7M: https://x.com/CertiKAlert/status/1839403126694326374/photo/1
Different Types of Attacks in Smart Contracts
1. Re-entrancy Attack
One of the most notorious vulnerabilities in smart contracts, re-entrancy attacks occur when a contract allows external calls to other contracts before updating its own state. This delay in state changes can be exploited by an attacker, who repeatedly calls the contract’s function, manipulating the contract’s logic to withdraw funds or resources multiple times before the contract is aware of the state changes.
Example
Imagine a simple smart contract written in Solidity as shown below:
Before the contract updates the balance, the call to msg.sender occurs. If msg.sender is a malicious contract, it can re-enter the vulnerable contract and call withdraw recursively before the balance is reduced, ultimately draining all the Ether stored in the vulnerable smart contract.
Prevention
To prevent re-entrancy attacks, developers can adopt several strategies:
- Checks-Effects-Interactions Pattern: In this pattern, internal state changes (checks and effects) occur before any external calls. For example, the balance should be updated before calling an external contract.
- Re-entrancy Guards: Libraries like OpenZeppelin's Re-entrancyGuard provides nonReentrant modifiers to prevent reentrancy attacks by blocking recursive calls within the same function.
2. Arbitrary External Calls
Some smart contracts allow users to pass arbitrary data or addresses for function execution. If not carefully controlled, this can enable attackers to execute malicious external calls, leading to unexpected behavior. Attackers can exploit this vulnerability to trick the contract into interacting with malicious contracts or siphoning funds.
Example
In July 2024, Decentralized finance (DeFi) platform LI.FI protocol was exploited, resulting in the theft of roughly $11 million worth of crypto assets. The root cause of the attack was insufficient user input validation, which allowed arbitrary external calls.
Let’s take a look at the LI.FI’s vulnerable smart contract which was exploited:
Source: https://x.com/DecurityHQ/status/1813195945477087718/photo/1The above depositToGasZipERC20 function from LI.FI protocol lacks user input validation on LibSwap.SwapData calldata _swapData parameter. An attacker could supply arbitrary _swapData parameter, which is later used in the _swap.callTo and _swap.callData parameters in the LibSwap.swap sub call function.
This flaw led to unauthorised calls to arbitrary contracts, affecting around 156 wallets that granted infinite token allowance approvals to this vulnerable contract.
A proof-of-concept exploit script for this attack has been reproduced by DeFiHackLabs:
https://github.com/SunWeb3Sec/DeFiHackLabs/blob/main/src/test/2024-07/Lifiprotocol_exp.sol
Prevention
- Restrict external calls: Limit external calls only to trusted addresses.
- Validate inputs rigorously: Ensure user-provided data is thoroughly validated before using it in any external call.
3. Oracle Price Manipulation
Oracle manipulation occurs when an attacker exploits or manipulates the external data source (oracle) that a smart contract relies on for making critical decisions. Since smart contracts operate in isolated environments and cannot fetch data externally, they rely on oracles to provide external data, such as asset prices and interest rates.
If an oracle feeds inaccurate or malicious data to a smart contract, it can lead to incorrect or unintended outcomes, resulting in financial loss, unintended logic execution, or system exploitation. These attacks are particularly common in decentralised finance (DeFi) protocols, where the value of tokens, loans, or collateral depends on real-world data provided by oracles.
Example
On a decentralised lending platform, an attacker can take out a flash loan to manipulate the price of a low-liquidity asset, like ETH, on a decentralised exchange (DEX). By driving up the asset's price on the DEX, the attacker inflates the price reported by the platform's oracle. The attacker then uses this falsely inflated price to borrow more funds than they should be allowed based on the real collateral value. Once the loan is taken, the attacker repays the flash loan and keeps the profit difference, leaving the platform under-collateralised and at a loss.
Prevention
- Use decentralised oracles: Rely on decentralised oracle networks (such as Chainlink) that aggregate data from multiple sources to reduce the risk of single-point oracle manipulation.
- Price Averaging and Time-Weighted Prices: Instead of using the latest price directly, use time-weighted average prices (TWAP) or volume-weighted average prices (VWAP) over a certain period. This approach makes it more difficult for an attacker to manipulate the price at a single point in time.
4. Lack of Access Control
Smart contracts often contain administrative functions that allow developers or designated individuals to change key parameters. If access control is improperly implemented, attackers can gain unauthorised control over these functions, leading to significant damage such as minting extra tokens or modifying contract logic.
Example
In October 2022, the TempleDAO hack occurred when attackers exploited a vulnerability in the staking contract. The issue stemmed from insufficient access controls, allowing the hacker to withdraw funds from the vulnerable staking contract. The breach resulted in a loss of approximately $2.3 million in crypto assets.
The issue originated from the migrateStake function as follows:
Source: https://etherscan.io/address/0xd2869042e12a3506100af1d192b5b04d65137941#code#F1#L241The function lacked proper access control, allowing arbitrary addresses to call the function, not just the intended migrator contract. Additionally, there was no validation on the oldStaking parameter. By exploiting both vulnerabilities, the attacker was able to create a malicious contract, pass it as the oldStaking parameter, and specify an arbitrary amount, enabling them to withdraw assets from the vault and have the tokens minted to their address.
Prevention
- Use proper access control libraries: Ensure functions that require restricted access are secured using libraries like OpenZeppelin’s Ownable or AccessControl.
- Audit administrative functions regularly: Smart contracts should undergo continuous security audits, with special attention to any privileged functions.
5. Loss of Precision
Smart contracts often deal with fractional values, particularly in financial applications like decentralised exchanges or lending protocols. Due to limitations in the precision of floating-point arithmetic or integer division in Solidity, loss of precision can occur, leading to incorrect calculations. Attackers can exploit this by manipulating the rounding or precision errors to their advantage.
Example
Common scenarios of precision loss include token swaps or trades. For instance, a user swaps Token A for Token B, where the price of 1 Token A is 1.5 Token B. If the smart contract calculates the exchange rate using integer division, it might round the value down to 1 Token B, resulting in the user receiving less tokens than expected.
Additionally, precision loss can occur in payment-splitting systems. When splitting payments among multiple parties, the contract may not be able to divide a specific amount evenly, resulting in a discrepancy where one party may receive less than they are entitled to. For example, suppose a contract splits 100 tokens among 3 people. In Solidity, the result of (100 / 3) would be 33 tokens for each person, leaving 1 token unaccounted for, which may remain locked in the contract.
Prevention
- Use fixed-point arithmetic: Consider libraries that help handle precision and rounding in financial operations.
- Round conservatively: Always round in favour of the contract or the protocol, ensuring that precision loss benefits the system rather than individual users.
6. Business Logic Flaw
Business logic flaws occur when a contract’s core rules or assumptions contain an error, leading to unexpected or unintended behavior. Unlike technical vulnerabilities, these flaws stem from incorrect assumptions made by the developer about how the contract should function. Attackers can exploit these logic flaws to bypass security mechanisms or manipulate the system.
Example
On 26 September 2024, the liquid staking protocol Bedrock DeFi was exploited, resulting in a loss of approximately $1.7 million. The exploit occurred due to a business logic flaw in the following function:
Source: https://x.com/CertiKAlert/status/1839403126694326374/photo/1The function above was intended to allow users to mint uniBTC crypto assets with native BTC tokens at a 1:1 exchange rate. However, it incorrectly used msg.value in the internal _mint function. msg.value represents the amount of Ether (ETH) sent during a transaction, not BTC. As a result, users could swap 1 ETH (~2,600 USD during the exploit) for 1 uniBTC (~62,000 USD during the exploit), yielding a profit of roughly 59,400 USD in a single transaction.
Prevention
- Design and Workflow Documentation: Maintain detailed design documents and data flow diagrams for all transactions and workflows, clearly noting any assumptions made at each stage.
- Clear Coding Style: Write code as clearly as possible. If intended functionality is unclear, logic errors are harder to identify. Ideally, code should be self-explanatory, though, in cases of unavoidable complexity, clear documentation is crucial to help developers and testers understand assumptions and expected behavior.
7. Frontrunning Attacks
Front-running occurs when an attacker observes a pending transaction and submits their own transaction with a higher gas fee to get processed first. This type of attack is possible on public blockchains, where transactions are visible before being mined.
Example
Malicious actors frequently monitor the mempool (a temporary holding area where pending transactions wait to be added to the blockchain), searching for transactions that could yield a profit. For instance, if they detect a large buy order, they can submit their own buy order ahead of it by offering a higher gas fee (transaction cost). This tactic pushes up the asset's price, enabling the front-runner to quickly sell their holdings after the original large order is executed, making a profit from the price increase.
Prevention
- Use private transaction techniques: Some protocols allow for private transactions or batch processing to reduce the risk of front-running.
- Slippage Control: Decentralised Exchanges (DEXs) can implement slippage control in their smart contracts, allowing users to set maximum slippage tolerance when swapping or exchanging crypto assets to prevent front-running attacks.
Conclusion
Smart contract security is a critical concern in blockchain development. Understanding and mitigating potential attack vectors can save developers, users, and entire networks from catastrophic losses. Proper auditing, using secure libraries, and following best practices in smart contract development can drastically reduce vulnerabilities. As the blockchain ecosystem evolves, so do attack types, making continuous vigilance and adaptation essential for long-term security.By staying ahead of these risks, developers can help ensure the safe and secure operation of their decentralised applications and smart contracts.
References
1. Proof of Concept Exploit Scripts for Past DeFi Hacking Incidents: https://github.com/SunWeb3Sec/DeFiHackLabs
2. Latest news on DeFi Exploits: https://rekt.news/
3. Defi Protocol LI.FI Struck by $11M Exploit: https://www.coindesk.com/business/2024/07/16/defi-protocol-lifi-struck-by-8m-exploit/
4. Temple DAO Hack Analysis: https://blog.solidityscan.com/temple-dao-hack-analysis-c96db856322c
5. Li.Fi bridge exploited for ~8M USD: https://x.com/DecurityHQ/status/1813195945477087718/photo/1
6. Bedrock_DeFi exploited for ~$1.7M: https://x.com/CertiKAlert/status/1839403126694326374/photo/1