Auditing Smart Contract

I did a piece on smart contract where I detailed the basics of the technology, how it works, platforms that drive smart contract and its diverse use case. The article can be found here:

Smart Contract.

In this article, we will further explore smart contracts by considering the security. 

let us break down Auditing Smart Contract

1. What is an Audit?
2. What is smart contract audit?
3. Types of Smart contract audit?
4. Common vulnerabilities
5. Smart contract audit steps
6. Audit Report Structure

Audit generally involves the inspection of any subject area along the lines of systems, processes and people (behaviour) to check for deviation from laid down or generally accepted standards. So with the definition of audit as a launchpad, we can describe smart contract audit as the inspection of automated contacts sitting on the blockchain for possible gaps and deviations from standards that will impact the logical flow of the case which has been automated in the contract. 

A smart contract audit is very much synonymous with code audit, as smart contracts are basically business or process flows coded into a contract on the blockchain. The process involves inspecting the smart contract code for security flaws and vulnerabilities before deployment to production (blockchain either a public or private chain). Since the blockchain has append-only features, which means that once the contract has been deployed, it cannot be altered and also smart contracts are self-executing, it is important that all tests such as functionality tests and security tests are conducted before deployment.

There are two major approaches to auditing smart contract which are:

1. Manual code review 
2. Automated code review

1. Manual Code review (MCR): This is the process of carefully examining the smart contract code line-by-line for possible vulnerabilities. This is a laborious process, as a lot of patience, skill and domain-level experience is required. Considerable man-hours are always dedicated in this approach which comes with both its pros (having multiple sets of eyes on looking out for possible security flaws )and cons (time which can be dedicated to other project efforts is spent here).
2. Automated Code Review (ACR): In this approach, the smart contract code is benchmarked against a predefined set of rules and best practices using an automated tool. This is by far an easier approach when compared to Manual code review, as the checks have been built into the tool, which conducts the assessment on the fly, and produces a report, that the smart contract code issues which the development team can quickly remediate.

Missed the article? Static code analysis: An introduction 

Common Smart Contract Vulnerabilities

Several smart contract vulnerabilities have been identified over time, I will briefly discuss three major vulnerabilities in this section:

1. Reentrancy
2. Race condition
3. Overflow and underflow attack

1. Reentrancy: A procedure is said to be re-entrant if its normal execution can be interrupted in the middle, initiated over (re-entered) and both runs can complete without any error in execution. A good example of this attack is a user initiating several transfers without actually submitting any of them, assuming the balance is only checked once at the point of confirming that the user’s account holds a sufficient balance for each individual transfer. If there was no additional check at the time of the actual submission, the user could then submit all transactions and potentially exceed the balance of their account. A good example of this hack was a DAO () hack in 2016 where $70 million worth of ether was stolen.

2. Race Condition: A race condition vulnerability occurs when a code depends on the order of the transactions submitted to it. The simplest example of a race condition is when a smart contract gives a reward for submitting information. Say a contract will give out 1 token to the first person who solves a math problem. Alice solves the problem and submits the answer to the network with a standard gas price. Eve runs an Ethereum node and can see the answer to the math problem in the transaction that Alice submitted to the network. So Eve submits the answer to the network with a much higher gas price and thus it gets processed and committed before Alice’s transaction. Eve receives one token and Alice gets nothing, even though it was Alice who worked to solve the problem. A common way this occurs in practice is when a contract rewards people for calling out bad behaviour in a protocol by giving a bad actor’s deposit to the person who proved they were misbehaving.

3. Overflow and Underflow attack: An overflow occurs when a number (token) gets incremented above its maximum value and an underflow occurs when a number (token) gets reduced below its minimum number. These are viable bugs that affect the smart contract if not well checked and or bounded at the code level. Suppose we declare an uint8 variable, which is an unsigned variable and can take up to 8 bits. This means that it can have decimal numbers between 0 and 2^8-1 = 255. If you increment 255, it will automatically be 0, if you decrement 0, it will become 255. No warnings, no errors. This will be a big problem if a token balance is stored in a variable and a decrease is made without checking.

Smart contract Assessment Steps

The generic steps listed below can be taken as a guideline when assessing smart contract security in a client environment.

1. Explain who you or your organization are: In the stage of the assessment, you are to spell out to the audit client who you are and your level of experience in the field, detailing a background of the assessments you have conducted.
2. Explain your audit process: The process you will employ in the smart contrat security assessment should be explained at this stage, detailing the steps you will employ from a risk and security viewpoint.
3. Conduct the Assessment: At this stage, the smart contract assessment is conducted by running the code base either through a manual assessment based on prepared test plans, automated assessment using tools, or a mix of both approaches. The goal of this stage is to unearth all possible security flaws in the design of the smart contract.
4. Document the Observation: All issues observed in the course of the assessment should be clearly documented considering the criticality/materiality of each observed issue.
5. Report presentation and discussion: A detailed report with an executive summary should be prepared and reported to the auditee management, highlighting and discussing the issues in a risk-based approach.

Audit Report Structure

Audit reports are very essential in auditing smart contract process as it communicates the to the management and relevant stakeholders the risks inherent in the smart contract, which enables them to make informed decisions and remediation before deployment. The below smart contract audit report structure from HashEx can be adopted:

1. Disclaimer. This part of the report is actually more important than you would think. As an auditor, you need to explain to your client that passing your audit is not the ultimate security insurance. Everyone can make mistakes and you are not an exception.
2. Background: Why did you decide to take this audit? Who gave you permission?
3. Critical Severity Issues: This part is about issues and vulnerabilities which can cost your client an unlimited amount of funds. 
4. High Severity Issues: Here you describe issues that can cost your client a limited amount of funds. This amount can be calculated before contract deployment. 
5. Low Severity Issues: This part is not about losing funds. It is about minor problems or better solutions.
6. General Recommendations: Here you provide recommendations on code improvement and best practices implementation.
7. Conclusion: Here you describe the next steps for your clients after they read the report.

Here you have it on auditing smart contract, what can you say about it? let me know in the comment section.