There is no checking whether the ExecutorPlugin module has been activated or not on the sub-account, this can cause malfunctions if the user wants to execute tx via ExecutorPlugin
Audit: 2023-10-brahma-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2023-10-brahma/blob/dd0b41031b199a0aa214e50758943712f9f574a0/contracts/src/core/TransactionValidator.sol#L181-L198


# Vulnerability details

# There is no checking whether the ExecutorPlugin module has been activated or not on the sub-account, this can cause malfunctions if the user wants to execute tx via ExecutorPlugin

## Impact

Can cause malfunctions if the user wants to execute tx via `ExecutorPlugin` on the sub-account

## Proof of Concept

If the user wants to execute tx on a sub-account via the `ExecutorPlugin` then, of course, the `ExecutorPlugin` as a module on the sub-account must be activated. The basis of the sub-account is Gnosif-Safe too, in which there is an `enableModule` function whose function is to activate the module on the sub-account. But in this case that never happened.

![Untitled](https://prod-files-secure.s3.us-west-2.amazonaws.com/93fed454-f35a-4808-afcf-14eb7aa5f207/a0f6be36-d733-46c0-80de-44b54f4f6f52/Untitled.png)

In this document it can be seen clearly how tx can be executed on sub-accounts via the `ExecutorPlugin`. For `Executor` to make a transaction on `SubAccount` via `ExecutorPlugin`. Execution via `ExecutorPlugin` executes in 3 steps;

1. The `Executor` calls `executeTransaction()` function on `ExecutorPlugin` enabled as module on `SubAccount`. The `ExecutorPlugin` validates that signer `Executor` is registered on `ExecutorRegistry`, then transfers the control to `TransactionValidator` by calling `validatePreExecutorTransaction()` which in turn transfers the control to `PolicyValidator` by calling `isPolicySignatureValid()` to check the `Trusted Validator Signature` is valid and then returns the control back to `ExecutorPlugin` via `TransactionValidator`.
2. `ExecutorPlugin` executes transaction on `SubAccount` as module.
3. After execution of module transaction, the `ExecutorPlugin` calls `validatePostExecutorTransaction()` function on `TransactionValidator`. to check that `SafeModerator` hasn't been removed as guard on `SubAccount` and `ConsoleAccount` hasn't been removed as module on `SubAccount`.

Here is a very good [document](https://github.com/code-423n4/2023-10-brahma/blob/main/contracts/docs/Architecture.md) from the Brahma team.

Checking whether the module is active or not is in the `validatePostTransaction` function in the `TransactionValidator.sol` contract, where this function calls the internal function `_checkSubAccountSecurityConfig` 

```solidity
File : contracts/src/core/TransactionValidator.sol

181 function _checkSubAccountSecurityConfig(address _subAccount) internal view {
182        address guard = SafeHelper._getGuard(_subAccount);
183        address fallbackHandler = SafeHelper._getFallbackHandler(_subAccount);
184
185        // Ensure guard has not been disabled
186        if (guard != AddressProviderService._getAuthorizedAddress(_SAFE_MODERATOR_HASH)) revert InvalidGuard();
187
188        // Ensure fallback handler has not been alte