SushiSwap MISO White Hat Diffusal

Notice: This page is a freshly imported case study from the original repository. The original content was in a different format, and may not have relevant information for all sections. Please help restructure the content by moving information from the 'About' and 'General Prevention' sections to other sections, and add any missing information or sources you can find. 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!

SushiSwap

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.

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

About SushiSwap

"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."

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

The background of the exchange platform, service, or individuals involved, as it would have been seen or understood at the time of the events.

Include:

• Known history of when and how the service was started.
• What problems does the company or service claim to solve?
• What marketing materials were used by the firm or business?
• Audits performed, and excerpts that may have been included.
• Business registration documents shown (fake or legitimate).
• How were people recruited to participate?
• Public warnings and announcements prior to the event.

Don't Include:

• Any wording which directly states or implies that the business is/was illegitimate, or that a vulnerability existed.
• Anything that wasn't reasonably knowable at the time of the event.

There could be more than one section here. If the same platform is involved with multiple incidents, then it can be linked to a main article page.

The Reality

This sections is included if a case involved deception or information that was unknown at the time. Examples include:

• When the service was actually started (if different than the "official story").
• Who actually ran a service and their own personal history.
• How the service was structured behind the scenes. (For example, there was no "trading bot".)
• Details of what audits reported and how vulnerabilities were missed during auditing.

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 - SushiSwap MISO White Hat Diffusal

Date	Event	Description
August 16th, 2021 11:40:00 AM MDT	Main Event	Expand this into a brief description of what happened and the impact. If multiple lines are necessary, add them here.

Technical Details

This section includes specific detailed technical analysis of any security breaches which happened. What specific software vulnerabilities contributed to the problem and how were they exploited?

Total Amount Lost

The total amount at risk has been estimated at $350,000,000 USD. No funds were lost.

How much was lost and how was it calculated? If there are conflicting reports, which are accurate and where does the discrepancy lie?

Immediate Reactions

How did the various parties involved (firm, platform, management, and/or affected individual(s)) deal with the events? Were services shut down? Were announcements made? Were groups formed?

Ultimate Outcome

What was the end result? Was any investigation done? Were any individuals prosecuted? Was there a lawsuit? Was any tracing done?

Total Amount Recovered

There do not appear to have been any funds recovered in this case.

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

Ongoing Developments

What parts of this case are still remaining to be concluded?

General Prevention Policies

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.

Individual Prevention Policies

No specific policies for individual prevention have yet been identified in this case.

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

Platform Prevention Policies

Policies for platforms to take to prevent this situation have not yet been selected in this case.

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

Regulatory Prevention Policies

No specific regulatory policies have yet been identified in this case.

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