Smart contract audit checklist for 2021 by QuillAudits | DeFi

It can unquestionably be stated that the increased adoption of smart contracts demands strong security guarantees. Unfortunately, it is challenging to create smart contracts that are free of security bugs. As a consequence, critical vulnerabilities in smart contracts are discovered and exploited every few months.

Significance of Smart Contract Security Audit

The rise of Decentralized Finance is inevitable. The DeFi market is growing at an incredibly exponential rate.

However, this year has quite clearly proved that it’s indispensable to consider the best security practices while developing the Smart Contract or building an entire Decentralized Application with so much at stake.

Most importantly, it’s high time for us to understand that Smart Contract Audits can no more be neglected.

With a significant dependency on smart contracts, DeFi audits become crucial where a third party reviews every line of code and helps to identify the bugs and bottlenecks.

If left unaudited, the DeFi contracts may result in setbacks that include loss of funds and manipulation of the system. Sometimes, it may also lead to the shutdown of the company.

Therefore, it becomes necessary to check the team’s quality auditing your DeFi contract and get acquainted with their auditing process.

Vicious Smart Contract Vulnerabilities that can Wipe Out Millions

  1. External Calls — Although external calls have their own significance but are extremely risky since they can technically shift the control over execution to any malicious actor.

dForce, a decentralized finance protocol lost around $25 million in April 2020. The attack took place when LendFi, the lending app of dForce, was exploited because of an external call that led to a reentrancy attack.

Note: It is crucial to ensure that no state changes take places after an external call is made. Read more about external calls and their vicious side here.

2. Reentrancy Attack ( DAO Fiasco )

The Dao Hack on June 17, 2016This was the hack where the attacker could steal 3.6 million ETH in the first few hours of the attack by sampling the reentering the contract again and again.

3. Price oracle Manipulation

The year 2020 witnessed some massive price oracle manipulation attacks. Renowned DeFi protocols like bZx hack, Harvest, Cheese Bank hack faced huge losses due to manipulation of price oracles.

While bZx lost $350,000 in the first attack(12 Feb 2020), it lost around $650,000 in the second attack(18 Feb 2020). On the other hand, Harvest finance lost approximately $24million due to an oracle manipulation attack using flash loans.

Read more about flash loan & oracle manipulation attacks here.

4. Ownership of the deployed contract

Parity Multisig wallet lost 150,000 ETH, which was around 30M USD back then.

5. Timestamp Dependence

Note: If the contract function can tolerate a 15-second drift in time, it is safe to use block.timestamp

6. Storage injection vulnerability in NEO Smart Contracts (which allows anyone to change the token’s total supply limit by transferring their tokens to an unspecified address.)

We keep ourselves always updated in smart contract auditing technology, try our best to keep us most up to date with the latest security practices. I am writing this blog to share our checklist and framework to audit every contract. This checklist can be applied to any smart contract, but we use other strategies to ensure smart contract’s security based on the contract’s business logic.

Imperative Checkpoints a Contract must go through

To ensure your code is easily followable by auditors, team members, automated tools, and the wider community, you should follow the style guide based on Solium’s standards. Having a set and automatically enforced style guide will additionally make it easier to spot the erroneous code.

1. Correct Functions Visibility:-

Functions in solidity can have four visibility specifiers: publicexternalinternal or private, with the public being the default. State variables can be publicinternal or private, with internal being the default. Explicitly specifying the visibility of functions and state variables is a security best practice.

Absent specifiers can be dangerous, especially in the case of functions where the default is public accessibility. If such a function has critical logic, then it can be triggered from any external address to misuse the contract potentially. The first hack on the Parity multisign wallet exploited such missing function visibility specifiers leading to the attacker stealing $31M worth of Ether.

2. Data Storage:-

In solidity, data can be stored in memory which is non-persistent and less expensive, or in storage that is persistent and very expensive. While writing smart contracts, one should properly analyze where the data should be stored. By default state variables and local variables are stored in storage and function parameters are stored in memory.

3. Prevent overflow and underflow:-

An overflow is when a number gets incremented above its maximum value. Solidity can handle up to 256-bit numbers (up to ²²⁵⁶-1), so incrementing by 1 would result in 0.

Likewise, when the number is unsigned in the inverse case, decrementing will underflow the number, resulting in the maximum possible value.

Underflow and overflow can be prevented by using SafeMath library to perform math operations in smart contracts.

