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 CertiK’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. CertiK’s State of DeFi report lists centralization risk as the most common risk factor in 2021.

For many in the web3 security space, it is frustrating to see so many projects fall prey to centralization risk as the vulnerabilities inherent in centralization are one of the main issues that the decentralized nature of blockchain technology is designed to combat.

Centralization in web3 projects often creates a vulnerability by creating a single point of failure which hackers can exploit to gain access to an entire network.

Within this, a common form of centralization risk is 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 web3 security but are as old as the internet itself. Because of this, like centralization risk they are one of the problems passed down from web2 that web3 is trying to resolve. With the evolution or bridge from web2 to web3 - currently referred to as web2.5 - web2 style attacks are bleeding into web3 eventual exploits. A good example is that of NFTs which rely on market-places and social media to grow its community. So, often in attacks that target NFTs, a hackers journey starts with a web2 phishing attack, but eventually moves to a token fund exploit.

Another way that centralization can be exploited is by the projects themselves, as teams behind bad-faith projects can code malicious backdoors into their code that allow them to drain a project of its funds after having raised enough investment from their communities. In other instances, a project team can simply leave a project by slowly dumping their tokens whilst keeping up a pretense of being behind the project.

So long as there is centralization in web3, there will be centralization risk. Whilst it is likely that some features of centralization will always be present in web3, there are several measures that projects can take to protect against this vulnerability.

One key way of doing this is to introduce aspects of decentralization into vulnerable areas. For example, projects should require two or more users to authenticate the identity of any privileged user any time they try to access the network. Multisig in wallets provides schemes where 2 of 3 or 3 of 5 signatures are required for successful authentication.

Projects should implement blockchain analytics tools such as CertiK’s 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 CertiK 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. CertiK’s 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.

‍