$0 USD

AUGUST 2021

GLOBAL

SUSHISWAP

DESCRIPTION OF EVENTS

"Be a DeFi Chef with Sushi. Swap, earn, stack yields, lend, borrow, leverage all on one decentralized, community driven platform. Welcome home to DeFi."

 

"Sushi is a DeFi protocol that is completely community-driven, serving up delicious interest for your held crypto assets." "On Sushi, you can take advantage of passive-income providing DeFi tools such as liquidity providing, yield farming and staking. Furthermore, due to the decentralized nature of being an AMM (Automated Market Maker), Sushi has fewer hurdles to execute your cryptocurrency trades and all fees are paid to the users who provided liquidity, just as it should be!"

 

"[A] pseudonymous developer who goes by “Chef Nomi” launched the SushiSwap protocol in late August [2020], and it was quickly cast as a “vampire protocol” because its inherent design intended to siphon away liquidity from a competing trading platform, Uniswap."

 

“… we have designed SushiSwap as the next step forward in the Uniswap protocol design. Taking Uniswap’s elegant core design, we’ve added community-oriented features that we believe help improve the design of the protocol, as well as provide further benefits to the actors involved.”

 

"Minimal Initial SushiSwap Offering" "MISO is a suite of open-source smart contracts created to ease the process of launching a new project on the SushiSwap exchange. MISO aims to drive new capital and trade to the exchange by increasing the attractiveness of SushiSwap as a place for token creators and communities to launch new project tokens. We aim to create a launchpad for both technical and non-technical project founders, that will allow communities and projects access to all the options they need for a secure and successful deployment to the SushiSwap exchange."

 

"MISO MARKET - Sell your tokens via Crowdsale, IBCO or Dutch auction." "List on SushiSwap - We take some of the tokens you made, and some of the money you made selling them, and launch them on the SushiSwap exchange." "Our Fermentation selections make the locking away of tokens before and during a launch simple and manageable, working seamlessly with our Markets, Farms and Liquidity Migration contracts." "Recipes combine one or many ingredients to create and launch your own token. We have carefully selected a few of the more interesting combinations as a way to help you get started. You can always build your own MISO from any of our ingredients."

 

"The DutchAuction smart contract inherits the BoringBatchable utility contract that allows callers to batch different calls together." "BoringBatchable is a mixin library which is designed to easily introduce batch calls to any contract which imports it. It does this by performing a delegatecall on the current contract for each call data provided in the input."

 

"MISO had gone through 3 audits and a few independent reviews."

 

"initMarket function had no access controls, which was extremely concerning. Furthermore, the initAuction function it called also contained no access control checks."

 

"There is a commitEth function in the auction contract that uses msg.value to know the amount of ETH commited by the user. If the user commits more ETH than the contract’s capacity, the contract refunds the extra ETH. This function is fine on its own but becomes a vulnerability when combined with the batch function from BoringBatachable."

 

"Inside a delegatecall, msg.sender and msg.value are persisted. This meant that I should be able to batch multiple calls to commitEth and reuse my msg.value across every commitment, allowing me to bid in the auction for free."

 

"[A] refund would be issued for any ETH sent which went over the auction’s hard cap. This applied even once the hard cap was hit, meaning that instead of rejecting the transaction altogether, the contract would simply refund all of your ETH instead."

 

"The batch function works by making multiple DELEGATECALLs to itself (the Auction contract). An interesting aspect about DELEGATECALL is that they use the same global context as the parent call so every DELEGATECALL has the same msg.value that the parent call had. This means that you can pass 1 ETH to the batch function and call the commitEth function a hundred times with 1 ETH as msg.value, every time."

 

"Since the commitEth function uses msg.value to know the amount committed, it will get tricked into thinking that the user committed 100 ETH (1*100) instead of the actual amount (1 ETH). If the contract had only 1 ETH of capacity left, it will refund the remaining 99 ETH to the user."

 

"In summary, the user can put in 1 ETH but get out 99 ETH as refund. The numbers can be scaled up or down."

 

"Since a large amount of funds were at risk (~$350 million), we decided to keep the inner circle small and started the war room / incident response bridge call. The group was split into two teams, the first team’s job was to analyze our options and do a white hack if need be. The other team was doing the boring yet necessary work of comms, waking up people who controlled relevant keys, and stuff like that."

 

"After some quick debate, we decided that" "Rescu[ing] the funds by purchasing the remaining allocation and immediately finalizing the auction" "was the cleanest approach." "We decided that it would be cleanest to take a flash loan, purchase up to the hard cap, finalize the auction, then repay the flash loan using proceeds from the auction itself. This would require no upfront capital, which was very nice."

 

"After some more thinking, I realized that we could use the points list to verify that the auction contract had enough ETH to match the commitments being made. In other words, if someone tried to exploit this bug, then there would be more commitments than there was ETH. We could easily detect this and revert the transaction. Mudit and Keno began working on writing a test to verify."

 

"While we are doing the final checks, we realized that the auction had naturally sold out. Someone bought in at the last moment. We no longer needed the flash loan to buy out the auction. All we had to do now is to finalize the auction so that the vulnerability is mitigated and the funds are taken out from the auction contract to a secure wallet. We already had the folks with relevant permissions on a call so we managed to finalize the auction immediately. Funds were now safe, the storm had passed." "No user action is required. No funds have been lost."

 

"The past few hours feel like a blur, almost as though no time has passed at all. I had gone from encounter to discovery in a little over half an hour, disclosure in 20 minutes, war room in another 30, and a fix in three hours. All in all, it took only five hours to protect 350 million USD from falling into the wrong hands."

 

"First, using msg.value in complex systems is hard. It’s a global variable that you can’t change and persists across delegate calls. If you use msg.value to check that payment was received, you absolutely cannot place that logic in a loop. As a codebase grows in complexity, it’s easy to lose track of where that happens and accidentally loop something in the wrong place. Although wrapping and unwrapping of ETH is annoying and introduces extra steps, the unified interface between WETH and other ERC20 tokens might be well worth the cost if it means avoiding something like this."

The SushiSwap MISO is a smart contract which assists with launching new coins and tokens which are managed through a smart contract hot wallet. The contract underwent 3 separate audits by reputable firms as well as multiple security researchers had reviewed it. And yet, there was still a bug found which would have been able to drain all $350m in funds.

 

Luckily, the exploit was found by a white hat security researcher, rather than a black hat hacker. As it turns out, the auction in question completed before any rescue had to be implemented. There was no loss suffered.

HOW COULD THIS HAVE BEEN PREVENTED?

Despite three audits, it's still possible for a complex smart contract to contain vulnerabilities. For that reason, protocols should have the majority of funds stored in a simple multi-sig treasury arrangement to limit losses. Those which are "hot" should be insured through smart contract insurance, self insurance from additional funds in the treasury, or an industry insurance fund.

 

Having a bug bounty program is a great idea to reduce the risk of breach. No funds were lost in this case due to the efforts of white hackers to find and fix the vulnerability before it could be exploited.

 

Check Our Framework For Safe Secure Exchange Platforms

Sources And Further Reading

 For questions or enquiries, email info@quadrigainitiative.com.

Get Social

  • email
  • reddit
  • telegram
  • Twitter

© 2021 Quadriga Initiative. Your use of this site/service accepts the Terms of Use and Privacy Policy. This site is not associated with Ernst & Young, Miller Thompson, or the Official Committee of Affected Users. Hosted in Canada by HosterBox.