MultiChain Infinite Approvals Critical Vulnerability

Notice: This page is a new case study and some aspects have not been fully researched. Some sections may be incomplete or reflect inaccuracies present in initial sources. Please check the References at the bottom for further information and perform your own additional assessment. Please feel free to contribute by adding any missing information or sources you come across. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!

MultiChain

MultiChain (formerly AnySwap) is one of the largest decentralized token swap services around. As part of the trading process, users would grant unlimited approvals to the smart contract. Unfortunately, being human, the developers of the original AnySwap smart contract made a mistake which resulted in risk to tokens. After publicly announcing and later explaining the vulnerability in detail, people's funds started to be stolen. Many users were fast to remove the permissions before hackers could take their funds, however others were too slow and lost their funds. Some have even still kept the permissions active, and are likely to be subject to future loss of any funds they bring into their wallet in the future.

While significant funds have been recovered by white hackers and some centralized exchanges, it appears that attackers have been exploiting the vulnerability to a high degree of success. In total, slightly less than half of the $6m worth of ethereum has been recovered. Much of the remainder has been sent to TornadoCash to be anonymized.

This is a global/international case not involving a specific country.

About MultiChain

"The Ultimate Router for Web3.0." "Multichain was born as Anyswap on the 20th July 2020 to service the clear needs of different and diverse blockchains to communicate with each other. Each blockchain has its own unique services that it provides, its own community and its own development ecosystem. For our industry to reach the next level for consumers, we need a fast, secure, inexpensive and reliable way to exchange value, data and exercise control between the chains."

"The solutions developed by Multichain allow almost all blockchains to inter-operate. There is no restriction to Ethereum like chains (e.g. Binance Smart Chain), or different Layer 2 chains requiring finality to Ethereum (e.g. Polygon), or a network of Parachains (e.g. Moonbeam in the PolkaDot system), or Bitcoin types of chain (e.g. Litecoin), or COSMOS chains (e.g. Terra). These are either now all integrated, or on course for integration. With support for all ECDSA and EdDSA encrypted chains, Multichain is almost universally applicable as an interoperable layer."

The Reality

TBD

"A critical vulnerability that affected 6 tokens (WETH, PERI, OMT, WBNB, MATIC, AVAX) has been reported and fixed. All assets on both V2 Bridge and V3 Router are safe, and cross-chain transactions can be done safely." "The liquidity for these 6 tokens is fixed now. All assets on both V2 Bridge and V3 Router are safe and all cross-chain transactions can be done safely as usual."

What Happened

The specific events of the loss and how it came about. What actually happened to cause the loss and some of the events leading up to it.

Key Event Timeline - MultiChain Infinite Approvals Critical Vulnerability

Date	Event	Description
January 17th, 2022 9:14:00 AM MST	Main Event	Expand this into a brief description of what happened and the impact. If multiple lines are necessary, add them here.
January 23rd, 2022 11:15:00 PM MST	Phishing Warning	"All users, make sure you are connected to http://app.multichain.org before doing any cross-chain transactions. We have seen reports of phishing websites using the same exact UI as ours again! Also, any website asking for your Seed Phrase is a fraudulent link! Be careful!"
January 24th, 2022 7:46:00 AM MST	Warning Posted On Twitter	Multichain posts a warning and requests all users to revoke their approvals immediately. Otherwise, "the six tokens in your wallet are always at risk".

Technical Details

"A critical vulnerability that affected 6 tokens (WETH, PERI, OMT, WBNB, MATIC, AVAX) has been reported and fixed. All assets on both V2 Bridge and V3 Router are safe, and cross-chain transactions can be done safely." "The liquidity for these 6 tokens is fixed now. All assets on both V2 Bridge and V3 Router are safe and all cross-chain transactions can be done safely as usual."

"Only users who had approved the 6 tokens (WETH, PERI, OMT, WBNB, MATIC, AVAX) on Router are required to revoke approvals. For other people, no action is needed." "If you have approved any of the contracts of the 6 tokens (WETH, PERI, OMT, WBNB, MATIC, AVAX), you need to revoke approval(s) and the options will appear according to your past activity. For example, if you had given contract approvals of WBNB and AVAX, you will see both BSC and AVAX buttons."

"Callers should not rely on permit reverting for arbitrary tokens. The call token.permit(...) never reverts for tokens that do not implement permit have a (non-reverting) fallback function. Most notably, WETH — the ERC-20 representation of ETH — is one such token."

"We call this pattern a phantom function— e.g., we say “WETH has a phantom permit” or “permit is a phantom function for the WETH contract”. A contract with a phantom function does not really define the function but accepts any call to it without reverting. On Ethereum, other high-valuation tokens with a phantom permit are BNB and HEX. Native-equivalent tokens on other chains (e.g., WBNB, WAVAX) are likely to also exhibit a phantom permit."

