Biconomy: Nexus

Summary

Initialising accounts can be griefed

Vulnerability Details

Would be key to note that creating account around all three factories (K1ValidatorFactory, NexusAccountFactory & RegistryFactory) are done in a similar way.

Now take a look at https://github.com/Cyfrin/2024-07-biconomy/blob/9590f25cd63f7ad2c54feb618036984774f3879d/contracts/factory/NexusAccountFactory.sol#L44-L64

This function creates a new Nexus account with the provided initialization data, issue however is that in the case where the account is already deployed the account never gets initialised. Whereas this shouldn't happen in the normal intended flow, this is very possible cause an attacker can just frontrun the attempt at creating the account with deterministically creating an account, considering the salt is not unique to the caller.

That would mean that the attacker can grief valid attempts of creating account, since they would never be initialised.

Impact

As hinted under Vulnerability Details, valid attempts of creating account can easily be faulted by an attacker since by frontrunning this the attacker ensures the accounts they would never be initialised.

As hinted earlier on in the report, this bug case is applicable to all three factories hinted below:

• https://github.com/Cyfrin/2024-07-biconomy/blob/9590f25cd63f7ad2c54feb618036984774f3879d/contracts/factory/NexusAccountFactory.sol#L43-L64

• https://github.com/Cyfrin/2024-07-biconomy/blob/9590f25cd63f7ad2c54feb618036984774f3879d/contracts/factory/RegistryFactory.sol#L111-L130

• https://github.com/Cyfrin/2024-07-biconomy/blob/9590f25cd63f7ad2c54feb618036984774f3879d/contracts/factory/K1ValidatorFactory.sol#L75-L105

Tools Used

Manual review

Recommendations

Consider either making the salt value unique down to the msg.sender value or, even if the account is already deployed still try to initialize the account.