sherlock-audit / 2024-05-midas-judging

12 stars 6 forks source link

Bigsam - Lack of Modifier onlyGreenlisted(msg.sender) in function withdrawToken will make frontrunning of admin who calls blacklist/pause while the malicious user withdraws his token succesfully. #176

Closed sherlock-admin4 closed 4 months ago

sherlock-admin4 commented 5 months ago

Bigsam

medium

Lack of Modifier onlyGreenlisted(msg.sender) in function withdrawToken will make frontrunning of admin who calls blacklist/pause while the malicious user withdraws his token succesfully.

Summary

Because o the missing check onlyGreenlisted(msg.sender) A malicious actor can front-run the admin who calls blacklist/pause function and redeem all his imbill tokens successfully. Also a malicious user who has done his KYC and AML who acquires Imbill tokens through hacking on another platform can potentially redeem them before the admin is aware or even if the admin is aware and they are blacklisted. After successfully front running the admin according to the docs, withdraw is computed off-chain and for USDC token it is executed on-chain.

https://docs.midas.app/protocol-mechanics/how-it-works/issuance-and-redemption#:~:text=Redemption%20requests%20are,additional%20business%20days.

While i want to believe other checks are done offchain to prevent this for off chain redemption, the function withdrawToken in ManageableVault.sol (ON-CHAIN) fails to query the address we are withdrawing to, hence a blacklisted account can get paid if he fronts-run the admin.

Vulnerability Detail

Fronting the admin because of a lack of verification on the address withdrawTo can allow a blacklisted account to redeem imbill tokens against protocol design. Even though KYC is conducted before deposits and redemptions, a malicious user can exploit the time gap between acquiring stolen tokens and the admin blacklisting them. This allows the attacker to:

  1. Frontrun the Admin: The malicious user can call the redeem function before the admin is aware of the stolen tokens and blacklists the user's address.
  2. Exploit Time Delays: Since withdrawals take 2 days or more, a malicious user can initiate a redeem transaction before the admin can blacklist the address. Even if the admin becomes aware, the attacker might frontrun the admin's attempt to blacklist the address, successfully withdrawing stolen funds/his funds in the native token or USDC.

    Impact

    A blacklisted accounts withdrwawal request is processed successfully and Stolen Imbill tokens can be redeemed and withdrawn by malicious actors before they are blacklisted. ALL this is possible because of a missing modifier on https://github.com/sherlock-audit/2024-05-midas/blob/main/midas-contracts/contracts/abstract/ManageableVault.sol#L92-L96

Code Snippet

https://github.com/sherlock-audit/2024-05-midas/blob/main/midas-contracts/contracts/RedemptionVault.sol#L57-L77

https://github.com/sherlock-audit/2024-05-midas/blob/main/midas-contracts/contracts/abstract/ManageableVault.sol#L151-L157

https://github.com/sherlock-audit/2024-05-midas/blob/main/midas-contracts/contracts/abstract/ManageableVault.sol#L86-L100

Tool used

Manual Review

Recommendation

To mitigate this vulnerability, the following recommendations are suggested:

  1. On-chain Blacklist Checks: Modify the smart contract to check the user's blacklist status before allowing withdrawn funds to proceed. This would prevent blacklisted users from withdrawing funds.
  2. I believe Off-chain Verification is being done but i will like to stress the : Implement off-chain checks to verify user identities before allowing/sending funds to the users account. This could involve additional KYC procedures off-chain or risk assessments.
sherlock-admin2 commented 4 months ago

1 comment(s) were left on this issue during the judging contest.

WildSniper commented:

low | this is the case with any on-chain pausing functionality && withdrawToken() is called only from permissioned actor.