Case Studies: Notable Smart Contract Security Breaches and Their Lessons

Smart contracts have the potential to transform the way we conduct transactions and automate operations, but they are not immune to smart contract security breaches, security flaws, and attacks. 

This article will discuss case studies of notable smart contract security breaches and the lessons learned from them to help avoid further smart contract security breaches.

In the dynamic world of Web3, smart contracts serve as the foundation for many creative applications. They automate transactions, manage DeFi protocols, and enable non-fungible tokens (NFTs). 

However, with great power, comes great responsibility. Smart contracts’ complexity and immutability render them vulnerable to security breaches and functional mistakes. 

This is where smart contract auditing becomes advantageous and necessary for the success of Web3 applications.

Let us get an understanding of what smart contracts are all about.

What are Smart Contracts?

A smart contract is a self-executing program that automates the acts specified in an agreement or contract. Once completed, the transactions are traceable and irreversible.

Smart contracts enable trustworthy transactions and agreements between disparate, anonymous participants without requiring a central authority, legal system, or external enforcement mechanism.

Blockchain technology is commonly associated with Bitcoin, although it has evolved beyond this.

Use Cases of Smart Contracts

Smart contracts, which implement agreements, can be used for various applications. 

One of the most basic applications is assuring transactions between two parties, such as purchasing and delivering products. 

For example, a producer needing raw materials can use smart contracts to arrange payments, while a supplier can set up shipments. 

Depending on the arrangement between the two businesses, the payments may be automatically sent to the supplier upon shipment or delivery.

Smart contracts can be utilized in various applications, including real estate transactions, stock and commodity trading, loans, corporate governance, supply chain management, dispute resolution, and healthcare.

Moving forward, let us see the notable smart contract security breaches and the lessons gained from them.

Notable Smart Contract Security Breaches

Smart contract security breaches cause heavy negative impacts on organizations. Some notable smart contract security breaches include;

1. Default visibility
2. Reentrancy attacks
3. Arithmetic over/ underflow
4. Race conditions/ front running
5. Entropy illusion
6. Denial-of-service (DOS) Attacks
7. Invalidated inputs and external calls
8. Tx.Origin Authentication

Default Visibility  

Common Weakness Enumeration (CWE) shows that Default Visibility is an example of Improper Adherence to Coding Standards.

Functions in Solidity have visibility specifiers that dictate how they can be called. The visibility determines whether a function can be called externally by users or by other derived contracts, only internally or externally. 

The default visibility for functions is [public]. Therefore, tasks that do not specify any visibility can be callable by external users.

Default Visibility becomes a problem when developers ignore visibility specifiers on functions that should be private (or only callable within the contract itself). 

It is good practice to specify the visibility of all tasks in a contract, even if they are designed to be public.

A noticeable example of the effect of this issue was the Parity MultiSig Wallet hack, when about $31M worth of Ether was stolen from primarily three wallets. 

The wallet smart contracts had two functions that were accidentally left [public], so an attacker could call these functions, changing the ownership to the attacker’s address. 

After becoming the owner, the attacker could drain the wallets of all their ETHs (≈$31M).

Summing up, incorrect use of visibility specifiers can lead to critical vulnerabilities in all smart contracts.

Reentrancy Attack

One of the advantages of Ethereum smart contracts is the ability to call and use code from other external contracts. Many contracts transmit Ether to several external user addresses. 

Calling external contracts or delivering Ether to an address needs the contract to initiate an external call. 

Cybercriminals steal those external calls, forcing the contract to run and call itself (via a fallback function). The execution of the code “re-enters” the contract.

The attacker can deliberately create a contract at an external location with malicious code in the fallback function. Such contracts aim to drain cash by making a recursive call back to the original function. 

When the contract fails to update its status before delivering payments, the attacker can repeatedly execute the withdraw function, draining the contract funds.

From a historical standpoint, the reentrancy attack is one of the most severe assaults on Solidity smart contracts. 

The reentrancy attack resulted in hundreds of millions of dollars in damages over the last few years, including the Ethereum fork in 2016.

Arithmetic Over/ Underflow 

The Ethereum Virtual Machine specifies fixed-size data types for integers. This means that it can only represent a specific range of integers. 

Without taking the required precautions, variables can be used if user input is not validated so that integers may be kept at data types other than those specified.

