Magpie Protocol Unchecked Contract Inputs

From Quadriga Initiative Cryptocurrency Hacks, Scams, and Frauds Repository
Jump to navigation Jump to search

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' section 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!

Magpie Protocol Logo/Homepage

Magpie Protocol offers efficient cross-chain trading without the need for bridges, enabling users to navigate DeFi seamlessly, facilitating seamless cross-chain swaps. It emphasizes fewer transactions and full non-custodial control of assets. Despite a recent attack due to a contract vulnerability resulting in a loss of $129,000 from 221 wallets, Magpie is taking steps to enhance security, including resetting selectors and collaborating with security firms like Cube3AI. They've reimbursed affected wallets and plan to conduct audits before releasing a new version.

This is a global/international case not involving a specific country.[1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18]

About Magpie Protocol

"Why use a bridge when you can FLY Trading any tokens between any chains - without the need to bridge, is what makes Magpie your efficient app to navigate DeFi."

"Our innovative design requires fewer transactions and confirmations." "Magpie is fully non-custodial. Your assets are in your control at all times." "Swap with speed between any chain of your choosing."

"Magpie serves as a sort of flightpath for the flock, introducing users to multiple blockchain networks and their corresponding protocols and features.

By flying through the typical barriers of going cross-chain, Magpie users can easily explore the multitude of opportunities offered on different networks, not only expanding the user base for individual projects across these chains but also fueling innovation as ideas and perspectives are shared across platforms."

"Magpie harnesses the liquidity from existing DEXs and bridge liquidity pools, both within chain and cross-chain.

This greatly reduces fragmentation and maximizes liquidity usage, resulting in improved market depth, cost-efficiency, reduced slippage, and better pricing on assets. The more liquidity networks we aggregate, the better our order router becomes. We're able to find the best deal on assets in real time, routing through anything to get there.

By utilizing the liquidity of well-established platforms, Magpie ensures that liquidity providers on these networks and protocols continue to benefit and contribute to the overall ecosystem in DeFi, and as the swaps go through those liquidity pools, they can still earn their rewards."

"The integration of multiple protocols through Magpie brings together the strengths of each, creating a more user-friendly and robust DeFi experience.

Magpie enables seamless cross-chain swaps by using bridges such as Wormhole, for cross-chain messaging, and Stargate, for deep liquidity reserves, so users can trade assets cross-chain seamlessly across different blockchains, unlocking a broader range of investment or trading opportunities.

Through the use of these integrations with Magpie, we enable the ability to access and swap thousands of different tokens cross-chain, both efficiently and securely, rather than limiting swaps to a handful of native assets and stablecoins."

"These all represent a significant step towards realizing the full potential of cross-chain growth and a multichain future. By connecting users to new blockchains, leveraging liquidity networks, and integrating different blockchain protocols, we pave the way for increased collaboration, innovation, and seamless, user-friendly transactions across blockchains.

As the DeFi landscape continues to evolve, Magpie will be here to be sure to create a more interconnected, efficient, and user-centric decentralized finance ecosystem."

"The decentralized liquidity aggregation protocol Magpie Protocol was attacked due to a contract vulnerability, resulting in $129,000 being stolen from 221 wallets. The root cause is due to unchecked call data. The attacker called the contract's swap() function and passed in data which included a list of users to transfer tokens from."

"Our router, MagpieRouterV2, is supposed to work as a router, nothing more. Which means it is not supposed to have funds and only do the required aggregation and send the tokens to the target address. We made our router flexible for aggregation in a way that we can construct complex calls which helps us to work gas cost efficiently with almost any protocol (it doesn’t require continuous contract updates for every protocol, and more importantly, optimized user gas usage).

From a security standpoint, one of the most important parts is the function selector. The function parameters shouldn’t be an issue since the contract is not supposed to hold funds and from the user’s perspective the most important thing is at the end of execution the minimum amount of the requested asset has to be received. With this, the most critical issue was to deny transfers from approved funds if the initiator is not the user itself."

"The way we construct our commands had a bug where we check for the validity of the selector, and the constructed input length, but not the position of the selector. The exploiter created an address which starts with one of the approved selector."

"We have contacted the attacker, and we have gotten no response back as of this writing. If you are reading this, we would be extremely grateful to provide a generous bounty and would obligate ourselves not to disclose any information about your identity."

"Resetting all selectors to 0 prevents this exploit since there is a check in the contract to not execute any custom calls where the selector is not defined."

"We will check the selector in the finalized input before the execution of the command to make sure it cannot execute `transferFrom` if it is not initiated by the sender. We will add a pause functionality to the swap just in case if any future emergency happens.

We are also considering adding a 3rd party to our contracts to monitor and pause our swaps if any unusual activity happens."

"We are in contact with Cube3AI, Hypernative, among others to secure the next version of our contracts. With a protocol like Cube3AI, it would enable RASP (Runtime Application Self Protection), allowing us to block risky and fraudulent transactions in real-time. This will also automatically alert anyone to an attempted exploit or hack.

Additionally, we are integrating Web3Shield as our insurance partner, which allows our users to get insurance by paying a premium in the same token they are swapping when bridging assets."

"We have just recently sent our reimbursements to all of the affected wallets. We are dedicated and incredibly thankful for our community and want to thank you all for being so understanding during this emergency situation. Until then, after the fix is applied to the contracts, we will conduct an audit with QuillAudits before releasing the new version, so our app will be down for maintenance until then."

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 - Magpie Protocol Unchecked Contract Inputs
Date Event Description
April 23rd, 2024 3:50:00 AM MDT Warning To Revoke The Magpie Protocol team posts a warning on Twitter requesting users to revoke permissions if they haven't yet.
April 23rd, 2024 4:43:59 AM MDT Ethereum Exploit Exploit transaction on Ethereum.
April 23rd, 2024 4:59:11 AM MDT BSC Exploit Exploit transaction on Binance Smart Chain.
April 23rd, 2024 6:31:00 AM MDT Twitter Follow Up Magpie Protocol posts a follow up update to notify that revoking permissions is no longer necessary as the immediate threat has been neutralized.
April 23rd, 2024 9:26:59 AM MDT Attempt To Reach Attacker The protocol sends a message to the attacker "to discuss returning the funds in exchange for a bounty".
April 26th, 2024 1:15:20 PM MDT Medium Postmortem A postmortem is shared by Magpie protocol on Medium.

Technical Details

"The attacker constructed a command that:

1. Created a custom data sequence:

23b872dd000000000000000000000000dd21d4610dc36792372769758e53aa9e312b14a0000000000000000000000000

2. Next sequence was the selector selected from storage:

e8eda9df

3. Then another custom data sequence was created:

edb228aa0cfd2c2f809a4418d0319eb20000000000000000000000000000000000000000000000000000000023c34600

So the exploiter could inject this address into the input:

0xe8eda9dfedb228aa0cfd2c2f809a4418d0319eb2

Through doing this, he skipped the check for `InvalidTransferFrom` which we used to protect exactly against this sort of attack. At the end he used his generated address which starts with the selector itself, while he still defined the required selector."

Total Amount Lost

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

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

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

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?

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.

References