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:
The accountId
is then validated to be non zero and must not have already been created:
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' accountId
s. 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).
Recommended Mitigation
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 repoadd
AVAX_FUJI_RPC_URL
variable as environment var or in.env
filerun test with
forge test --mc FolksPOC_GriefAccountCreation