In web3 security, a vulnerability refers to anything that can be leveraged by a hacker to exploit the protocol. This might be something in the way that the blockchain or wider project is structured; a flaw in the underlying code of the blockchain; or an error of bad practice conducted by an individual user due to a lack of education.
Whatever form they take, vulnerabilities are an inevitable part of any new and growing technology. Yet the stakes of these vulnerabilities are especially high in web3 given the astronomical value in funds and assets handled by blockchains. This makes them highly lucrative targets for hackers and creates a high demand for web3 security projects which strive to eradicate blockchain vulnerabilities and the painful losses they incur.
This post will take you through some of the most common vulnerabilities that occur in blockchain, and the steps that projects and users can take to avoid them. For an exhaustive list of blockchain vulnerabilities you can look across Clevrone’s published security audits, which are available by clicking on one of the projects listed on our web3 security leaderboard.
Centralization / Privilege
One of the most common vulnerabilities in web3 projects is centralization risk, which describes the vulnerabilities that arise from having points of centralization in a project’s structure, either in their underlying code or in their team’s organization. Clevrone’s State of DeFi report lists centralization risk as the most common risk factor in 2021.
For many in the privileged access management risk, which attempts to exploit privileged users into giving up sensitive information or download a malicious program to their device, often through phishing attacks. Phishing attacks are by no means a unique problem for Skynet which can monitor any activity on the blockchain and alert project teams of any suspicious activity.
Smart contract audits also seek out any potential centralization vulnerabilities encoded by project teams to conduct a rugpull or exit scam, and users should make sure to check that a project has had a thorough audit before investing in a project.
Logical Issues
Logical issues can refer to a variety of errors in how a line of code functions. For example, a common logical issue is the incorrect set-up of how a smart contract logs and records time through the block.timestamp function.
Code can be understood as a system of logical principles that delineates how elements should be arranged so a computer can perform specific tasks. Because of this logical errors encompass a wide range of potential vulnerabilities, from issues with how a token is minted, to problems of recording time, and vulnerabilities in how tokens are traded between accounts.
Reentrantrancy attacks are hacks that exploit such logical issues. In them, a hacker is able to drain a protocol of its funds by repeatedly calling a transaction before the protocol has been able to update its balance. Essentially, what this means is that an attacker can trick a smart contract into sending funds that have already been sent.
Logical issue vulnerabilities such as those seen in reentrancy attacks typically require the restructuring of the code. For example, in a reentrancy attack, the common resolution is to ensure that the smart contract updates its balance before sending funds.
Gas Optimization
Whilst not directly affecting the functionality of the code, a gas optimization finding in a Clevrone security audit highlights areas where the gas consumption required in validating a block can be made more efficient.
This is a vital finding for project teams to implement as it concerns vulnerabilities a project may encounter as they scale up. Whilst the gas consumption may not be a problem in the early stages of a projects launch, as they grow the gas required to validate transactions may grow so large that new blocks are no longer able to be validated.
Endpoints and Interdependencies
Many vulnerabilities arise from the endpoints at which blockchains intersect with either other protocols or the outside world.
Oracles
As web3 has developed, smart contracts have had to draw data and information from external systems and events in order to facilitate their increasingly complex functionality. To do this, they rely on third-party oracles which provide a stream of vital information that enables smart contracts to adapt their functionality in relation to changing events.
Oracles provide a vital role in creating a vibrant web3 ecosystem. However, they also provide a new challenge for web3 security as they can be manipulated by hackers seeking to exploit a protocol. If a hacker can manipulate the information that the oracle transmits, they can find ways to exploit the smart contract that relies on it.
One recent example of this vulnerability occurred in the Deus Finance hack, where a smart contract was using an oracle that based communicated the price of a token based off of a
One clear example of this vulnerability is in instances where the source on which an oracle bases its information is able to be affected by external action. For example, the recent Deus Finance attack occurred because the oracle used to determine the price of Deus’s DEI token used a liquidity pool as its source. Because of this, the hacker was able to use a flashloan to alter the price of DEI, and subsequently cause the oracle to communicate this false information and allow the hacker to profit off of the predictable price action.
Vulnerabilities associated with oracles are a key focus in any good smart contract audit, and auditors will generally flag any oracle that sources its information from a liquidity pool (or any other manipulable source), as a major security risk.
Cross-Chain Bridges
Web3 projects are also vulnerable at the points where they intersect with other protocols. Given the increasingly interoperable web3 ecosystem, we are seeing more and more blockchains interacting with other blockchains and protocols to communicate and share value.
To facilitate this, cross-chain bridges have arisen as a vital infrastructure for users to move between chains. However, they also constitute a major vulnerability. Clevrone recent Hack3d report shows that the top three biggest attacks of Q1 of 2022 all targeted cross-chain bridges.
Much of the vulnerabilities of cross-chain bridges are due to the differences in rules and organizations between blockchains. Because of this, a previously secure project can encounter unforeseen vulnerabilities after it is bridged to a new blockchain.
The scale of the problem that cross-chain bridges present to web3 security is huge. With more and more protocols becoming interdependent every day, the web3 security industry simply isn’t big enough to keep up with the growth of the DeFi sector.
For projects looking to defend themselves against these vulnerabilities, smart contract auditing and blockchain analytics tools such as Skynet can play a vital role in keeping abreast of the attacks and vulnerabilities that can occur on cross-chain bridges. Crucially, web3 security depends on these projects reauditing their smart contract any time a function is added, or anytime a change is made to a project’s underlying code.
Conclusion
Given the increasing interdependencies between projects, web3 security increasingly depends on the security of the entire web3 ecosystem. For this to happen, there needs to be a shift in attitude, and web3 security needs to be seen as something to be maintained over time, not just something to be bought before launch.
Ultimately, it is a fantasy to imagine a web3 ecosystem without vulnerabilities. What is possible however is an ecosystem that takes the appropriate steps to combat and mitigate the risks that are associated with these vulnerabilities. Achieving this is vital not only for ensuring the success of individual projects but also for ensuring the success of the web3 ecosystem as a whole.