WOLF & CO Insights Securing Your Smart Contracts: 3 Common Vulnerabilities & How to Prevent Them

Securing Your Smart Contracts: 3 Common Vulnerabilities & How to Prevent Them

Written by: Stephen Nelson

Throughout your security career, you may come across terms such as Common Vulnerabilities and Exposures (CVE) or Common Vulnerability Severity Score (CVSS). These terms usually refer to the weaknesses in software, applications, or operating systems that are public-facing or internal on an organization’s network.

However, some CVEs may not be familiar to you, such as smart contract exploits, specifically costly ones. Smart contracts are self-executing contracts on the blockchain in which the terms of the agreement between the buyer and seller are directly coded. The vulnerabilities detailed below are the top three most reoccurring and exploitable weaknesses found in smart contracts. To help you safeguard your organization, we’ve outlined definitions, real-world applications, and best practices surrounding these vulnerabilities.

What is a Vulnerability?

A vulnerability is a weakness or flaw found in various forms of technology including not only software, but also hardware and firmware. At Wolf, our DenSecure team finds many weaknesses in organizations across various niches including the healthcare, financial services, and technology sectors. In the crypto and blockchain space, we find that vulnerabilities cause organizations financial hardship and reputational damage amongst competing firms.

Reentrancy Attacks

A reentrancy attack in smart contracts is an attack that allows a user to make an external call to another untrusted contract. As a result, the different invocations of the function may interact in an undesirable way.

Reentrancy Attack Example

In 2022, the Fei Protocol was the victim of an ~$80 million attack that was made possible by its use of third-party code containing reentrancy vulnerabilities.

Best Practices to Prevent Reentrancy Attacks:

  • Verify that all internal state changes are performed before the call is executed. This is known as the Checks Effects Interactions pattern.
  • Use a reentrancy lock (i.e. OpenZeppelin’s ReentrancyGuard).

Insecure Arithmetic Attacks

An insecure arithmetic attack, sometimes referred to as underflow or overflow, is an attack wherein the user-supplied data controls the value of an unsigned integer. For example, if Solidity 00-1 is equal to 99, an attacker can overflow the possible value of an unsigned integer. This might allow the attacker to withdraw more Ether, the currency of Ethereum.

Insecure Arithmetic Attack Example

In 2018, the author did not realize the existence of the underflow/overflow vulnerability, and 866 Ether was liberated from a smart contract in a Ponzi scheme.

Best Practice to Prevent Insecure Arithmetic Attacks:

  • Implement vetted safe math libraries for arithmetic operations consistently throughout the smart contract (i.e. OpenZeppelin’s Safe Math Library).

Access Control Vulnerability

An access control vulnerability is when visibility settings give an attacker a straightforward method to access a contract’s private values or logic. With access control, bypasses are often more subtle.

Access Control Vulnerability Example

In 2017, the had an access control vulnerability that allowed an attacker to access three multi-sig wallets. Luckily only three wallets were exploited, while a total of 596 were exploitable.

Best Practice to Prevent Access Control Vulnerabilities:

  • Implement controls so withdrawals can only be triggered by authorized parties or within the specs of the smart contract.

In the fintech space, applications, hardware, and internal networks are not the only source of vulnerabilities. Smart contracts also present significant opportunities for attackers. Vulnerabilities including reentrancy attacks, insecure arithmetic attacks, and access control vulnerabilities have implications that would not only impact an organization financially, but also impact their reputation. Without the proper security measures in place like audits, we could see these incidents repeated.