BOOK THIS SPACE FOR AD
ARTICLE ADHey there, I am Samrat Gupta aka Sm4rty, a Smart Contract Auditor at QuillAudits and a Part-time Bug Bounty Hunter. In this blog, I will share my methodology for auditing smart contracts. While there is no universal approach, this post provides insight into creating your own. Additionally, it includes resources and advice to help you become an efficient and effective auditor.
This Blog is also published at DeFiHackLabs’s Substack as a Lesson 1 in Solidity Security Series. Check it out here.
Let’s start:
Before starting with auditing, one must first understand the project first which includes the technical designs, objectives of the Project, Contract types, etc. There are many sources that can help an auditor to understand and grasp the project.
Whitepapers or Documentations.Code Comments and NatspecProjects Website/Blogs and so on.Developing Mental Model
While reading through the documentation It is critical to develop a mental model for auditing. The audit will be built on your mental model of the smart contract system. Before looking deeper into the details, it is essential that we have a strong high-level understanding of the contracts.
Some tools can help you assist with this process:
Solidity Metrics: This extension will generate Source Code Metrics, Complexity, call graphs, and Risk profile reports for projects written in solidity. It will help you understand the overview of the contracts.
Solidity Visual Developer: This extension contributes security-centric syntax and semantic highlighting, a detailed class outline, specialized views, graphs, advanced Solidity code insights, and augmentation to Visual Studio Code. You can use it to automatically generate call graphs and UML diagrams.
Static Analysis Tools:
In this step, we will run some static analysis tools. Static analysis tools are used to analyze smart contracts for common security vulnerabilities and low-hanging bugs. Static Analysis tools will drastically decrease your false-negative rate and help you catch things that manual analysis rarely uncovers.
We can use Mythx, Slither, Mythril, 4naly3er, and a lot of other tools for it.
Fuzzing Tools:
Fuzzing involves providing a large number of random inputs to a smart contract and observing how it responds. The goal of fuzzing is to find edge cases and unexpected behaviors that might indicate a security vulnerability or bug. We can use tools like Echidna, Foundry Fuzz, or some other tools for fuzzing.
It’s important to note that, while these tools can provide valuable insights and identify any potential issues, they are not a replacement for a thorough manual review, which is our next step.
Now, that we know the overview of what the protocol does and have an eagle-eye view of the contracts. Let’s dive deep into the contracts and start Manual Auditing. Start Reading the codes Line by Line to get an understanding of the contracts.
Think like an attacker and identify potential places where things can go wrong. The following are some of the most common checks I look for:
Common Smart contract bugsAccess Controls Checks in Critical FunctionsCheck if the contract complies with the standardsThe flow of Function callsExamine all User-controlled InputRealistic attack scenarios and edge casesA lot of the bugs and vulnerabilities that actually impact a code are protocol-specific. Finding these protocol-specific bugs requires a thorough understanding of protocol and some creativity. Identify the protocol’s pain points by brainstorming ideas and looking for edge cases.
Note-Taking:
When auditing a complex or large codebase, it is important to take note of anything that appears to be wrong. Utilize some notetaking software like notepad, notion, or Evernote.
VScode Extension Inline Bookmarks can also assist you with the process. While reading the code, we can add audit tags wherever we find bugs or suspect a vulnerability. We can get back to it later.
A POC is a demonstration of the feasibility and viability of an idea, and in the context of smart contract auditing, it serves to validate if the vulnerability is valid. Now that we found some vulnerabilities, We can write some PoC tests using frameworks like foundry, hardhat, or brownie. Below are a few ways to write PoC for our findings:
Unit TestExploit on a ForkSimulationIt’s critical to provide sufficient comments throughout each PoC, both for our own understanding and that of others.
A good report should contain:
Summary of the vulnerability: A clear and concise description of the vulnerability.Impact: This section is where Auditors provide a detailed breakdown of possible losses or damage to the protocol.Assigning Severity: Severity can be classified as high, medium, low, or informational depending on the impact, likelihood, and other risk factors.Proof of concept: A valid PoC might be an attack script in Hardhat/Foundry test file that can trigger the exploit or any code that manages to somehow exploit the project’s vulnerability.Mitigation steps: In this section, the auditor should provide a recommendation on how to mitigate the vulnerability. This will be beneficial for the project, making it easier to resolve the issue.Reference [Optional]: Any external reference links related to the vulnerability.