TL;DR#

On January 18, 2022, Multichain disclosed the existence of a smart contract vulnerability, which resulted in a loss of roughly 308 ETH, worth approximately $949,000. 

Introduction to Multichain#

Multichain is an infrastructure designed to support arbitrary cross-chain interactions.

Vulnerability Assessment#

The root cause of the exploit is a lack of input validation. 

Steps#

Step 1:

It was known that Dedaub reported a critical vulnerability that affected multiple token contracts. We attempt to analyze the attack transaction for the exploit in reference.

Step 2:

The Multichain Router enables users to switch between any two chains without restriction. This is done by wrapping the original token with an `anyToken` variant and using it for Multichain's internal accounting.

Step 3:

For instance, the `USD` token is encapsulated as `anyUSD`, with `USD` serving as the underlying asset for `anyUSD`. When a user moves `USD` from the BNB chain to the Arbitrum chain, the Multichain `anyUSD` contract on Arbitrum is increased by `anyUSD`, while the corresponding `anyUSD` contract on the BNB chain is decreased.

Step 4:

A vulnerable `anySwapOutUnderlyingWithPermit` function swaps an underlying token using the ERC20 `permit` function. Essentially, the `permit` function allows the user to supply a signed transaction approving a contract to spend its funds without actually sending it to the blockchain.

function anySwapOutUnderlyingWithPermit(
  address from,
  address token,
  address to,
  uint256 amount,
  uint256 deadline,
  uint8 v,
  bytes32 r,
  bytes32 s,
  uint256 toChainID
) external {
  address _underlying = AnyswapV1ERC20(token).underlying();
  IERC20(_underlying).permit(from, address(this), amount, deadline, v, r, s);
  TransferHelper.safeTransferFrom(_underlying, from, token, amount);
  AnyswapV1ERC20(token).depositVault(amount, from);
  _anySwapOut(from, token, to, amount, toChainID);
}

Step 5:

This function unwraps the underlying token from its `anyToken` wrapping, and then the `permit` function is called to approve the router’s ability to withdraw an amount from the user’s address. After verifying the transaction's signature, the amount is moved from the user's account to the wrapped token account.

Step 6:

However, the AnyswapV1ERC20 contract didn't check to verify whether the `token` parameter is indeed a Multichain `token` contract.

Step 7:

Using the IERC20 interface, the `permit` function of the underlying WETH token contract is called to approve the router's ability to withdraw an amount from the user's address after validating the transaction signature. However, the WETH contract didn't have a permit function but a fallback function named `deposit` that allowed the function's execution to continue normally.

Step 8:

Naturally, the `safeTransferFrom` function should have been invoked after the transaction signature validation. However, the signature was not verified. On top of this issue, due to an infinite approval to save gas, this vulnerability could allow anyone to transfer the WETH amount from the victim's contract to a contract they controlled.

Step 9:

This vulnerability affected six token contracts, including WETH, PERI, OMT, WBNB, MATIC, and AVAX, and the patch for the same was fixed subsequently.

Solution#

This exploit stems from the absence of appropriate validation checks and mishandling of the permit function within the contract. A key part of resolving this issue is to integrate stringent checks within the code to confirm that the supplied token parameter is indeed a Multichain token contract. By implementing necessary validation procedures and restricting access to known contract addresses, the possibility of an unauthorized function call, like the WETH's deposit, can be negated.

Given that users' only immediate defense was to revoke previous approvals, a transparent and clear communication channel with users is vital. They also developed a public `approval-revoke` API for dApps to integrate, by which users could directly revoke approvals. The team shared guidelines, tutorials, and tools to assist users in revoking all such approvals on the affected contracts. This ensured that users could take immediate action to secure their assets.

While these preventative measures are essential, they may not entirely preclude the possibility of an attack. Neptune Mutual was not available as a marketplace at the time of this incident. So the affected parties had no way to recover the stolen assets. However, it's here that solutions like ours at Neptune Mutual play an integral role. If the team associated with Multichain had established a dedicated cover pool with us prior to the exploit, the aftermath of the incident could have been notably alleviated. We offer coverage to users who have suffered a loss of funds or digital assets as a result of smart contract vulnerabilities owing to our parametric policies.

Our marketplace operates on numerous popular blockchain networks, including Ethereum, Arbitrum, and the BNB chain. This extensive reach allows us to serve a broad spectrum of DeFi users, offering protection from potential vulnerabilities and enhancing their faith in the ecosystem.

Reference Source Multichain