Attacker can take over and hijack any and every asset of a party initialized with the governance value `distributionsRequireVote` set to false, through the utilization of a flash loan.
Audit: 2023-10-party-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-10-party/blob/b23c65d62a20921c709582b0b76b387f2bb9ebb5/contracts/crowdfund/ETHCrowdfundBase.sol#L196


# Vulnerability details

### Pre-requisite knowledge & an overview of the features in question
---
1. The `distributionsRequireVote` flag: The `distributionsRequireVote` flag is a governance value flag set to `false` by default in the governance values. It determines whether or not a party member can simply create a distribution without the need to create a proposal, get it to pass, or not.

    - By default, it is set to as `false` because creating token distributions isn't seen as a sensitive action. If a party member creates a distribution, then everybody can simply claim his share of the distribution. No funds will be lost.

    - By default, the distribution creation without voting feature/flag is toggled on unlike the governance values like `enableAddAuthorityProposal`, `allowArbCallsToSpendPartyEth`, `allowOperators`. Those are flags you have to toggle on by creating a proposal and getting it to pass because they are seen as sensitive actions.


### The Vulnerability
---
In parties which are initialized with the flag `distributionsRequireVote` set to `false` (the default) **OR** initialized with a host member that is malicious (more on that later), an attacker can take over the party and get voting power equivalent to 51% or even more of the total voting power of the party through taking a flash loan.

After the attacker obtains such voting power, he can change the proposal engine configuration, add himself as an authority, hijack any precious tokens and any assets in the party.

#### Example Attack:

1. Let's imagine a crowdfund (to-be party) with the following configuration:

- `minTotalContribution` = 100 ether
- `maxTotalContributions` = 200 ether
- `maxContribution` = `type(uint256).max`
- `passThreshold` = `5000` (50% have to vote for the proposal to pass)

2. The crowdfund starts and earns 100 ether in contribution, so it has met it's minimum total contribution. Only after the expiration time, the party will be finalized.

3. The attacker takes a flash loan of 100 ether and contributes with it to reach the `maxTotalContributions` target. The crowdfund will be finalized immediately and the attacker will get a 50% voting power (can abuse this to get even more)

4. The attacker will create a native ether distribution through the `distribute()` function in `PartyGovernance` contract. He can do so without having to create a proposal as `distributionsRequireVote` is set to `false`.

5. The attacker will claim his 50% share from the created ETH distribution by calling the function `claim()` in the `TokenDistributor` contract.

6. Now the attacker has his ETH back and will repay the flash loan

7. The attacker is now left with 50% voting power (pass threshold). The attacker now can, change the configuration of the proposal engine, add himself as an authority, hijack all ETH + ERC20 tokens