Gamma Protocol Exploit Analysis
Gamma Protocol Exploit Analysis
Introduction
The Gamma Strategies decentralized finance (DeFi) protocol encountered a security breach on January 4, 2024, wherein an attacked exploited vulnerabilities within their vaults on the Arbitrum layer-2 network. Through skillful manipulation of asset prices, the attacker stole nearly $6.2 million from the affected vaults.
Hacker attacked project in 4 vaults below:
Analysis
For our analysis, we will delve into the largest vault attack: gDAI-DAI.
Transaction Attack: TxAttack
Vulnerable Contract: ContractCode
Steps Executed by the Attacker:
Borrow DAI exceeding 4 million tokens from Uniswapv3Pool and Balancer.
Utilize a significant amount of DAI to purchase gDAI, inflating the gDAI price beyond the tick range supported by the Hypervisor.
Deposit 270,000 gDAI and 1 wei DAI into the Hypervisor contract to acquire numerous share tokens.
Withdraw all shares obtained in the previous step, receiving substantial DAIs through the removeLiquidity process in the Hypervisor. The attacker also obtained a portion of gDAIs deposited in step 3.
Swap gDAI to DAI, causing a drop in the gDAI price below the tick range supported by the Hypervisor. Since a considerable amount of DAI was pilfered in step 4, the attacker only needed to use an amount less than what was received in step 2 to rebalance the price range.
Deposit a small amount of gDAI, triggering the Hypervisor contract to use all remaining gDAI from step 3 to execute addLiquidity.
Repeat steps 2 to 6 multiple times. In each iteration, the attacker received a substantial amount of DAI in step 3 and residual gDAI from step 5.
Repay the DAIs for UniswapV3Pool and Balancer.
In a typical project, pump-and-dump price within a pool is considered a regular occurrence. Nevertheless, when the gDAI price exceeds the predetermined tick in this project, specific consequences emerge. Therefore, we will delve into the steps following step 3.
Dive into the step 3:
The contract uses realtime price from UniswapV3Pool, so the attacker gains a substantial number of shares following the recent price pumps.
Under deposit logic, the DAI and gDAI deposited by users are employed to add liquidity:
However, the attacker pumps the gDAI price beyond the supported range. The supported range becomes inactive, containing only DAIs and awaiting a decrease in gDAI price.
As a result, the Hypervisor utilizes only the existing DAI in the contract for adding liquidity, leaving the deposited gDAI untouched. It’s clearly an unexpected action, lots of share for only keeping ton of gDAI in contract.
Moving on to Step 4, the attacker withdraws all the shares obtained in step 3:
According to step3, the supported range consists solely of DAIs. The withdraw action allows attacker to obtain a huge part of all staked DAIs within this range (despite having deposited only 1 wei DAI in step 2). Because, lots of DAI is withdrawn in this step, the price in this range is now more susceptible to slippage. Additionally, the attacker also gains a portion of the gDAI staked in step 2.
Moving on to Step 5:
Due to the weakened liquidity within the supported range, the attacker only sell a number of gDAI which lower number he received in step 2 to make a decrease in gDAI price to under range supported.
In fact, attacker only needs to set price to original value. However, to optimize profit, he targeted to the remaining gDAI tokens in contract which he deposited in Step 3. So he set price lower than the supported range.
Step6:
With the price lower than the supported range, the attacker triggers the Hypervisor to add liquidity to all the residual gDAI tokens in Step 3.
Overall, from the step 2 to 6, attacker receives more DAI and gDAI tokens than the previous state. So attacker can repeat these steps to gain more profit.
For the next loops, each times attacker will take more gDAI and the DAI in attacker balance will decrease a bit (because the price rate and the number DAI can steal is downed).
Ultimately, the attacker stole 2,388,217 gDai and 23,862 DAI through this vault exploit. As outlined in the Gamma report, this roughly translates to $2.7 million.
Root Cause
After analyzing the attack process, we can see the main flaw in the contract lies in the project's use of real-time prices for calculations the shares. The project uses real-time prices to calculate the shares, and this causes the attacker to get a lot of shares even though their deposited tokens are not used when price is pumped.
Besides, the project doesn't handle it well when the price goes beyond the supported range. As a result, the attacker can quickly withdraw and get a lot of DAI that other users have staked.
Lesson learned
Relying solely on the direct use of prices for calculations poses a risk, as attackers may manipulate prices for their gain. Utilizing oracle prices is a prudent approach to ensure the proper functioning of the project. Additionally, it is crucial to be mindful of cases where the tick falls outside the supported range in UniswapV3Pool.