"In the case of AnySwap/MultiChain code, the simplest vulnerable contract" "means that the regular deposit path (function deposit) transfers money from the external caller (msg.sender) to this contract, which needs to have been approved as a spender. This deposit action is always safe, but it lulls clients into a false sense of security: they approve the contract to transfer their money, because they are certain that it will only happen when they initiate the call, i.e., they are the msg.sender."

"The second path to depositing funds, function depositWithPermit, however, allows depositing funds belonging to someone else (target), as long as the permit call succeeds." "The problem in this case is that the WETH token has a phantom permit, so the call to it is a non-failing no-op. Still, this should be fine, right? How can a no-op hurt? The permit did not take place, so no approval/allowance to spend the target’s money should exist."

"All WETH of all such clients can be stolen, by a mere depositWithPermit followed by a withdraw call. (To avoid front-running, an attacker might split these two into different transactions, so that the gain is not immediately apparent.)" "Two separate vulnerabilities are based on the above attack vector. The first was outlined above. The second, on AnySwap router contracts, is a little harder to exploit — requires impersonating a token of a specific kind. We do not illustrate in detail because the purpose of this quick writeup is to inform the community of the attack vector, rather than to illustrate the specifics of an attack."

Total Amount Lost

The total amount lost has been estimated at $5,981,000 USD.

Immediate Reactions

"Although we have found other instances of the vulnerable code patterns, the contracts currently have very low or zero approvals on Ethereum." "[O]ur best indicators suggest that there is no great exposure outside the AnySwap/Multichain contracts."

"If you have ever approved any of these 6 tokens, [please] log in asap to revoke the approvals, otherwise, your assets are at risk." "Please do not transfer any of these 6 tokens to your wallet before revoking the approvals. The risk will be eliminated instantly upon revoking approvals."

"Many thanks to security firm @dedaub for reporting this vulnerability." They also "scanned the entire Ethereum chain for instances of this threat and warned other projects when applicable." "We have been awarded Multichain’s maximum published bug bounty of $1M for each of the two vulnerability disclosures. (Thank you for the generous recognition of this extraordinary threat!)"

"Current main attacker, already accumulated ~$180K." "Top 10 victims of the #Anyswap #MultiChain hack (out of at least 330) Biggest individual loss: ~$170K (54 Weth)." "Stolen funds are currently held at this address, more than 450 Ether (~$1.34m)"

Announcement of Vulnerability on Twitter

Many thanks for the vulnerability reporting @Dedaub

Attention Everyone

Pls go to http://app.multichain.org/#/approvals to revoke immediately, otherwise, the six tokens in your wallet are always at risk. The risk will be eliminated upon revoking the approvals

Ultimate Outcome

"As of Jan 28, 3735 addresses have revoked as instructed (total affected addresses:7962), while 4227 addresses still need to take action. 941 ETH ha[d] been exploited. 901 ETH has been saved by the joint efforts of whitehats and Multichain."

"As of Feb 7, 4504 addresses ha[d] revoked as instructed (total affected addresses 7962). The remaining 3458 address holders still need to take action immediately. A total of 1862ETH ha[d] been exploited (1842ETH Feb 6), from which 901ETH has been protected."

"According to the tracking data, one whitehat hacker has returned 259 ETH."

"Shout out to @0xlosha for protecting 125AVAX, we will return to users accordingly. Many thanks."

"Tether has frozen an Ethereum hacker address holding over $715,000 worth of USDT. This address was involved with Multichain exploitation with a total of 45.4527 ETH. We are working with Tether to trace more exploiter addresses."

"Here's a shout out to @BlockSecTeam for being a part of the battle against hackers from the beginning and protecting 18.89 ETH. Many thanks!"

"I've had a ticket open since Jan 18. Can provide id if you want. They keep saying to wait for an announcement for reimbursement of funds. So when will this process start? When will multichain start returning the funds."

A bounty of $1,000,000 USD was paid for the discovery.

Total Amount Recovered

The total amount recovered has been estimated at $2,894,000 USD.

What funds were recovered? What funds were reimbursed for those affected users?

Ongoing Developments

"Dev team keeps 24/7 tracking the hack and monitoring the affected users’ assets and all the other funds. Alert announcements and updates on all social channels. Reach and notify all the affected users through different platforms. Send onchain alert message to affected addresses. Alert banners go live at Etherscan, Polygonscan, BSCscan. 24/7 support service at our Help Center."

