Swords of Damocles: 4 Potential Blockchain Vulnerabilities

Vulnerabilities are inherent to any automated system, yet the stakes are especially high in Web3 given the total value of funds under management.

Introduction

According to ancient Greece’s Cicero, a king named Dionysius offered a flatterer named Damocles an opportunity to switch places for a day, so that Damocles could enjoy the good fortunes of being a king firsthand. Damocles took the deal and was showered with exotic food and other luxuries, but he noticed that King Dionysius had hung a sword from the ceiling, held by a single strand of horsehair. 

Damocles could no longer enjoy the luxuries of being king alongside the paralyzing fear that was brought upon by the stress of being in such an exposed circumstance. That is, Damocles learned that the opulences of power came with grave responsibilities, and that a fatal destiny could arrive at any moment without warning. The same lesson Damocles learned may be applied to the Web3 stack and their applications in global finance, so that we can advance confidently and with grace instead of cowering in fear. 

As Web3 continues to mature and a slew of use cases are being rolled out for commercialization, those looking to apply the tech to their existing business models must also focus their attention on the potential risks that blockchains and digital assets may involve. This is especially true when the technology is automated and all-encompassing of an organization’s core financial infrastructure, not to mention the totality of the funds which are often allotted to smart contract protocols, mining operations, or other logistical investments related to commercial adoption.

Vulnerabilities are essentially things which can be taken advantage of by scammers to exploit computer software, hardware, or in the case of Web3, a smart contract protocol. This could be inherent to a given blockchain’s underlying infrastructure; flaws or limitations in the smart contract’s coding languages, or could accumulate over time if centralization takes hold regarding nodes or other network participants which might compromise the integrity of their assets.

Of course, the stakes of these vulnerabilities couldn’t be much higher given the tremendous value of assets being managed by Web3 protocols and the like. This high valuation makes Web3 protocols highly attractive targets for hackers, making it extremely important that projects spare no expense in eradicating blockchain vulnerabilities, and the painful losses that users incur from exploits. 

It’s helpful to familiarize oneself with some of the potential landmines to avoid stepping on in Web3, hopefully helping to inform one’s security concerns regarding Web3, even if only from a bird’s eye view. This article will therefore summarize a few of the most common vulnerabilities inherent to blockchains and the Web3 stack more broadly and various risk-mitigation strategies used by projects so the audience can more effectively evaluate their risk tolerances and participate accordingly. Nevertheless, nothing found here or elsewhere on the site should be considered financial advice in any way.

Dreaded Words in Web3: Centralization Risks

Perhaps the most common vulnerability threatening Web3 protocols has to be the risk of centralization. Ironically, centralization is one of the main issues that distributed ledger technology was originally designed to improve upon. Identifying centralization risks is not as simple as counting how many nodes are in a network and stamping it with approval, it’s important to consider a number of angles from which centralization risks could subsequently make themselves known. 

Centralization risks typically arise either by nature of a project’s underlying consensus framework, the total number or geographical distribution of nodes participating in a given network, or even the ratio of nodes running the most current version of the network’s software, among other things. This creates single points of failure which hackers can exploit to gain privileged access to a user’s wallet or a network’s liquidity pools.

For instance, what is the minimum number of entities necessary to disrupt the network’s operation? This has been dubbed the Nakamoto Coefficient by researchers, and effectively represents the number of nodes that would have to work in collusion to disrupt the operation of a given blockchain. If the number of nodes needed to take down a network becomes implausibly large, it is considered functionally secure.

Regardless of any blockchain’s inherent properties of decentralization, there are a number of subsystems which can be evaluated separately for a more granular understanding.

Similarly, the amount of hashing power controlled by a mining pool, validator node, or staking pool could also factor into a blockchain’s properties of decentralization. Slush Pool and F2Pool have both been put forth as examples of decentralization within the Bitcoin community for their size and collective hash power. 

Protocols which utilize privileged access accounts are another form of centralization risk, since hackers will inevitably attempt to exploit those privileged user accounts. Even with the most prudent operational security, the trust required for this sort of setup all but negates the benefits of decentralization enjoyed by blockchains while still taking on the risk of smart contract exploits.

If bad actors access the privileged account’s sensitive information or infect it with a malicious program, the losses can and have been catastrophic. This is often done via phishing attacks, like emails tricking the user into clicking a link or typing in part or all of a string of sensitive information. However, this is not unique to Web3 and will be left for more generalized discussions, though digital assets have certainly become common targets for phishing attacks and the like.