4. External Calls — Every external contract call is a risk:-

External calls to untrusted contracts can bring certain risks and errors. External calls may execute malicious code in that contract or any other contract that it depends upon. As such, every external call should be treated as a potential security risk. When it is not possible, or undesirable to remove external calls, use the recommendations.

5. Check for re-enterancy and ensure the state committed before the external call.

The Reentrancy attack, probably the most famous Ethereum vulnerability, surprised everyone when discovered for the first time. It was first unveiled during a multi-million dollar heist which led to a hard fork of Ethereum. Reentrancy occurs when external contract calls are allowed to make new calls to the calling contract before the initial execution is complete. For a function, this means that the contract state may change in the middle of its execution as a result of a call to an untrusted contract or the use of a low-level function with an external address.

Loss: estimated at 3.5M ETH (~50M USD at the time)

6. Don’t delegate the call to untrusted code.

The delegatecall the function is used to call functions from other contracts as if they belong to the caller contract. Thus the caller may change the state of the calling address. This may be insecure.

7. Save Gas on smart contracts.

Saving gas is necessary to build an efficient smart contract. It is one of the main issues that the developers face because not all of them know how to do it correctly. Auditors at QuillAudits understand well which instructions consume more gas and how we can avoid or minimize them.

8. Timestamp Dependence

If the contract function can tolerate a 15-second drift in time, it is safe to use block.timestamp.

9. Compiler warnings

All the compiler warnings are serious issue sometimes developer ignores warnings and deploys contract without considering them as a significant threat to their smart contract, we recommend necessary action to be taken to remove all the warnings.

10. Ownership of the deployed contract

It is very important to provide ownership to a contract at the time of deployment or a restriction to function calls else attacker may call those function or transfer ownership function before you or if you are required to give ownership of a contract later, most famous bug of this kind is oyster-pearl because ownership of smart contract was open attacker transfer ownership to himself and able to mint tokens of worth ~$300,000.

11. Oracle calls

Blockchains cannot access data outside their network. An oracle is a data feed provided by a third-party service designed for use in smart contracts on the blockchain.

Oracles are third-party services which are not part of the blockchain consensus mechanism. The main challenge with oracles is that people need to trust these sources of information.

12. Lock pragmas to specific compiler version:

pragma solidity ^0.4.4; this is bad pragma solidity 0.4.4; this is good

13. Security Tools

After manual and unit testing, your smart contract undergoes automation testing that is done using many open source security tools.

Visualization:

Solidity Visual Developer ,Surya , Solgraph, Evm-Labs, Ethereum-graph-debuger

Static and Dynamic Analysis:

Slither, Mythril, Oyente, Securify, Smartcheck

Test Coverage:

Solidity-coverage

Linters and Formatters:

Linters improve the code quality.

Solcheck, Solhint, Solium, Prettier Solidity Plugin

We use multiple in-house automated tools in addition to the tools listed, to secure your smart contract and to find whether your smart contract can fulfil your business requirements. apart from automated tools your smart contract code goes under multiple testing phases like static testing which is done manually by our expert audit team thereafter smart contract comes under unit testing which is done using truffle, the test suite is prepared for each and every function in your smart contract to know whether your function is capable of handling overflow, underflow condition, reflected variable in that function should maintain their value properly, then Solidity-coverage is used to know how much our test cases are penetrating your smart contract functions, final report after reviewed at multiple levels is delivered to the client including all the possible suggestions and severity issues raised during the audit.

Some recent Audit reports, Audited by us are :

UnionTron Audit ReportCentralex Audit reportChocoSwap Audit Report

We welcome feedback on the procedures so we can keep iterating and improving.

Thanks for reading. Also, do check out our earlier blog posts.

About QuillAudits
QuillAudits is a secure smart contract audits platform designed by QuillHash
Technologies.
It is an auditing platform that rigorously analyzes and verifies smart contracts to check for security vulnerabilities through effective manual review with static and dynamic analysis tools, gas analysers as well as simulators. Moreover, the audit process also includes extensive unit testing as well as structural analysis.
We conduct both smart contract audits and penetration tests to find potential
security vulnerabilities which might harm the platform’s integrity.
For further discussion and queries on the same topic, join the discussion on
Telegram group of QuillHash —
https://t.me/quillhash

To be up to date with our work, Join Our Community:-

Telegram | Twitter | Facebook | LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *

Top