WingRiders hackers put on a white hat and save $195M TVL on Minswap

We love to code and observe how from coding value is created. The code becomes a kind of living active functional being. Based on this we always observe the space and are on the lookout for current developments. We make smart contract security and correctness our number one priority. We have already published a blog post about potential <a href="https://medium.com/@wingriderscom/request-ordering-eeb4635b295a">reordering</a> concerns with transaction inputs that could limit the ability to verify the correctness of batch transactions. Today our post is regrettably more impactful and we will do our best to present to you our findings in an objective and transparent way.<a href="https://minswap.org/">Minswap</a> is a decentralized exchange on Cardano. They are community-driven and offer a polished UX. After completing their audit by Tweag they launched on mainnet reaching TVL over $195M. Lately, they open-sourced their smart contract code. We appreciate the team in doing so, as we believe only open-sourced smart contracts can be really trustless.Even though they are our competitor, we share common values and strive to offer a safe experience for the whole Cardano community. After going through their code we discovered multiple vulnerabilities where at least one was of critical severity level on 21.3.2022 in the UTC evening. It took us a couple of nerve-wracking hours to get in direct verified contact with the founders where we responsibly disclosed the vulnerability to them and offered guidance to stop the imminent threat and protect the funds ASAP with a first step of stopping the platform. As ourselves being community-centric and taking into regard the big community of Minswap we offered our advice, support, and tips on an action plan on how to execute the protective measures.For a moment we did consider exploiting the vulnerability ourselves and returning the funds based on blockchain snapshots to the community (to minimize the vulnerability time window). But out of respect to what the Minswap team and their community have achieved so far, we decided to leave it up to them to fix it. We really hope it was the right call and wish them luck with the challenging solution they’ve chosen to resolve the issue.Vulnerability  To understand the vulnerability we found, it is necessary to understand how Minswap DEX works under the hood. To create a liquidity pool, a special Pool NFT is minted and locked inside the pool by the initial liquidity provider. Whenever a user provides liquidity, LP tokens (or share tokens in WingRiders terminology) are minted on-demand and given to the liquidity provider. We can say that LP tokens represent the liquidity offered by the liquidity provider and can be redeemed for the share of liquidity (+fees -impermanent loss) later on.LP tokens differ between liquidity pools so that liquidity providers to one pool can not redeem liquidity from another pool. The Minswap minting policy allowed minting LP tokens **IF** a corresponding Pool NFT is found on **ANY** script address in the transaction outputs. Put together, the assumption for the minting of LP tokens is that only one Pool NFT can exist for a single liquidity pool. The Pool NFT is supposed to be locked inside the particular liquidity pool and can never be unlocked. The second assumption is that whenever a Pool NFT is in a transaction output on that pool script address, a script validator should have validated the transaction.We will show that these assumptions do not hold. By discovering a vulnerability in the minting policy governing the Pool NFT minting, an attacker can create any number of Pool NFTs that already match existing pools, take ownership of them and put them in any script which the attacker can control. (For example a script that allows any action.) The attacker can then simply mint any number of LP tokens for that pool using the maliciously minted and unlocked Pool NFT. We stress again, that the pool can be freely chosen among the existing ones.The attacker at this point owns an arbitrary number of LP tokens for any existing liquidity pool, which can be equivalent or more to the amount owned by actual liquidity providers. Liquidity providers can redeem liquidity and the attacker is no different. So the attacker is able to withdraw all liquidity from the given pool. The attacker can continue his attack and empty any and all liquidity pools.The actual critical vulnerability was in the Pool NFT minting policy. It correctly took a UTxO reference, checked that transaction spends that exact UTxO in the transaction limiting successful transactions to at most one (since an UTxO can not be spent twice) and minted a Pool NFT token with the token name equal to the hash of that UTxO reference. If it checked all this, how can we say it had a vulnerability? Smart contracts on Cardano are validation scripts. Anything that is not explicitly forbidden is allowed, even if the transaction does not resemble the intended one.The attacker could perform the attack by selecting a UTxO from their wallet. The attacker passed its UTxO reference as a redeemer to the policy. The transaction would mint a Pool NFT with the token name equal to the hash of his UTxO reference. So far, only the intended behavior was covered. However, the attacker could have minted another Pool NFT token alongside this, in the same transaction. Once again. Any other Pool NFT token with the same minting policy could be minted by this transaction. The first check in the policy checked that the transaction minted exactly one Pool NFT corresponding to the UTxO reference. It was missing a check that no other Pool NFT token was minted for this policy, though.A snippet of the first check:<img src="http://cardanofeed.com/site/uploads/2022/Mar/25/snippet.png" alt="">does not guarantee that `Value v` does not contain any additional tokens.  Having minted a token corresponding to the one located in an existing liquidity pool, the attacker was able to follow the other steps mentioned above and exploit the vulnerability.After we disclosed these findings we were expecting MinSwap to exploit the vulnerability and return the liquidity to the liquidity providers as we found additional potential areas for vulnerabilities that could expose at least in part the TVL. We advised them to do a full re-audit, pull funds, and re-release only after a thorough check of the contracts. Since they felt confident that patching contracts would be sufficient, we passed on the additional vulnerabilities we didn’t fully investigate as well to make sure they are aware of these and can try to address them if necessary. We are not able to confirm if the hotfix addressed all issues as that would require a thorough and deep audit of their codebase, so we will not release the details of the potentially vulnerable areas. We may disclose details on our findings in the future.<img src="https://miro.medium.com/max/1400/0*JZz2XAbVYW7q9OHH" alt="">ConclusionWe at <a href="https://wingriders.com/">WingRiders</a> have actively tried to hack our own code the whole time through tough code reviews, thorough code inspections before both testnet launches, and even more so before the upcoming mainnet launch. We used the mentality we acquired to review the code Minswap open-sourced.We are glad that Minswap’s team decided to respond after disclosing the vulnerability to them and are open to potential future cooperation on the project and community level if we can provide added value.What a great day when an ethical team was first to find exploits :) We are proud that we were able to support protecting our beloved Cardano community from an unfortunate impact. After our development team found and disclosed a critical vulnerability in multiple <a href="https://twitter.com/jpgstoreNFT/status/1462935207242260482">NFT</a> market places, this is another major one.DisclaimerWe are not an audit company, nor did we do any thorough review of Minswap contracts or code. This was the result of a surface-level sweep of the open-source code that was made publicly available. We neither can guarantee the completeness nor thoroughness of the code and contract review.We would also like to take this opportunity to thank our tireless developers, both WingRiders and Vacuumlabs, who did the hard work of finding and identifying this potential issue and bringing it to the community’s attention.