The implementation of Web3-specific analytics tools, audits, and whitehat campaigns can monitor for suspicious activity, though if something legitimate is actually detected, large amounts of crypto will have already been drained. The old saying, “better late than never,” comes to mind, but striving to circumvent the problem a priori via decentralization and properly aligned disincentives for on-chain mischief is preferable, if not ideal.

Exploitable Logic in a Web3 Protocol’s Code

Code is essentially the law that dictates how elements of software should arrange themselves so that the desired outcomes are completed with predictability and certainty. Anticipating misbehavior or unexpected behavior, however, is much more difficult than it may appear at first glance. Consequently, this presents the opportunity for vulnerabilities to be exploited.

Logical issues can sometimes be exploited, depending on how lines of code execute. This will always be trouble for automated systems, since hackers will be persistent threats looking for ways to exploit a system for its vulnerabilities. For example, a common logical issue is the incorrect set-up of how smart contracts timestamp blocks, the order of operations which check ledger balances for double-spending, the guardianship of users’ private keys, and so on.

Reentrancy attacks exploit the order of operations for executing smart contracts in order to withdraw more assets than they should.

Reentrancy attacks are hacks that exploit such logical issues, enabling hackers to drain a protocol of its funds by repeatedly submitting and then recalling transactions before the protocol has been able to update its balance. Essentially, this means that attackers can trick smart contracts into repeatedly sending funds that have already been sent by sending and retracting withdrawal requests unless developers reorder the operations of their code’s logic.

Following previous reentrancy attacks, Web3 developers began restructuring their own code to guard against the threat. One common resolution has been to write code functions in such a way that external listener functions happen after the blockchain’s state change, use eventual-sends, resource constraints, or pull payments. Pull payments are recommended by Open Zeppelin as they prevent recipients in a transaction from canceling a transaction, thus eliminating reentrancy complications.

Potential Third-Party Chokepoints: Oracles and Bridges

The endpoints at which blockchains intersect with either other protocols or external systems provide attractive targets for bad actors to steal funds by exploiting the system in some way. Thus, vulnerabilities associated with oracles and cross-chain bridges are key targets for Web3 security audits. 

If a blockchain is only as strong as its weakest link, then any data coming into contact with the blockchain must be fresh, pristine, and sterile. If the data that Oracles transmit to a Web3 protocol is faulty or delayed, it causes suboptimal or erroneous execution of the smart contracts. Perhaps a fitting analogy is that of hospital surgeons and their working environments, it must be perfect so that it does not infect the patient’s immune system, or otherwise create undesirable symptoms needing to be treated. 

In order to scale past their own native blockchains, hybrid smart contracts use oracles to fetch data from external systems in order to ‘know’ when their conditions have met, and to execute the agreement. To accomplish this, they rely on third-party Oracles which provide periodically updated data streams that enable smart contracts to adapt rapidly changing off-chain conditions or events.

Oracles have played a pivotal role in opening up the Web3 ecosystem to a number of practical use cases, or more efficient ways of implementing previously established business models.

However, they also provide opportunities for centralization and therefore exploitation, collusion, or manipulation. If the data that Oracles transmit to a Web3 protocol is faulty or delayed, it causes suboptimal or erroneous execution of the smart contracts.

Given the desire for seamless efficiency within our digital financial systems, a recent push towards Web3 interoperability should come as no surprise. Cross-chain bridges have been the first rudimentary response to the market’s demand for interoperability, and have served as useful models for the infrastructure which users can patronize to move value across disparate chains. Of course, they also represent a major vulnerability for several reasons.

First, they not only serve as focal points for liquidity to consolidate, but channels also take on increased counterparty risks and other security concerns. Since cross-chain bridges intersect with other blockchains through liquidity channels, their security and operation depends on at least three mutually exclusive security designs. That is, the security of Chain A, Chain B, and the bridge itself must endure security threats, with any compromise of the bridge’s integrity wreaking havoc on its interconnected chains, not to mention the shaken confidence of unaffected users.

Since transactions between Chain A and Chain B are funneled through a third-party channel, new risks are introduced to both ecosystems, making security by far the most important quality on which to focus.

