TLDR: Sayfer’s researchers team found a new potential vulnerability in Connext’s cross-chain bridge’s smart contracts. It appears that their remuneration system for routers (users that make the transfers possible on sending and receiving chains) is sensitive to front-running. Indeed, we found more than 1000 MEV transactions on the Ethereum blockchain only, for a total of $70k of stolen fees.

Take me to the technical details.

Web3 is an extraordinary and revolutionary vision for the World Wide Web that offers us many new possibilities. However, like everything new, it comes with good and bad sides and the famous war between white and black hats does not spare web3. Undoubtedly, web3 became the new playground for hackers.

As a security company, we often find vulnerabilities that can be used by hackers, and in this article, we are going to present to you one of these, Connext’s fees front-run vulnerability.

What is Connext?

Connext is a platform based on the Ethereum blockchain that allows users to conduct transactions across different Ethereum-compatible networks. Connext achieves its function without the use of any off-chain validator. It works through the Noncustodial Xchain Transfer Protocol (NXTP) for its cross-chain transfers.

Connext Architecture

NXTP is a simple protocol for fully noncustodial cross-chain transfers and contract calls. The key takeaway with this protocol is that all the information needed for both parties is available on-chain. 

Every time someone moves money from one blockchain to another three steps occur:

1. Route selection: Users select the chains and assets and start an auction with the transfer information. Routers bid to complete the transfer within a time/price range.
2. Prepare: Users send a transaction to the NXTP contracts on the sending chain. Upon seeing the contract’s event, routers lock up liquidity on the receiving chain.
3. Fulfill: Users provide a signature to unlock funds on the receiving chain, and routers use the revealed signature to claim the liquidity on the sending chain.

What is Front-Running?

Front-running is the act of placing a transaction in a queue with the knowledge of a future transaction. Front-running on a blockchain platform normally happens when a miner, who has access to information on pending transactions, places an order that would earn him or her a profit based on a pending trade. For instance, on the Ethereum blockchain, front-running can occur when bots are able to quote a higher gas price than a pending trade, thus, hastening its processing. This is mainly happening for arbitrage reasons.

Mempool is a set of Ethereum transactions that have been broadcasted to the network and are waiting to be packaged into blocks. It is the premise for the implementation of front-running.

The front-running bot analyzes and finds targets that can be attacked by continuously scanning pending transactions in the Mempool.

Maximal (or Miner) Extractable Value (MEV) refers to the profits miners and other entities can harvest by exploiting the transparency of the blockchain to front-run profitable transactions before they are confirmed.

The Technical Details

Routers have two sources of income: auction fees and relayer submission fees.

As explained on Connext Academy:

Auction Fees

Whenever a user broadcasts to the Connext network by signaling their intention of doing a cross-chain transfer, routers can respond with sealed bids. The underlying process for this is described in more detail here: Route Auction. The bids include the routers’ commitment to fulfill the transaction within a predefined time and price range. Connext then matches the user to the cheapest bid.

Once the router detects an event that contains their signed bid, the router submits the transaction. To incentivize the router to complete the transaction, the amount locked on the receiving chain is reduced by the auction fee, which the router receives.

Relayer Submission Fees

The user who initiated the broadcast signs a message once the router has prepared the transaction.

The message is sent to a relayer who earns a fee for submission. The relayer is typically another router. A relayer is used here to allow users to submit transactions with arbitrary calldata on the receiving chain without needing gas to do so. The router then submits the same signed message and completes the transaction on the sender side, unlocking the original amount.

During our research, we found that the fulfill function in the TransactionManager.sol contract lacks a particular authentication mechanism, enabling a MEV attacker to front-run a relayer’s transaction and steal his relayerFees.

MEV attackers can look for pending transactions in the Mempool that call the fulfill function in the TransactionManager contract. They can then perform a displacement attack by submitting the same transaction to the Mempool but with a higher gas fee. This bypasses the authentication measures currently in place, as the attacker simply copies the transaction, including its signature.

The vulnerability behind this attack originates in a logic error in the TransactionManager.sol:842.

LibAsset.transferAsset(txData.receivingAssetId, payable(msg.sender), relayerFee);

The relayerFee is sent to the message sender, without any verification. Whoever calls the fulfill function first gets the fee.

If the frontrunner transaction successfully outstrips the original transaction sent by the relayer, that legitimate transaction is then reverted with a ‘#F:019’ error code, since it would be the second time it is being fulfilled.

The Impact

The financial impact here is critical as this is an economic attack that targets one of the components of the NXTP protocol – the relayer (It is important to note that user funds are currently not at risk). By using MEV attacks, malicious attackers can potentially steal the relayer’s fees, thereby impeding the relayer’s incentive to fulfill the transaction.

Without profitable enough fees, relayers may stop providing their service, which in time, might prevent the NXTP protocol from operating.

This scenario isn’t theoretical at all. During our MEV research, we found this attack is being actively exploited by sophisticated general front-runner bots families we are currently tracking. These bots cause the loss of a tremendous amount of funds across the Ethereum network. 

Since its deployment, we’ve found more than a thousand successful attacks on the TransactionManager.sol contract. One such example includes:

Attacker transaction:

1. https://etherscan.io/tx/0xfeedceaa9be3c8bffc1519ec612d2797d63de63bb22aced0e9eb2635d57f2985
2. https://ethtx.info/mainnet/0xfeedceaa9be3c8bffc1519ec612d2797d63de63bb22aced0e9eb2635d57f2985/

Victim transaction:

1. https://etherscan.io/tx/0x08b17148c1239a80d7ceead53e888b88fadb0239446b90cf280c0e9cd7b42dff
2. https://ethtx.info/mainnet/0x08b17148c1239a80d7ceead53e888b88fadb0239446b90cf280c0e9cd7b42dff/

We can tell that both transactions are related to the same cross-chain transfer by checking the signature parameter value in the transaction data. Since the signatures are the same in our example above, we know that both senders are trying to get the relayerFee, so one of them is trying to front-run the other. To identify the bot, we just need to compare the cost of the transactions, the most expensive being the attacker’s.

Our team estimated the total amount of taken fees, on the Ethereum blockchain only, is at approximately $70k.

Reporting

We have reported this vulnerability to Connext via the bug bounty platform Immunefi. After a long exchange, Connext told us that this was not a vulnerability and that “this is by design”.

Here is their last reply:

We believe smart contracts may still not be safe enough for mainstream users, and we think that stories like this case are the cause for that. We believe crypto will change the world (If it hasn’t already). This is why we see it as our responsibility to inform the world about how some protocols consider their cyber security responsibilities.