Smart contract development is difficult. Part of what makes smart contract applications so appealing is their immutable (or quite often semi-immutable) nature. It helps keep the ecosystem trustless, as we can count on the code to perform exactly how it says it will. But this also means development teams have one shot to get it right before their project is a sitting duck for any dangers lurking in the dark. Sure, they can participate in monitoring and bug bounty programs but as we saw with this past weekend’s Sushi Swap hack, fixing bugs post-deployment comes with its own challenges. If we’re ever going to reach mass adoption of Web3, we need to make users feel comfortable when interacting with decentralized applications. We need to reduce the number of hacks that occur in this space. By reviewing what vulnerabilities are being missed before deployment, we can work to prevent future incidents.
This article is for developers, auditors, and anyone who wants to understand the most common security incidents to date in 2023. We took an in-depth look at nearly 40 smart contract hacks that occurred this year to bring you the list of the top 5 most common issues. This list excludes hacks that are not directly related to smart contract vulnerabilities such as: rugpulls, mishandled admin keys, phishing, or governance takeovers that did not rely on an issue present in smart contract code.
This category is broad and encompasses a wide range of vulnerabilities that were caused by either a mathematical or logical mistake in the deployed code, but did not fit well in any of the other categories. Incidents in this category contained errors related to incorrect collateralization requirements, the accrual of bad debt, incorrect decimal scaling of tokens, inappropriate rewards distributions, off-by-one mistakes, or other mathematical errors. There were 12 instances identified as faulty calculations.
Notable hacks: Allbridge, Euler Finance, Platypus Finance, Omm Finance
The approval mechanism for tokens on EVM chains is used to give permission in a permissionless world. Approvals work by allowing another party to spend tokens on your behalf. This is convenient when you are sending tokens through an intermediary or when interacting with a contract that will need to use your tokens to perform an action such as swapping on a DEX. One of the biggest dangers of approvals is that it can be cumbersome, expensive, and even downright tricky to frequently gather and spend them in full. As a result it is common practice for many applications to request “infinite approvals”. Many of these approvals persist unrevoked for EOAs and contracts alike, so when a bug appears in the contract, all of these approved funds can be at risk. There were 7 incidents that were identified as approval issues.
Notable hacks: Cow Swap, Dexibel, FEGToken, Dungeon Swap + Launch Zone, Sushi Swap
Oracles are how on-chain applications get information from the real world. In other words, they are used to provide off-chain data to on-chain applications. Integrating oracles can be a challenge because even a moment of inaccuracy in reported data can have catastrophic consequences. A small discrepancy in price reported by an oracle can open up a DeFi application to huge amounts of arbitrage. As a result, oracle results are often aggregated and weighted across a period of time to reduce the points of failure. Nevertheless, oracle issues are still one of the most common occurring incidents in smart contract security. This category includes issues where the oracle dependencies provided faulty data, the oracle reported on an easily manipulable pool, or the oracle relied on spot prices. There were 4 incidents that were identified as oracle issues.
Notable hacks: Mycelium, BonqDao, ROE Finance, DKP token
Reentrancy is perhaps the most infamous issue in the smart contract auditing and development world. It can occur when a contract contains an operation where its control flow can be interrupted and rerouted. This is often the case when a contract contains external calls made to other contracts. The state that a contract is in the moment it gives up control flow to another contract is the state it will be in if it is “reentered”. That is to say, if control flow is given up to another contract and that contract decides to interact with the original contract once more (within the same transaction), the original contract will maintain the state it had before it gave up control flow. This becomes an issue when the original contract relied on logic occurring after control flow was given up to put it in a valid or safe state. While classic reentrancy is the oldest trick in the book for smart contract hackers, read only reentrancy is more nuanced in that it takes advantage of applications that rely on unguarded view functions to perform important calculations. There were 4 incidents that were identified as reentrancy, 3 of which were read only reentrancy.
Notable hacks: Midas Capital, Orion Protocol, DForce, Sentiment
Access controls are what define how users of an application can interact with it. They limit the roles of certain users so that they can’t unfairly impact other users or the system itself. Oftentimes these are enforced via function modifiers and function visibility. While access controls are not intrinsically more difficult to implement than a lot of other potential security concerns, a mistake in access controls can have large consequences. The issues here included a public burn function, an unprotected mint function, and a Cardano specific issue where the project assumed using solely stake addresses would be sufficient for user validation. There were 3 incidents that were identified as inappropriate access controls.
Notable Hacks: SafeMoon, Degen Millionaires Club, Mutant NFTs
Technically rebasing tokens tied for 5th place, however the amount of funds lost was used as a tie breaker and more were caused due to inappropriate access controls. Rebasing tokens are tokens that can have their balances (or some other mechanism used to calculate their value) manipulated during certain events. This could be an increase to the total supply via minting of new tokens, or a decrease in the value that tracks the total available balance to represent burning of tokens. This allows a token to hold inflationary or deflationary properties. Rebasing tokens are difficult to manage in an application because the posts are always shifting. It is easy to overlook edge cases when integrating with tokens that can change their effective supply. These changes often lead to applications that operate on point in time values while anticipating future deviations. There were 3 instances identified as rebasing tokens.
Notable Hacks: Sperax, BEVO NFT, Dragonball
Faulty calculations unique to projects are by a large margin the most common issue leading to hacks on deployed smart contracts right now. After that, we see that contracts holding approvals on behalf of other parties led to a large portion of the incidents. The design choice of holding approvals for users places a great deal of responsibility on the project and as a result, the security of such projects should not be taken lightly. They should be particularly careful when accepting user input and making external calls. The presence of oracle and reentrancy issues high up in the list reminds us that variations of these problems are still proving difficult for development teams to avoid. Finally, the fact that rebasing tokens made the list shows us that integrating with tokens that have a changing supply can greatly increase the complexity of an application.
The best way to bring the number of hacks down today is for projects to get a high quality audit before deployment. A vast majority of hacks still occur on unaudited codebases.
This news is republished from another source. You can check the original article here