Decent - nuthan2x's results

Lines of code

https://github.com/decentxyz/decent-bridge/blob/7f90fd4489551b69c20d11eeecb17a3f564afb18/src/DcntEth.sol#L20 https://github.com/decentxyz/decent-bridge/blob/7f90fd4489551b69c20d11eeecb17a3f564afb18/src/DecentEthRouter.sol#L294

Vulnerability details

Impact

    function setRouter(address _router) public {
        router = _router;
    }

Any attacker can set any address as router, and can mint/burn DcntEth tokens which can be redeemed for WETH at DecentEthRouter::redeemWeth and DecentEthRouter::redeemEth

• DcntEth contract allows minting and burning of DcntEth tokens directly pegged to WETH.
• So, the DecentEthRouter mints tokens to router itself, if a user provides WETH as liquidity to DecentEthRouter::addLiquidityEth and DecentEthRouter::addLiquidityEth, some DcntEth toeksn are minted.
• Anyone with DcntEth tokens can convert into WETH if the liquidity is available.

Proof of Concept

• An attacker sets himself as router by calling DcntEth::setRouter
• Then mints all the DcntEth supply to himself by calling DcntEth::mint
• Then call DecentEthRouter::redeemWeth with maximum available lquidty and redeem WETH.
• profits ✅

Tools Used

manual review

Recommended Mitigation Steps

Modify DcntEth::setRouter to only allow owner to set router.

-   function setRouter(address _router) public {
+   function setRouter(address _router) onlyOwner public {
        router = _router;
    }

Assessed type

Access Control

Lines of code

https://github.com/decentxyz/decent-bridge/blob/7f90fd4489551b69c20d11eeecb17a3f564afb18/src/DecentEthRouter.sol#L98

Vulnerability details

Impact

Although 100k GAS_FOR_RELAY is applied as minimum This is an issue that affects all the contracts that inherit from NonBlockingLzApp due to incorrect overriding of the lzSend function and lack of input validation and the ability to specify whatever adapterParams you want. The consequence of this is that anyone can with a low cost and high frequency keep on blocking the pathway between any two chains, making the whole system unusable.

Proof of Concept

Layer Zero minimum gas showcase While sending messages through LayerZero, the sender can specify how much gas he is willing to give to the Relayer to deliver the payload to the destination chain. This configuration is specified in relayer adapter params. All the invocations of lzSend inside the DentEth contracts pass 100k+ gas on the destination.

As a showcase, The transaction below proves , an application that has the intention of using the NonBlockingApp can end up in a situation where there is a StoredPayload and the pathway is blocked.

Transaction Hashes for the example mentioned above:

LayerZero Scan: https://layerzeroscan.com/106/address/0xe6772d0b85756d1af98ddfc61c5339e10d1b6eff/message/109/address/0x5285413ea82ac98a220dd65405c91d735f4133d8/nonce/1 Tenderly stack trace of the sending transaction hash: https://dashboard.tenderly.co/tx/avalanche-mainnet/0xe54894bd4d19c6b12f30280082fc5eb693d445bed15bb7ae84dfaa049ab5374d/debugger?trace=0.0.1 Tenderly stack trace of the receiving transaction hash: https://dashboard.tenderly.co/tx/polygon/0x87573c24725c938c776c98d4c12eb15f6bacc2f9818e17063f1bfb25a00ecd0c/debugger?trace=0.2.1.3.0.0.0.0

Tools Used

copied from this issue.

Recommended Mitigation Steps

Increase GAS_FOR_RELAY to 200k and refund the unsed gas after the dest chain tx succeeds.

Assessed type

DoS

Lines of code

https://github.com/code-423n4/2024-01-decent/blob/011f62059f3a0b1f3577c8ccd1140f0cf3e7bb29/src/bridge_adapters/StargateBridgeAdapter.sol#L209-L215

Vulnerability details

Impact

• Tokens/Ether will be permanently freezed in the bridge adapters if any of the actions post bridge fails/reverts.
• Tokens can't be recovered, but MEV bos will sweep in the same block itself.

For any of the below reasons, if sgReceive reverts, then the funds can be sweeped by anyone. - The slippage of minOut/maxIn values doen't match, so post bridge swap with dexes failed. Or worse, the liquidity was low on the destination chain. - If stargate forwards less gas that it took to execute the tx, or pre bridge gas parameters were not enough to complete all state changes, so Out-Of-Gas error is thrown. - the approval call does not check for bool return, or USDT's approval race implementation, or improper Fee on transfer hadling can revert. - The refund address doesn't implement fallback function in a contract ..

If any of the above cases, primarily slippage/liquidity revert can make the funds locked in the contract. Then an attacker can call sgReceive with any payload he pleases payload and can sweep the locked tokens.

Proof of Concept

• A user bridges from chain A to chain B
• A post bridge swap has to happen, but due to low liquidity or high slippage/or gas errors, the transaction of sgReceive failed.
• Now the funds are locked in the chain B bridge adapter contract.
• An MEV bot can call from another chain C to chain B which will trigger sgReceive with a payload that can sweep the toens in the chain B bridge adapter.

Tools Used

Manual review

Recommended Mitigation Steps

Implement the try catch method in the sgReceive function

 function sgReceive(
        uint16, // _srcChainid
        bytes memory, // _srcAddress
        uint256, // _nonce
        address, // _token
        uint256, // amountLD
        bytes memory payload
    ) external override onlyExecutor {
        (
            SwapInstructions memory postBridge,
            address target,
            address paymentOperator,
            bytes memory utbPayload,
            address payable refund
        ) = abi.decode(
                payload,
                (SwapInstructions, address, address, bytes, address)
            );

        SwapParams memory swapParams = abi.decode(
            postBridge.swapPayload,
            (SwapParams)
        );

        IERC20(swapParams.tokenIn).approve(utb, swapParams.amountIn);

-       IUTB(utb).receiveFromBridge(
-           postBridge,
-           target,
-           paymentOperator,
-           utbPayload,
-           refund
-       );

+       try IUTB(utb).receiveFromBridge(postBridge, target, paymentOperator, utbPayload, refund) returns () {
+        
+       } catch  {
+           IERC20(swapParams.tokenIn).transfer(refund, swapParams.amountIn);   
+       }
    }

Assessed type

Token-Transfer