Much of the vulnerabilities of cross-chain bridges are due to the differences in security parameters, smart contract languages, and consensus mechanisms between blockchains. Furthermore, the nodes of disparate chains do not keep ledgers for any other than their own native chain, and consequently take on added counterparty risks, as previously mentioned.  This could lead to a project’s reputation being harmed despite previously being seen as a secure project. 

Smart contract auditing and blockchain analytics tools can help in preventing surprise attacks, helping to shore up attractive targets for exploitation like oracles or cross-chain bridges. However, there are ways to crowdsource the intelligence needed to presage would-be attacks and secure Web3 protocols. That is to say, projects should not only perpetually re-audit their networks, but also host hackathons to look for bugs prior to going fully online, and hire whitehat hackers to sniff out any potential risks before they become steaming piles of trouble.

Black Swans, Counterparty Risks, and Regulatory Uncertainty

Sometimes attacks seem to happen out of nowhere, or originate from a flaw in one or more parties’ operational security. Other times, it is simply a matter of unmitigated counterparty risks. Of course, the ultimate sword of Damocles hanging over the head of any protocol has to be the regulatory uncertainty involved with dealing in digital assets paired with the sparse patchwork of legal protections currently in place around the world.

Flash loan attacks are also a matter of concern; hackers in the past have previously manipulated flash loan features to attack weaker protocols or bridges. With just a small initial investment, attackers could borrow thousands of dollars of ETH, deploy it towards a vulnerable bridge or liquidity pool, and extract huge sums in stolen digital assets before instantly paying back their initial ETH loans. With meticulous timing, all of this will happen in a single Ethereum transaction, leaving users scrambling to figure out what happened to their crypto.

Commissioned by the US military’s DARPA, researchers at Trail of Bits recently published a negative review of the features and vulnerabilities of blockchains. The report set out to gauge several protocols’ consensus mechanisms and node infrastructure for qualities of decentralization, and their potential for clandestine manipulation or exploitation. This has invited speculation that regulatory risks lurking in the darkness are more dangerous than ever now that crypto has reached a critical juncture on its adoption curve. This cannot be ruled out without regulatory clarity being brought forth by lawmakers around the world.

“If the Web3 stack is indeed set to power an online renaissance of human creativity, interpersonal communications and collective cooperation, and economic dynamism, then it must undergo a certain evolutionary process in order to first understand and then address the weaknesses which present themselves.”

Given the increasing composability amongst Web3 ecosystems, there needs to be a recasting of attitudes towards shoring up security vulnerabilities through open exploration and discussion of their presence. One of the benefits of the Internet and subsequent digital economy is that they are being improved via crowdsourcing at all times. However, a more robust understanding of any project’s potential vulnerabilities must be a top priority if they are to be properly mitigated, and therefore scale in due course.

Ultimately, it is unrealistic to expect any system to operate in perpetuity without vulnerabilities. What is more realistic to expect is a Web3 ecosystem that mitigates these risks by crowd-sourcing information, and using the principles of shared accountability via decentralized transparency so as to constantly evolve in a rapidly changing environment. Such is vital not only for shoring up the security guarantees of individual projects, but also for promulgating the success of the Web3 sector and adoption of digital assets more broadly.

References

1. Coghlan, J. (2022, 17 June). Inverse Finance exploited again for $1.2M in flash loan oracle attack. Cointelegraph.
2. Foxley, W. (2020, 19 Feb.). Everything you ever wanted to know about the DeFi ‘flash loan’ attack. CoinDesk. 
3. Lamesh, L. (2022, 29 May). Is there a secure future for cross-chain bridges? Cointelegraph. 
4. Sai et al. (2021, July). Taxonomy of centralization in public blockchain systems: A systematic literature review. Information Processing & Management, 58(4), 102584.
5. Shiv, J. (2022, 29 June). Pentagon warns of serious threat to global economy from blockchain vulnerabilities. Benzinga Crypto. 
6. Srinivasan, B., & Lee, L. (2017, 27 July). Quantifying decentralization. Medium.
7. Sultanik et al. (2022, June). Are blockchains decentralized? Unintended centralities in distributed ledgers. Trail of Bits.

Related Articles

• Blockchain Nodes: How to Run Your Own the Easy Way
• Does Blockchain Protect or Erode Privacy?
• Blockchain Governance: Consensus & Finality

Learn More

• What is Proof of Space and Time?
• Quantum Computing and Blockchain: What You Need to Know
• Blockchain DNS: Is Blockchain The Future of Domain Names?