deuszx
commented
9 months ago Flashminting is not something that makes a difference here. Someone with large capital could also perform your "attack". However, to pay back the A token they need to find another market where to buy A, to make profit. If they are able to do so it's because there was an arbitrage opportunity and not because the contract is vulnerable.
Please note that challange description requires the submission of PoC file:
Proof of Concept (PoC) file: You must provide a file containing a proof of concept (PoC) that demonstrates the vulnerability you have discovered.
Github username: @JJtheAndroid Twitter username: -- Submission hash (on-chain): 0xd4cd792db292411524594ee70338687f30aeb56e9c00bcb0a61846cd70561502 Severity: high
Description: Description\ In ink!, PSP22 tokens have the ability to have extensions. One of these extensions, flashminting, can allow a malicious actor to potentially drain a pool, causing a loss for liquidity providers
Attack Scenario\
Let's look at the PSP22 flast mint extension
https://learn.brushfam.io/docs/OpenBrush/smart-contracts/PSP22/Extensions/flashmint/
here it allows a user to perform a flash loan where tokens are minted and then burned in the same transaction. This can be used to manipulate and drain a pool in the following attack scenario:
Suppose there is a liquidity pool containing two assets: Token A and Token B. For simplicity, let's assume the pool initially contains 10,000 Token A and 100 Token B, which means 1 Token B is equivalent to 100 Token A (following the x * y = k constant product formula, since this protocol is based on Uniswap V2).
Flash Minting a Large Amount of Token A:
The bad actor uses the flash mint function of Token A to mint 1,000,000 Token A within a single transaction.
Swapping Minted Token A for Token B:
The bad actor then uses some of the minted Token A to swap for Token B in the liquidity pool. Let's say they use 500,000 Token A for the swap. Prior to the swap, the pool contains 10,000 Token A and 100 Token B. After adding 500,000 Token A, the pool has 510,000 Token A. To maintain the constant product
(x * y = k), the pool adjusts the amount of Token B. Initially, k = 10,000 * 100 = 1,000,000. After the swap, the new amount of Token B in the pool is calculated as k / new amount of Token A = 1,000,000 / 510,000 ≈ 1.96 Token B. The bad actor receives the difference in Token B from the pool, which is approximately 100 - 1.96 = 98.04 Token B.Repaying the Flash Mint:
The bad actor now has to repay the 1,000,000 Token A they flash minted. They use a portion of the 98.04 Token B they acquired to buy back enough Token A from the pool or from another source, ensuring they can repay the flash-minted amount. Let's assume the bad actor needs 2 Token B to buy back the required amount of Token A from another source or from the same pool at a now-devalued rate.
Profit:
After repaying the flash mint, the bad actor is left with a profit of 98.04 - 2 = 96.04 Token B. The liquidity pool is left imbalanced, with a depleted Token B reserve and an excess of Token A. Other liquidity providers suffer losses due to the devaluation of Token A and the removal of Token B from the pool.
Becuase the protocol is fairly new, newly created pools with low liquidity are very suceptible to this attack, using standard PSP22 tokens. A possible mitigation strategy to prevent this attack would be to limit the size of swaps requests
Attachments
https://github.com/Cardinal-Cryptography/common-amm/blob/bf4e48e3257894dcc8e6ab359321d1406533ad8b/amm/contracts/pair/lib.rs#L412-L419