10 Key Smart Contract Vulnerabilities: That can Lock your Crypto Assets.

Smart Contract Security To Prevent Possible Attacks

Smart contracts are codes deployed on the blockchain platform and executed upon meeting certain conditions.

A few smart contract applications are crypto assets, medical care applications, vote keeping, IOT, digital rights, gambling, music rights management, record keeping, smart property, and e-governance.

Smart contract security plays a crucial role in decentralized applications. An exploit in smart contracts happens due to vulnerability present in them without having a Smart Contract Audit.

Millions of dollars draining have been frequent for the past few years, like The DAO attack, King of the Ether Throne, Multiplayer games, GovernMental, Dynamic libraries, and Batch Transfer Overflow.?

Due to these reasons, it is imperative to remain fully prepared with an efficient detective and preventive methods with your smart contracts before deployment. 

Smart contracts are designed to be independent contracts that are not open to interpretation by other parties or jurisdictions. The code intends to serve as the last judge of “the contract” it stands for. Although unfortunately, it is not free from vulnerabilities. 

What are Smart Contract Vulnerabilities?

Unlike most other agreements, smart contracts primarily deal with financial assets. Hence, once deployed, errors in smart contracts cannot be rectified owing to the immutable nature of the Blockchain. 

Smart contract vulnerabilities could be a potential security hazard and a curious target for malicious cybercriminals. In fact, in some cases, even if there are no external exploiters, chances of capital collapse and financial losses are present. 

In this blog, we will discuss the ten most frequently occurring vulnerabilities you must keep in mind before deploying your smart contract on a blockchain.  

10 Key Smart Contract Vulnerabilities

Reentrancy

In Reentrancy attack, it is a malicious smart contract that exploits the vulnerabilities of another smart contract, usually to drain off its funds. 

In this case, working on a vulnerable smart contract, say Contract X includes checking the balance, sending funds, and then updating the balance sheet. This creates a window for the attacker contract, contract Y, to repeatedly call contract A. The cycle continues till contract X is deprived of all its funds. 

Access Control

The concept of Access Control, or “who is permitted to perform a particular task,” is crucial in the context of a smart contract. 

Your contract’s access control may determine who can issue tokens, vote on initiatives, halt transfers, etc. 

To prevent someone else from stealing your entire system, it is crucial to understand how you implement the access control function in your smart contract( malicious users should not breach access control). 

Floating Pragma

A solidity pragma is probably the first line of code in a solidity code that determines the compiler’s version of the smart contract. 

For a smart contract compilation, Floating Pragma categorically specifies an array of compiler versions.

Now a pragma does not change the version of the compiler, and all it can do is instruct the compiler to verify if it matches the pragma. In case of a negative result, the compiler generates an error. 

Using a strict pragma function, specifying the compiler version is advisable. This avoids the unintentional deployment of a contract with an outdated compiler with unresolved bugs.  

Zero Address Check For Critical Functions

A blockchain address is a public key linked to a hash identifier. In the case of Ethereum, it is the last 20 bytes of a public key hash.  

As your house has a unique physical key, your blockchain account has a unique private key(that you should not share with anyone else). These private keys enable you to conduct transactions on a blockchain platform. 

Now, deploying a smart contract on a blockchain is done through a transaction involving a sender and a recipient. EVM recognizes that when a transaction includes the zero address in the receiver field, it means establishing a new contract.

The zero-address resembles a “false account” in several ways. The zero-address is 20 bytes long, just like a typical Ethereum address, except it only contains empty bytes.

Also, there is no private key for a zero account, so if your smart contract is transacting to a zero address, there is no way of reverting that. This implies that your funds will be locked in a zero address forever. 

Divide Before Multiplying 

Let’s have a look at a simple mathematical example of this:

A= (10*30*18)/ 30= 180     

We are now solving the same equation but performing division before multiplication.

A= (10/30)* 30*18= 179.99999

Almost these two terms are quite close but not the same. In the case of a solidity smart contract, it is going to yield 179. Therefore, performing multiplication before division mitigates rounding-off errors in a smart contract. 

Frontrunning

Frontrunning is a term for stock trading concerned with insider trading. A Malpractice where insider information impedes the market before the actual competition begins. 

In the crypto space if it is defined as the employment of unconfirmed transactions by paying a higher gas fee to the miner. This is possible due to the public nature of the Blockchain and can also be done using a front-running bot.  

This type of problem majorly requires code refactoring or redesign to be solved.  

