Multichain Bridge was exploited for more than $126M.

I believe that the hacker initially compromised the Multichain MPC network, then exploited the vulnerability in the Multichain MPC Bridge Contracts.

Since it all happened with ease, it raises suspicion whether someone from the inside was involved. (Unlikely, but still, I wonder)

This is how it happened (Refer to the visual below):

The hacker targeted the Multichain MPC network, a distributed network of nodes that process cross-chain requests using a threshold signature scheme (TSS) based on secure multi-party computation (MPC). This means that the cryptographic keys that control the bridge transactions are split into multiple shards and distributed among the nodes, and a threshold number of nodes need to agree to sign a transaction.

The attacker managed to compromise some of the nodes or key shards either by 

• hacking into them (likely),
• bribing or coercing the node operators (unlikely), or
• conspiring with some insiders (can't rule this out).

Then, the attacker would have found a way to bypass the security checks in the Multichain MPC bridge contracts.

According to the Multichain documentation, the bridge process involves four steps:

• The user locks their assets on the source chain by sending them to a bridge contract, which is controlled by a secure multi-party computation (SMPC) address. This address is generated by a network of nodes using a threshold signature scheme (TSS) to share the cryptographic keys controlling bridge transactions. The user also specifies the destination chain and address where they want to receive the wrapped assets.
• The bridge contract emits a lock event that contains information about the locked assets, such as the amount, the token type, and the destination chain and address. This event is detected by an oracle that relays it to the destination chain.
• The oracle calls a mint function on the destination chain, which triggers another bridge contract to mint the equivalent amount of wrapped assets and send them to the user’s destination address. The wrapped asset token contract is a superset of the standard ERC20 contract, which only allows the SMPC address to mint assets.
• The destination bridge contract emits a mint event that contains information about the minted assets, such as the amount, the token type, and the source chain and address. This event is detected by another oracle that relays it back to the source chain.

The security checks that are supposed to prevent unauthorized withdrawals from the bridge contracts are:

• The verification of the lock event and mint event by the oracles, which ensures that only valid cross-chain requests are processed, and no double-spending occurs.
• The verification of the mint function by the destination bridge contract, which ensures that only the SMPC address can mint wrapped assets, and no inflation occurs.
• The verification of the signature and nonce parameters by the source bridge contract, which ensures that only authorized users can approve the spending of their tokens by the bridge contract and no replay attacks occur.

The attacker could have bypassed these security checks by exploiting a vulnerability in any of these components.

The attacker could have exploited a

• bug, logic, or a design flaw in the contract code of the source or destination bridge contracts, which allowed them to manipulate or bypass some of the verification steps or parameters.
• vulnerability in the Oracle system, which allowed them to tamper with or forge some lock or mint events or relay them to incorrect chains or addresses.
• vulnerability in the SMPC or TSS protocols, which allowed them to compromise some of the nodes or key shards that control the bridge transactions.

Some of the vulnerabilities that could have been exploited on the Multichain MPC bridge contracts are:

• A vulnerability in the on-chain and off-chain validation of the bridge transactions, which could have allowed the hacker to bypass or manipulate some of the security checks, such as the lock and mint events, the signature and nonce parameters, or the asset lockup and minting on the other chains.
• A vulnerability in the handling of native tokens on the bridge contracts could have allowed the hacker to withdraw native tokens from the bridge contracts without locking or burning them on the other chains or to mint native tokens on the other chains without locking or burning them on Ethereum.
• A vulnerability in the configuration of the bridge contracts or the MPC network could have allowed the hacker to exploit some of the settings or parameters of the bridge transactions, such as the fees, limits, oracle addresses, or node addresses.

As for the stolen funds, as I write this:

• 27,653,475 $USDC were transferred to 0x027f1571aca57354223276722dc7b572a5b05cd8.
• 2 $USDT, and 30,138,618 $USDC were transferred to 0xefeef8e968a0db92781ac7b3b7c821909ef10c88.
• 1023 $WBTC were transferred to 0x622e5f32e9ed5318d3a05ee2932fd3e118347ba0.
• 7214 $ETH were transferred to 0x418ed2554c010a0c63024d1da3a93b4dc26e5bb7.
• 502,400 $TUSD, 1,492,821 $USDT, 4,177,590 $DAI, 1,361,886 $CRV, 491,656 $LINK, 910,654 $UNIDX, 9,674,426 $WOO, 1,296,990 $ICE, 134 $YFI were transferred to 0x9d5765ae1c95c21d4cc3b1d5bba71bad3b012b68.
• 5,496,936 $USDC, 1,042,195 $USDT, 780,080 $DAI, 6 $WBTC were transferred to 0x48bead89e696ee93b04913cb0006f35adb844537.
• 4,830,466 4USDC, 1,042,195 $USDT, 780,080 $DAI, 6 $WBTC (Moonriver Bridge) and 666.470 $USDC (Dogecoin Bridge) were transferred to 0x48BeAD89696Ee93B04913cB000635adB844537.

As of now, the Multichain team has not confirmed or denied this explanation, and they are still working on finding the root cause and solution.

Thank you for reading, and follow me here and on Twitter for more regular post updates.

I’d also appreciate it if you shared this with your friends, who would enjoy reading this.

You can find my other research & investment thesis here: https://bit.ly/3CjMvoA

If you find this analysis useful, please consider donating to 0xd95d4b14dcfa941bf916255b3624c0bfb22166c8.

Thank you.