Cross Chain Protocols: A Look At Recent Exploits
As Decentralized Finance continues to grow its user base, the demand for network throughput grows exponentially. This growth, though positive, puts excessive strain on blockchain networks and causes gas fees to rise beyond affordable levels for individual investors.
In response to this, a number of alternative blockchain networks and “layer 2” solutions have emerged, offering faster block times, lower gas fees, and higher throughputs to ease the strain on networks and investors’ wallets. Each of these networks take a unique approach to the hashing algorithm, consensus, and so on — leading to separate blockchain ecosystems that are largely inoperable. This inoperability problem stifles the growth and innovation potential of DeFi, and prevents the industry from reaching its full potential, revealing the need for robust cross-chain protocols to bridge the gap between ecosystems.
Over the past several months there have been several exploits of cross-chain protocols and bridges. For reference, a “bridge” is a technology that allows users to move their tokens from one blockchain network to another. Cross-chain protocols incorporate bridging technology, but with added features like the ability to transfer messages across chains. This is what we are building with the Router Protocol.
DeFi is a rapidly evolving ecosystem, and the cross-chain feature portion of that ecosystem is relatively new. As such, its recent innovations have not been battle-tested, and underlying vulnerabilities have been exploited. In this article, we’re going to take a look at several recent cross-chain exploits, decipher what went wrong, and draw lessons learned for the Router protocol.
How Cross Chain Protocols Work
In general, the current crop of cross-chain protocols helps users move funds from one blockchain to another. One of the most common ways this is done is via wrapping tokens. When a user deposits funds into the protocol, the bridge contract “locks” the funds on the source blockchain and mints a “wrapped” version of that asset on the destination chain. When funds are moved back, the wrapped version is burned and the original collateral is unlocked on the original chain.
This will be important to keep in mind as we explore what happened in the recent exploits.
Inside the Attack: pNetwork
The pNetwork is a cross-chain protocol that allows users to deposit native BTC and mint tokenized BTC for use on another blockchain. In the case of this attack, the affected bridge minted BTC on the Binance Smart Chain (BSC) network. An attack occurred on September 19, 2021, that resulted in the theft of 277 BTC (worth over $13M at the time of the attack).
The pNetwork bridge had code that was used to process withdrawal request event logs, unwrapping BTC on the Bitcoin blockchain when pBTC was redeemed on BSC. The hack occurred because the code assumed that all of these requests would come from pNetwork’s own contracts. This assumption was incorrect. The attacker was able to spoof requests on their own smart contract and send these requests to be processed, which were erroneously approved. The failure to properly validate redemption requests enabled the attacker to withdraw 277 BTC worth over $12 million.
Inside the Attack: Synapse
On November 7, Synapse Bridge — another cross-chain protocol — narrowly avoided a multi-million dollar exploit that would have drained the platform of funds. Its network of validators was able to detect suspicious activity and reject the transaction that would have bridged funds from Polygon to Avalanche and in doing so, saved $8 million.
The protocol utilized forked code from Saddle Finance for its AMM functionality. In this case, the attacker utilized a flash loan to manipulate a price discrepancy between the “swap” and “swapUnderlying” commands in the codebase, exploiting the slippage between the two.
The underlying danger here is that Synapse used third-party code for its core features. Without properly auditing these features, doing so can prove to be excessively risky.
Inside the Attack: Polynetwork
On August 10, headlines were made after a hacker nearly got away with an eye-popping $600 million sum, making it the largest DeFi hack to date. The attack was on the PolyNetwork — a cross-chain protocol that powered swaps from one blockchain to another.
The protocol functioned with several interacting smart contracts. The attacker was able to manipulate the relationships between these contracts in order to claim the “keeper” role (a role that controls custody of funds in the contracts) to themself. Specifically, a function called “PutCurEpochConPubKeyBytes” in the “EthCrossChainData” contract was used to update the keeper role through accessing a different function called, “verifyHeaderAndExecuteTx”. By sending a specific command to the latter function, the hacker was able to claim the keeper role. Once they took the keeper role, they were able to move funds and execute transactions at will.
Knowing all of the possible interactions between functions and contracts in your code is critical. A function may be labeled as “private” — but if this function is called by a separate external or public function, it may still be accessible to savvy hackers. This attack was possible because a function could change the keeper role.
The hacker later returned the funds to PolyNetwork.
Inside the Attack: THORchain
On July 15, THORchain suffered an exploit resulting in the loss of $7.6M worth of ETH tokens on its network. THORchain is a decentralized protocol that powers cross-chain swaps. The protocol has a built-in bridge called Bifrost, which was manipulated to process fake assets using an override function. This hack was repeated numerous times on multiple pools. Even though THORchain was quick to react and pause functionality, the damage was already done and millions of dollars were lost.
Lessons Learned
It’s clear that code must be well-written, thoroughly tested, and peer-reviewed before going live on mainnet. Utilizing third-party code presents an additional risk, as it can have unknown effects and interactions with other sections of a protocol.
This is why Router Protocol has taken a very security-oriented approach to development. We want to make sure that every box is checked, every i dotted and every t crossed before deploying our product onto the mainnet. We have conducted audits with multiple reputable firms, and have done bug bounties at ImmuneFi to ensure that our code has been tested from every possible angle. A protocol is only as good as its security, and we have made every effort to meet the highest bar of security standards. Zero exploits from day one is the goal.
Of course, no one can guarantee 100% secure contracts in Web3, as each new innovation opens up new possibilities for vulnerabilities that have not been seen before. Furthermore, Router Protocol will launch with a proxy contract implementation, meaning that contracts will be upgradable and any issues will be patchable in real-time.
About Router Protocol
Router Protocol is building a suite of cross-chain liquidity infra primitives that aims to seamlessly provide bridging infrastructure between current and emerging Layer 1 and Layer 2 blockchain solutions.