It commonly occurs during an operation that requires a fixed-size variable to store a piece of data or a number more significant than the variable’s data type range. 

Cybercriminals use smart contract flaws to exploit the code and profit from the process.

Adding numbers exceeding the data type range is called overflow. When the uint (unsigned integer) reaches its maximum value, the next element added will overflow. 

For example, the ultimate value for uint8 is 255; if you add one more, the variable will overflow and equal 0 (if you add two, the variable will be 1).

Race Conditions/ Front Running 

Another one of the smart contract security breaches is called Race conditions or front running. 

The Ethereum blockchain’s design suggests a combination of external calls to other contracts and many users, allowing attackers to identify Solidity vulnerabilities by racing code execution for profit.

Ethereum nodes use blockchain technology to group transactions into blocks, considered valid until a miner solves a consensus mechanism.

Before a transaction is included in a block, it is sent to the mempool, where everyone knows what will happen. 

Such situations might be problematic for decentralized markets since a transaction to purchase specific tokens is detected, and a market order is performed before the other transaction is incorporated. 

Front running is a distinctive element of a contract; hence, it takes a lot of work to avoid. 

However, it is preferable to use batch auctions (which mitigate against high-frequency trading concerns) or a pre-commit approach (“I’ll submit the details later”).

Entropy Illusion 

Every transaction on the Ethereum blockchain has a quantifiable influence on the whole Ethereum ecosystem. It means that randomness and entropy cannot exist within the blockchain ecosystem. 

As a result, Solidity lacks the ‘rand()’ function, and many experts need help to achieve decentralized entropy.

Some programmers attempt to develop their own “random” functions, but due to their lack of familiarity with the ETH ecosystem, they make mistakes, resulting in vulnerabilities.

Denial-of-Service (DOS) Attacks

Denial-of-Service (DoS) is one of the smart contract security breaches. Its attacks attempt to interrupt the availability or performance of a smart contract by exploiting resource constraints or inefficiencies. 

These attacks can cause network congestion, halt execution, or deplete the contract’s gas limit, making it unusable.

To protect against DoS attacks, developers should carefully construct smart contracts, avoiding expensive computations and loops with infinite iterations. 

Furthermore, imposing gas limitations and employing gas-efficient coding techniques can assist in preventing DoS attacks.

Invalidated Inputs and External Calls

Unvalidated inputs and external calls can also pose vulnerabilities to smart contracts. 

If a smart contract fails to check user inputs or manage external calls correctly, it is vulnerable to malicious input manipulation, phishing, and arbitrary code execution.

To protect against these smart contract security breaches, developers should properly evaluate and sanitize user inputs, implement suitable input processing and validation procedures, and exercise caution when communicating with external contracts or data sources.

Tx.Origin Authentication  

This is also one of the notable smart contract security breaches. The Ethereum blockchain features a global variable called tx.origin. 

It completes the calling process and returns the account’s address that sent the transaction. Using the variable for smart contract authentication exposes a severe risk of phishing cyber-attacks.

We rarely encounter this vulnerability. Developers with minimal solidity knowledge cannot distinguish it from the variable msg—-sender, resulting in contracts with vulnerabilities and utilizing it where it is not recommended. 

Therefore, never use tx.origin for authorization.

How To Guard Against Smart Contract Security Breaches 

By adhering to these six pillars, developers may design a comprehensive defense mechanism that strengthens the security of their smart contracts and guards against smart contract security breaches.

• Best practices: Stick to the standards and best practices while building and deploying smart contracts.
• Testing: Write unit tests before deploying smart contracts to ensure the system functions as expected.
• Auditing: Have smart contracts inspected by expert auditors to detect any potential security problems and offer best practices to increase security.
• Code Reviews: Conduct code reviews to spot the issues and, more importantly, respond quickly before the implementation proceeds too far.
• Monitoring: Implement monitoring and alarm systems to detect and respond to any suspicious activity.
• Access controls: Put permissions and access controls to determine who can access funds and change the smart contract data to avoid asset loss due to data manipulation or outside intervention.

Conclusion

These are only a few possible smart contract security breaches and attacks. Developers must rigorously test and review their code to ensure the contract’s security. 

Users should also know the hazards and only utilize reliable and secure smart contracts.