Malicious users can exploit a re-entrancy opportunity in `_handletrade` to bypass `SHARE_LOCK_PERIOD` and carry out a flashloan attack to dilute existing shareholders and steal their rewards distribution
Audit: 2024-08-phi-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-08-phi/blob/8c0985f7a10b231f916a51af5d506dd6b0c54120/src/Cred.sol#L641-L644


# Vulnerability details

## Vulnerability Details
In `Cred.sol` we can see that in the part of `_handletrade`[L641-644:](https://github.com/code-423n4/2024-08-phi/blob/8c0985f7a10b231f916a51af5d506dd6b0c54120/src/Cred.sol#L641-L644)
```solidity
  function _handleTrade(
      uint256 credId_,
      uint256 amount_,
      bool isBuy,
      address curator_,
      uint256 priceLimit
  )
      internal
      whenNotPaused
  {
      ......

      if (isBuy) {
          ....
          if (excessPayment > 0) {
@1>             _msgSender().safeTransferETH(excessPayment);
          }
@2>       lastTradeTimestamp[credId_][curator_] = block.timestamp;
      } else {
          ....
      }
      ....
  }
```

The line at "`@1>`" allows for re-entrancy, and since that line is before line "`@2>`", re-entrancy will allow malicious users to bypass `SHARE_LOCK_PERIOD` check since `lastTradeTimestamp` is outdated during the operations of the re-entrancy.

With `SHARE_LOCK_PERIOD` out of the way, the protocol is vulnerable to the following exploit, which will allow the malicious user to use flashloans to dilute existing shareholders, steal their rewards and exit their positions all within the **same** transaction.
1. `Creator` creates `credId: 1`
2. Honest shareholder `Alice` buys some share of `credId 1` and becomes a shareholder.
3. Protocol users mints art of `credId 1`, causing rewards to be deposited into `CuratorRewardsDistributor.sol` which are meant to be distributed between shareholders of `credId 1`.
4. Malicious user `Bob` does the following operations **ALL** in one transaction
    1. `Bob` takes a flashloan
    2. In the same transaction, `Bob` uses funds from flashloan to buy up a significant amount of shares, severely diluting `Alice`
    3. When buying the shares, `Bob` sends `+1 wei` of the amount required in `buyShareCred`.
    4. The line at "`@1>`" in the code snippet will transfer him back the `1 wei`, allowing him to start his re-entrancy attack, taking advantage of `lastTradeTimestamp`'s value being outdated.
    5. In `Bob`'s `receive`/`fallback` function, he calls `CuratorRewardsDistributor.sol`'s `distribute` function.
    6. This will allow `Bob` to receive majority of the rewards since he has severely diluted `Alice`'s stake.
    7. Afterwards, he calls `sellShareCred` in the same transaction to return the money to the flashloan protocol, completing the exploit.

Hence, `Bob` has managed to exploit the un-updated value of `lastTradeTimestamp` to steal majority of `Alice`'s rewards by entering and exiting in the same transaction, allowing him to use a flashloan. At the same time he does **NOT** have to take on any risk of the share price dropping, since he is selling in the same transaction as he bought them.

## Proof Of Concept
Create the following file `flashLoanAttack.t.sol` and add it to the `test/` folder