DYAD - djxploit's results

Lines of code

https://github.com/code-423n4/2024-04-dyad/blob/main/src/core/VaultManagerV2.sol#L143

Vulnerability details

Impact

In the VaultManagerV2.sol contract, when a user tries to withdraw his collateral by calling withdraw, an attacker can make the call revert by front-running.

Attacker will front-run the victim's withdraw call, and call the deposit function with same DNFT id passed in the victim's withdraw call, with 0 amount, and same vault address. Due to this, the deposit function will set the idToBlockOfLastDeposit[id] to the current block.number. And as the amount passed by the attacker is 0 amount, so the attacker doesn't need to approve the safetransferFrom call, and it will simply pass. The _vault.deposit line will also simply add 0 to the id2asset[id].

Now finally when the victim's withdraw call will execute, it will revert because of the 1st if statement

`if (idToBlockOfLastDeposit[id] == block.number) revert DepositedInSameBlock();`

As due to front-running by the attacker, the idToBlockOfLastDeposit[id] is set to the current block number, so the if check will return True , and this will revert the victim's withdraw transaction.

Attacker can use this same front-running technique to revert the victim's redeemDyad call too, as the root cause is same. So when the victim calls redeemDyad, attacker will front-run it, and call deposit function with same id and 0 amount. This will update the idToBlockOfLastDeposit[id] to current block number, and due to this the if condition will pass in withdraw function called inside redeemDyad function , and it will revert. Hence the whole transaction will revert.

Thus an attacker can repeat this process of front-running, and prevent the victim from withdrawing his collateral. This will ultimately lead to a DOS-like situation, where the victim will never be able to withdraw his collateral, and his collateral will forever be locked.

Proof of Concept

Consider the below scenerio:

1. Victim calls withdraw function to withdraw his collateral, by giving the DNFT id and the amount to withdraw, with the vault address
2. Attacker see this call in mempool, and front-runs it, and calls deposit function
3. Attacker calls the deposit function, with the same id passed in the victim's withdraw call, and passing 0 amount and with same vault address.
4. This will update the idToBlockOfLastDeposit[id] to current block number.
5. Hence when the victim's withdraw call will execute, it will revert, as the if condition will be true.

Tools Used

Manual review

Recommended Mitigation Steps

It is recommended to use the isDNftOwner(id) modifier in deposit function, instead of isValidDNft(id)

Assessed type

Other