The way to WEB3 security : mindset and tools
« Code is Law » !
We all know this statement. The philosophical goal of smart contracts is to replace legal contracts whose terms are enforced by third parties (Judges, notaries, governments…) with decentralized contracts whose rules are defined and ensured by code itself. In this context, the code becomes the law. However, as you know, traditional law can suffer from various flaws such as legal vacuums, lack of precision, and excessive complexity…
This allows bad actors to circumvent the law whiteout actually breaking it (think about abusive tax optimisation). The same happen with code.
The equivalent of several dozen billion USD is currently locked in the entire web3 ecosystem. All these funds are secured by smart contracts whose codes are public and that can be accessed by anyone. Needless to say that this attracts many malicious actors. In this context, every web3 developer should have a deep insight into security.
The Defi security 101 that occurred on July 14 2023 in Paris was an opportunity to learn about good security practices and tools. In this article, we will present some of them. Keep in mind that most of these teachings are also applicable to web2.
1) Become a WEB3 hero !
The web3 ecosystem is full of opportunities, which also means full of ruthless villains ready to steal (or break) everything they can. In this context how can you become stronger and get the power to protect your smart contracts? What’s the way to becoming a web3 security specialist?
1.1) Acquire knowledge
First of all you need to acquire basic knowledge about the ecosystem. According to Joran Honig, a security researcher at Consensus Diligence, 80% of knowledge you need is not about security itself but about web3 in general: EVM, solidity, protocols, …
Then you can learn about well known hacks (you can, for example, look on rekt news) audit reports, well-known vulnerabilities …
1.2) Attacker mindset
The best inspectors are those who can put themselves into the shoes of criminals and think like them. To secure your smart contracts, you have to attempt to hack them. To acquire the attacker mindset, you must gain a deep insight of your code and try to tamper with it.
Hacking is possible when there is a gap between how your code is intended to behave and how it actually behaves. To shrink this gap, you can document (for example in specifications) all your assumptions about what your smart contract is supposed to do and verify that they are accurate.
The hacking spirit involves questioning your code to challenge it on edge cases.
Here is an example, provided by Joran Honig, of questions a security developer or an hacker ask to test the limits of a liquidation feature in a DeFi protocol :
1.3) Mitigate risk
Web3 ecosystem aims to be Trustless. However as Ken Thompson stated in it’s «Reflection on trusting trust» essay, you can’t be entirely sure that the software your system relies on is trustworthy. He demonstrated that even the compiler you use could theoretically have a back-door in it and, hence, could introduce backdoors into a program that has safe open-source code.
Nothing has a 0% failure rate: programmers, blockchain client, network software …
«You want to produce a reliable system from unreliable components.» discussed Kurt Barry, security researcher at Fixed Point Solutions LLC.
Security/hacking is an asymmetric battle. As Mudit Gupta (CISO at Polygon) said, « As a security person I have to get it right every single time, I can’t let any single bug go through (…) but as an attacker, I only need one weak point. »
Therefore it’s impossible to perfectly secure a system. What can be done instead is mitigating breaches by stacking several imperfect layers of security.
2) Security weapons
Human auditing is effective for identifying edge cases and simulating unconventional hacking schemes. However, manual security reviews are time-consuming, require significant expertise and cannot be automated. That’s why tools are necessary to complement human review.
2.1) Unit test
The first thing that comes to mind when talking about automated testing is unit test. Unit tests are well known to all developers and are easy to set up. 100% of smart contracts code should be covered by unit tests. Developer should pay attention to test both happy path and unhappy path and to attempting to catch edge cases.
However, unit tests are inherently limited by the tested input and cannot test integration between components. That’s why unit testing is the minimum security requirement but may not be sufficient.
2.2) Static Analysis
Since the creation of the EVM, numerous hacks have occurred and several smart contract vulnerability types have been identified by developers.
To enforce good practices in your smart contracts, you can use a static analysis process that automatically scans your code in order to find potential vulnerabilities.
To do that, you can use Slither open-source tool. Slither is capable of detecting 87 potential vulnerabilities or suboptimal design choices, such as some incorrect standard interface implementation, reentrancy vulnerabilities, variable shadowing…
Slither can be integrated to your CI via GitHub actions.
2.3) Testing with invariants
An invariant is a property of the code that always holds true. For example, an invariant of an ERC20 contract could be «The total supply is equal to the sum of balances of all holders».
There are two categories of invariants:
- Functions invariants: for the transfer function of an ERC20, an invariant could be « the sum of balances of the sender, and the receiver remains constant before and after the call to transfer function »
- System invariant: For a lending protocol, an invariant could be « the value withdrawn by the lender is greater or equal to the value it supplied»
Invariants are useful for testing a code.
2.4) Fuzz testing
A smart contract can have a vast array of input value. Unit testing can assess a limited number of these. The purpose of fuzz testing is to stress test the code with numerous random inputs (akin to a monkey typing on the keyboard) to determine if there are edge cases that cause unexpected issues. In traditional development, such an unexpected error typically results in a program crash. However for smart contracts, there is no such concept of a crash. Instead, we utilize property-based testing through invariants. The fuzz test fails when it finds an input that violates an invariant.
To use fuzz testing on your smart contracts, you can use the open-source tool Echidna.
2.5) Formal verification
Formal verification is a technique used to prove that some invariants (specifications) hold true for all possible states of a contract. Formal verification doesn’t make your code bullet proof but it significantly enhance security. It’s a heavy process that requires specific skills and that take a lot of time to be done. So it should be used only for critical features of complex programs.
For example, Aave is a very complex system and it’s not possible to cover all scenarios with tests, fuzzing and human verification. That’s why they worked with Certora to provide formal verification for securing some critical parts of their codebase. Certora is a company specializing in formal verification. They use the Certora Verification Language (CVL) to write the specifications rules for smart contracts.
Aave has integrated formal verification into their CI pipeline so that each pull request can be secured by their CVL rules.
Conclusion
Enhancing web3 security is critical, not only for protecting user’s funds, but also for the credibility of the entire ecosystem.
This post has primarily focused on smart contract security but keep in mind that web3 security is not only about solidity stuff. It also encompasses the security of secret keys security, wallet, clients, …
For more informations on this topic, go watch the replay of Defi Security 101 and Defi Security Summit (that occurred on 15 and 16 July) presentations on their YouTube channel. You can also test and improve your hacker skills on secureum-a-maze-x-challenges.