Missing Withdraw Functions 

A common vulnerability is when your smart contract has a payable function but misses out on the withdrawal function. It implies that there is only a payment option in your smart contract, and if you are a sender in case of a transaction, your funds are bound to get locked in your contract. 

Integer Overflow and Underflow

Firstly, look at the example given below.

EVM states fixed-size data types for integers, implying that integers can represent only a specific range of numbers. 

If a solidity code deals with overflow or underflow issues, there may be a significant difference between the calculation’s actual outcome and expected results. 

This will undermine the contract’s inherent logic and result in the contract’s funds being lost. Version limitations do apply to overflow vulnerabilities, though.

Overflow will not generate an error in Solidity versions up to 0.8, but it will in versions after 0.8.

Using Block Properties For Randomness (Miner Manipulation)

Solidity does not have a process to generate random numbers, but many turnarounds have come up with a developer’s wish to include randomness. The miners, for their benefit, can exploit these random number generators. 

One frequently employed method is using a pseudorandom number generator (PRNG), which generates a string of bytes that appear random in a predictable manner based on an initial private seed value and internal state.

Poor Visibility Specifiers For Critical State Variables May Lead to Abuse.

In the case of solidity code, visibility specifiers govern the manner of calling a function. The visibility specifier assumes control when allowing users to employ derived contracts to call for external functions.

The smart contract may suffer catastrophic consequences if the visibility specifiers are implemented incorrectly. If functions’ default visibility is always set to public, external contracts can request visibility even when functions don’t explicitly mention it.

Developers fail to set the visibility specifier to private, which results in this vulnerability.

How to Avoid Vulnerabilities in Smart Contracts

There are several ways to safeguard your smart contracts. Some of them have been mentioned below. 

1. Healthy Development of code

There are a few practices that need to be followed, to completely avoid or mutate a code in case of an encountered bug in the smart contract. 

Firstly, the use of proxy codes to ensure upgradability

Supposedly, we have two smart contracts, let’s call them A and B, where A is the proxy contract and B is the logic contract. 

A interacts directly with the user and has a delegate function that sends the transaction to B. 

Since blockchain is immutable both A and B cannot be changed once deployed but in case of an issue with the logic, the link between A and B can be broken and replaced with an upgraded logic via another smart contract C.  

Secondly, developers should write unit test cases.  

It encompasses the implementation of comprehensive test coverage associated with smart contract functionality. It ensures the optimized performance of the functions included in the smart contract. 

Thirdly, Using the latest version of the Libraries

Open-source libraries provide reusable standard codes, these are tried and tested pieces of code for vulnerabilities. Hence, using the latest version of libraries significantly reduces the probability of vulnerabilities in smart contracts.

2. Internal Security Checks – Internal Audit

Setting up an internal team of security professionals acts as the first line of safety for your smart project. Also, An internal team can frequently audit your code for bugs in comparison to a third-party audit. 

3. Regular Audits

Undoubtedly, the blockchain space is on its development curve and with its evolution, security concerns and vulnerabilities are also evolving. 

Hence, regular audits aid in ensuring the protection of your smart contract from the evolving bugs in the Web3.0 domain. 

4. Bug Bounty

A bug bounty program provides a platform for building a bridge between the project and the whitehat hackers. Here, real-world hackers tamper with your code to find vulnerabilities. 

ImmuneBytes is all set to launch its BugBytes (A Bug Bounty Platform), where you can ensure the security of your smart contract by competing with hackers and paying only if they catch a bug.   

5. Opt for Security Monitor Tool/Alert Tool

In the blockchain space, repeated or blacklisted offenders are a reality. Deploy a tool or outsource an alert service to acquire notification in case a blacklisted hacker is tempering with your smart contract. 

Immunebytes is soon launching its alert tool, AlertBytes, to notify the transaction on your smart project. Here you can customize your service based on the alert method(place of receiving notification), condition( send or receive transaction alerts), and threshold( minimum amount of transaction).  

Sum Up

Smart contracts are the backbone of the blockchain space, especially with its ever-widening domain usage. With the rapidly scaling Blockchain uses, vulnerabilities are probably inevitable. 

But, there is a simple yet effective way out. A third-party review of the smart contract and in case your budget allows further, succeeding it with a bug bounty would be a good idea!!

It seems like an additional burden on your pockets but trusts us; it could save you from a potential catastrophe. Any project that cares about the security of its smart contracts must include a third-party solidity smart contract audit as a standard procedure.