"The reported vulnerability remains critical for the old users who had approved the six tokens (WETH, PERI, OMT, WBNB, MATIC, AVAX) in their addresses. We strongly urge these users to revoke their approvals immediately before sending any of these 6 tokens to their wallets again." "Otherwise, these six tokens in your address is always at risk, risk will be eliminated instantly upon revoking approvals."

General Prevention Policies

Turning everyone's wallet into a hot wallet is not a good design from a security standpoint. It is far more secure to keep funds stored offline with no smart contract permissions granted, and most certainly not unlimited permissions. Users could avoid this problem by immediately revoking permissions after trading, or keeping funds they aren't actively trading in a separate cold wallet.

When a vulnerability is found, it makes far more sense to whitehack the funds, than to hope that users will be able to find the information and remove their funds faster than hackers will. Platforms should fund a treasury to be able to assist users from events like this, which would be more capital efficient if multiple platforms create a fund together.

Individual Prevention Policies

It is important to limit your risk by only keeping the assets you need for a swap transaction and removing permissions after you are done.

Avoid the use of smart contracts unless necessary. Minimize the level of exposure by removing or withdrawing assets whenever possible. Aim to choose smart contracts which have obtained third party security audits, preferably having been audited by at least three separate reputable firms. Pay attention to the audit reports, which smart contracts are covered, and whether the smart contract has been upgraded or modified since the report. Ensure that any administrative functions with the ability to remove funds from the smart contract are under the authority of a multi-signature wallet which is controlled by at least three separate and reputable entities.

Store the majority of funds offline. By offline, it means that the private key and/or seed phrase is exclusively held by you and not connected to any networked device. Examples of offline storage include paper wallets (seed phrase or key written down and deleted from all electronic media), hardware wallets, steel wallet devices, etc...

For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.

Platform Prevention Policies

Platforms can reduce the likelihood of exploits by ensuring greater validation of smart contracts, minimize the risk by reducing the requested permissions, and improve handling of loss situations with better announcements and an industry insurance fund.

Prevention Of The Exploit

The exploit would likely have been caught with third party validation from multiple smart contract auditing services.

All aspects of any platform should undergo a regular validation/inspection by experts. This validation should include a security audit of any smart contracts, reporting any risks to the backing (of any customer assets, ensuring treasuries or minting functions are properly secured under the control of a multi-signature wallet, and finding any inadequacies in the level of training or integrity of the team. The recommended interval is twice prior to launch or significant system upgrade, once after 3 months, and every 6 months thereafter. It is recommended that the third party performing the inspection not be repeated within a 14 month period.

Dealing With The Exploit

Special care needs to be taken to ensure that user funds are properly rescued from any exploit and to give an opportunity for white hacking to rescue the funds prior to a free for all.

Work with other industry platforms to set up a multi-signature wallet with private keys held separately by delegate signatories from seven prominent platforms and services within the industry. Establish requirements for contributions by all platforms and services, designed to be affordable for small platforms yet large enough to cover anticipated breach events. Any breach event can be brought forth by a member platform or a petition of 100 signatures for consideration by the delegate signatories. A vote of 4 or more delegate signatures is required to release any funds, which could partially or fully restore lost funds based on their assessment.

For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.

Regulatory Prevention Policies

The risk could be reduced by educating users to give less permissions or automatically revoke permissions after they are done, improving the security of platforms through third party validation, and setting up an industry insurance fund to help compensate victims.

Decreasing Unlimited Approvals

Create a standard tutorial and quiz for all new cryptocurrency participants, which is required to be completed once per participant. This tutorial and quiz should cover the basics of proper seed phrase protection, strong password generation, secure two-factor authentication, common fraud schemes, how to detect and guard against phishing attacks, how ponzi schemes work, as well as other risks which are unique to the cryptocurrency space.

Improving Platform Security

All platforms should undergo published security and risk assessments by independent third parties. Two assessments are required at founding or major upgrade, one after 3 months, and one every 6 months thereafter. The third parties must not repeat within the past 14 months. A risk assessment needs to include what assets back customer deposits and the risk of default from any third parties being lent to. The security assessment must include ensuring a proper multi-signature wallet, and that all signatories are properly trained. Assessments must be performed on social media, databases, and DNS security.

Handling Exploit Cases

Set up a multi-signature wallet with private keys held separately by delegate signatories from seven prominent platforms and services within the industry. Establish requirements for contributions by all platforms and services within the country, designed to be affordable for small platforms yet large enough to cover anticipated breach events. Any breach event can be brought forth by a member platform or a petition of 100 signatures for consideration by the delegate signatories. A vote of 4 or more delegate signatures is required to release any funds, which could partially or fully restore lost funds based on their assessment.

For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.