Boost _ Folks Finance 33779 - [Smart Contract - Medium] The account creation process can be griefed

Submitted on Mon Jul 29 2024 08:49:26 GMT-0400 (Atlantic Standard Time) by @JCN2023 for Boost | Folks Finance

Report ID: #33779

Report type: Smart Contract

Report severity: Medium

Target: https://testnet.snowtrace.io/address/0x6628cE08b54e9C8358bE94f716D93AdDcca45b00

Impacts:

  • Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)

Description

Brief/Intro

An account is required to perform any core operations in the folks finance protocol. It is the user's responsibility to choose their accountId that will be created. A bad actor can front-run any account creation operation on the Hub chain and create an account using the accountId seen in any user's tx. Therefore, the bad actor is able to grief the account creation of any other user, preventing them from being able to interact with the protocol for an arbitrary amount of time.

Bug Description

Ignoring cross-chain components, the execution flow for account creation is as follows: SpokeCommon::createAccount -> router/adapter/hub interactions -> AccountManager::createAccount. It is important to note that all the account state is stored on the Hub chain, so the AccountManager contract on the Hub chain will store the account information for all users, even if the user is interacting via a different Spoke chain.

When creating an account, a user must supply an accountId that will be the identifier for the account to be created:

SpokeCommon::createAccount

The accountId is then validated to be non zero and must not have already been created:

AccountManager::createAccount

AccountManager::isAccountCreated

Since this accountId value is user defined, any bad actor can front-run other users' createAccount transactions and create accounts using those users' accountIds. This will result in the users' transactions reverting on line 42 in AccountManager.sol.

Impact

A bad actor can consistently grief other users' createAccount transactions, preventing those users from interacting with the core components of the protocol for an arbitrary amount of time. The bad actor can lower the gas costs of this exploit by submitting their createAccount tx directly via the Hub chain (utilizing the HubAdapter) instead of interacting via a Spoke chain (triggering cross chain communications).

I would recommend implementing an accountId state variable that is utilized and incremented every time a new account is created. This would be more gas intensive, but would limit the number of arbitrary values that users can supply to functions, which will in turn decrease the number of possible attack vectors.

Proof of concept

Proof of Concept

To run foundry POC:

  • add test file to test/ directory of a foundry repo

  • add AVAX_FUJI_RPC_URL variable as environment var or in .env file

  • run test with forge test --mc FolksPOC_GriefAccountCreation

Last updated

Was this helpful?