Smart contracts are the foundation of DeFi, NFTs, play-to-earn, and other phenomena associated with the internet. Unfortunately, while smart contracts are awesome and store huge amounts of value, they are not as secure as we think. Smart contracts contain bugs and vulnerabilities that attackers exploit to steal funds.
In my humble opinion, smart contract attacks are made for fun or to prove a point - they can hack the protocol. While these attacks are not purely evil, they show the lengths humans would go to satisfy our whims.
In the past, the attacks were spread out and less devastating. However, the attacks have recently been bolder, with hackers making away tens and hundreds of millions of dollars. October alone has been hacker’s most profitable month, with over $700 million in hacks.
How is this possible? What attack vectors are hackers exploiting which give them an unfair advantage?
As a brand new and fast-paced field, answers to these questions are important. And the answer is better coverage and understanding of these vulnerabilities so users and developers can properly mitigate the attacks to prevent more loss of funds.
The causes of previous attacks are the popular vulnerabilities listed below:
- Re-entrancy: The word “reentrancy” means “entering again (reentering).” The main vulnerability of reentrancy smart contracts is that they receive addresses as function parameters. This is dangerous as another harmful external contract can initiate transactions without us knowing.
- Timestamp Dependence: This bug happens when the smart contract relies on the value of the blockchain’s timestamp for execution. The problem is that the timestamp is generated by the node(s) executing the code making the feature open for manipulation.
- Transaction Ordering Dependence: This attack is also called the Front Running attack. It happens when someone else (the attacker) sends a transaction that modifies the price before your transaction is recorded. This action creates a vulnerability because each smart contract relies on the state of storage variables staying at a certain value during transactions.
- Call to Unknown: Call to unknown vulnerabilities occur when a function that doesn’t exist in the target contract is called. This action is a special function that the hacker can create, giving them some access to transact with the address.
Apart from the vulnerabilities mentioned above - which are the main types - there are about 36 other known vulnerabilities that plague the smart contract ecosystem. Discovering these vulnerabilities and bugs would have been impossible without the available vulnerability detection tools.
For context, vulnerability detection tools are automated tools that crosscheck and analyze smart contracts to identify potential vulnerabilities. In my upcoming discussion post, I listed and explained the available tools under their input and analysis methods. There are two analysis methods - static and dynamic. As the name imply, the static analysis method involves examining the code without executing the program. The dynamic analysis method involves testing and evaluating the code by running it in real time. Furthermore, these analysis and input methods are responsible for how well and fast an analysis tool detects contract vulnerabilities.
In the key finding section, we notice that most if not all smart contract attacks can be mitigated with better coding practices. With this finding, we can infer that the programming language - Solidity - is also responsible for causing bugs.
The programming language is very nascent, notwithstanding the amount of dapps built with it. Everyday, developers are still figuring out different parameters for smart contract applications. While that happens, hackers also keep up with the updates and look for loopholes they can exploit.
In closing my comment, I am particularly interested in how Ethereum’s switch to PoS influences the exploits. Would be glad to learn more in that direction.