Vulnerability in the membership check function, allowing attackers to bypass membership checks and perform actions they should not be allowed to execute.
Audit: 2023-09-centrifuge-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-09-centrifuge/blob/512e7a71ebd9ae76384f837204216f26380c9f91/src/InvestmentManager.sol#L657-L660


# Vulnerability details

## Impact

- Attackers can bypass membership checks and perform actions they should not be allowed to execute.
- Unauthorized withdrawals can lead to a loss of assets within the liquidity pool.
- The vulnerability compromises the integrity of the smart contract, undermining its security features.

**Vulnerability Overview:**

A vulnerability exists in the membership check function of the `InvestmentManager` contract. The vulnerability allows an attacker to bypass the membership check, gaining unauthorized access to functions that should be restricted to pool members only. This could lead to unauthorized actions and potential loss of funds.

## Proof of Concept

There is a critical assumption made regarding the behavior of the `checkTransferRestriction` function in the `LiquidityPoolLike` contract. This function is used to verify whether a user is a member of the liquidity pool before allowing them to perform certain actions, such as withdrawals or deposits. The vulnerable code segment is as follows:

**[Code Link](https://github.com/code-423n4/2023-09-centrifuge/blob/512e7a71ebd9ae76384f837204216f26380c9f91/src/InvestmentManager.sol#L657-L660)**

```solidity
// In the InvestmentManager contract
function withdraw(uint256 amount) public {
    address liquidityPool = msg.sender;
    // Incorrectly assuming that this check ensures membership
    require(
        LiquidityPoolLike(liquidityPool).checkTransferRestriction(address(0), msg.sender, 0),
        "InvestmentManager/not-a-member"
    );
    // Proceed with the withdrawal
    // ...
}
```

The vulnerability arises from the assumption that the `checkTransferRestriction` function correctly determines membership status. If this assumption fails, the contract can be manipulated to allow unauthorized users to perform actions that should be restricted.

**Attack Scenario:**

Consider the following attack scenario:

1. An attacker, who is not a member of the liquidity pool, interacts with the `InvestmentManager` contract and attempts to withdraw funds.

2. The `checkTransferRestriction` function in the `LiquidityPoolLike` contract has a vulnerability that fails to correctly verify the attacker's membership status.

3. Due to this vulnerability, the membership check erroneously allows the attacker to proceed with the withdrawal.

4. The attacker successfully withdraws funds from the liquidity pool, even though they should not have had access.


## Tools Used
Vs

## Recommended Mitigation Steps

Implement additional checks within the `InvestmentManager` contract to verify the membership status of users before allowing them to perform actions restricted to pool members.

Example:
```solidity
// In the InvestmentManager contract
function withdraw(uint256 amount) public {
    address liquidityPool = msg.sender;
    require(
        Li