search

code-423n4 / 2021-11-unlock-findings

0 stars 0 forks source link

Unlock: free UDT arbitrage opportunity #70

Open code423n4 opened 2 years ago

code423n4 commented 2 years ago

Handle

itsmeSTYJ

Vulnerability details

Impact

Uniswap v2 made oracle attacks much more expensive to execute (since it needs to be manipulated over X number of blocks) however its biggest drawback is that it reacts slow to price volatility (depends on how far back you look). Depending on a single oracle is still very risky and can be exploited given the correct conditions.

Assuming the ideal conditions, it is possible to purchase many keys across many locks for the UDT token that is distributed to the referrer and sell them on some other exchanges where the price of UDT is higher; high enough such that the malicious user can still profit even after requesting for a refund (w/ or w/o a free trial).

Proof of Concept

This exploit is made possible because of:

The following assumptions has to be true for this attack to work:

  1. price of UDT on an exchange is much higher than that from the price retrieved from the uniswapOracle.
  2. Since the price retrieved by udtOracle.updateAndConsult() only updates once per day, it is slow to react to the volatility of UDT price movements.
  3. Malicious user creates a lock and buys many keys across multiple addresses.
  4. Malicious user sells these UDT tokens on the exchanges w/ the higher price.
  5. Malicious user requests for a refund on the keys owned.
  6. Repeat until it is no longer profitable i.e. price on other exchanges become close to parity with the price retrieved by the uniswapOracle.

Recommended Mitigation Steps

julien51 commented 2 years ago

AS you noted this is pretty theoretical and given that the amount of UDT minted is capped to the gas spent, the user will need to 1) purchase a LOT of keys and 2) cancel them all and 3) find an exchange where the price is significantly different.

0xleastwood commented 2 years ago

Nice find!

While, I do agree this is a difficult attack to perform, it is still a valid way of extracting value from the protocol. Hence, I believe this should be kept as medium.

2 — Med (M): vulns have a risk of 2 and are considered “Medium” severity when assets are not at direct risk, but the function of the protocol or its availability could be impacted, or leak value with a hypothetical attack path with stated assumptions, but external requirements.
julien51 commented 2 years ago

We will mitigate this in an upcoming upgrade by moving to Uniswap v3 for our oracles.