It’s only a matter of time from when a blockchain project is developed and deployed until someone targets it — knowing what to look out for goes a long way towards mitigating these concerns.
There are many kinds of threats, from rug pulls and access control exploits to DNS spoofing and private key compromises, for founders and security teams to keep in mind when bringing a protocol to market. The data in this article is gathered from 2017 onward (except the DAO exploit), and grouped by attack type.
While reading this article, which is the first in a series of articles on security, ask yourself “how did I avoid being a victim to these cyber criminals?” And keep in mind that understanding the risks in the ecosystem goes a long way towards creating a secure dApp.
Exploits are lucrative
The chart below shows the different types of attacks, their frequency, and the amount of funds stolen in each instance.
As you can see, price oracle attacks tend to be the most popular, with protocol logic hacks not far behind. But they are far from the most profitable.
When considering which protocols are most likely to be hacked, it’s worth keeping in mind that Ethereum may appear to be the most vulnerable, but that is only because it has by far the most development activity.
*money stolen per blockchain
You might be wondering why we mention Rugpulls in the table. Glad you asked!
First off, it’s a lot of money; secondly, we see it as an important vector because an inside job or whole team vanishing with the money is still a theft and exploitation of the ecosystem. And these happen far more often than many people realize.
Know your threats
- Rugpull — This is when a dishonest project team either fakes a hack and disappears with the money raised or total value locked (TVL); or just straight up takes the money and disappears as part of a broader scheme to defraud investors/their community
- DNS spoofing — This exploit has roots in the web2 world and involves a hack where servers and/or routing are compromised and attacker addresses injected to them, giving the malicious actors control over the systems used to run the protocol/project
- Administration operations & misconfiguration — This occurs when an admin executes a transaction that causes a vulnerability, or when they change a state to a wrong value, enabling intrepid hackers to spot an opening and take advantage of the mistake
- Frontend attack — This is another web2 attack vector, when the website of the protocol is not secured enough and unfortunately open to XSS (cross-site scripting) or some other manipulation on either the front side or the backend that can cause users to lose money; phishing schemes can also be included in this group
- Reentrancy — Oh, the infamous reentrancy — this kind of exploit enabled bad actors to take advantage of code bugs in a sophisticated manner. Basically, this happens when code flow logic is more of a code flaw logic, and can refer to a case where one of the protocol’s smart contracts calls to a contract outside the protocol that can execute third-party instructions (like entering again to the protocol and withdraw money for example) before the state is saved
- Price oracle attack — In this instance, hackers manipulate an outsider data provider for the protocol, most of the time an automated market maker (AMM) with a flash loan
- Access control exploit — This is when contracts deployed with restricted functions open to unauthorized addresses that cause severe damage
- Protocol logic — A high-level vulnerability that is caused by a loose end in the protocol architecture or some imperfection in the general plan of the protocol
- Code bug — This one refers to exploits that occur when the code execution of the smart contracts isn’t sound enough and enables unwanted behavior — e.g wrong formulas/calculations, wrong/missing validation, etc.
- Private key compromising — These actions often cause the most damage because the nature of the blockchain is basic immutability of code and transactions — what happens on-chain stays on-chain, when money is transferred or a transaction is sent, it can’t be reverted; when a private key is compromised, you can’t simply update the password to keep your private keys from being compromised; these attacks are successful from a number of angles including phishing scams and social engineering against weak safety best practices, or even a vulnerability in the generation of private keys
All hope is not lost
Keeping a protocol safe involves a lot of hard work to keep each one of these exploits vectors blocked and staying updated on the latest best practices and tools
In our next post, we will go over these best practices to keep protocols safe in front of each one of these attack vectors.
Learn more about smart contracts protection at: