Axelar Network v2 contest - cryptphi's results

Decentralized interoperability network.

General Information

Platform: Code4rena

Start Date: 29/07/2022

Pot Size: $50,000 USDC

Total HM: 6

Participants: 75

Period: 5 days

Judge: GalloDaSballo

Total Solo HM: 3

Id: 149

League: ETH

Axelar Network

Findings Distribution

Researcher Performance

Rank: 8/75

Findings: 2

Award: $2,134.93

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

🌟 Selected for report: Lambda

Also found by: 0x52, cryptphi

Labels

bug
duplicate
2 (Med Risk)

Awards

2078.8043 USDC - $2,078.80

External Links

Lines of code

https://github.com/code-423n4/2022-07-axelar/blob/main/xc20/contracts/XC20Wrapper.sol#L71 https://github.com/code-423n4/2022-07-axelar/blob/main/xc20/contracts/XC20Wrapper.sol#L124-L125

Vulnerability details

Impact

Whenever owner removes wrapping by calling removeWrapping() , it sets the wrapped[axelarToken] to 0. This would allow users to be able to call _executeWithToken() when the function is used in the future by calling a function that calls it (i.e if this function is really meant to be internal instead of external, but if it is really external function then can be called anytime)

The call in _executeWithToken() sets variable xc20 to wrapped[tokenAddress] which exists as address(0) after removeWrapping() call by owner. xc20 will pass the if-statement and then proceed to transfer tokens to receiver.

Tools Used

Manual review

The mapping for the removed wrapping should be deleted instead of set to address 0.

#0 - re1ro

2022-08-05T05:53:01Z

Duplicate of #23

#1 - GalloDaSballo

2022-09-04T19:09:41Z

Dup of #23

While the conclusion of how the tokens can be sweeped is different, the root cause is Admin Privilege can remove wrapping when wrappedBalance > 0

  1. No receive() function to receive ether in contract The following contracts have payable functions for caller to send ether to contract. However the contract does not implement receive() to receive the eth.

**Occurrences in: https://github.com/code-423n4/2022-07-axelar/blob/main/xc20/contracts/XC20Wrapper.sol https://github.com/code-423n4/2022-07-axelar/blob/main/contracts/deposit-service/AxelarDepositService.sol https://github.com/code-423n4/2022-07-axelar/blob/main/contracts/gas-service/AxelarGasService.sol

  1. unchecked transfer There occurrences of IERC20(token).transfer() calls without returned value checks. Transactions will not be reverted on failed transfer, setting system state as if it was successful.

**Occurrences in: https://github.com/code-423n4/2022-07-axelar/blob/main/contracts/deposit-service/ReceiverImplementation.sol#L23 https://github.com/code-423n4/2022-07-axelar/blob/main/contracts/deposit-service/ReceiverImplementation.sol#L51 https://github.com/code-423n4/2022-07-axelar/blob/main/contracts/gas-service/AxelarGasService.sol#L128 would affect AxelarDepositService.refundNativeUnwrap() - > ReceiverImplementation.receiveAndUnwrapNative() - > recipient.transfer(receiver) AxelarDepositService.nativeUnwrap - > ReceiverImplementation.receiveAndUnwrapNative() - > recipient.transfer(receiver)

  1. missing zero address check on recipient in : Some functions are missing zero address checks on receiver of funds

**Occurrences in: AxelarDepositService.refundNativeUnwrap() - > ReceiverImplementation.receiveAndUnwrapNative() - > recipient.transfer(receiver)

AxelarDepositService.nativeUnwrap - > ReceiverImplementation.receiveAndUnwrapNative() - > recipient.transfer(receiver)

AxelarDepositService.sendNative() - destinationAddress parameter

refundAddress param in the following functions: AxelarDepositService.refundTokenDeposit() AxelarDepositService.sendNativeDeposit() AxelarDepositService.refundNativeDeposit() AxelarDepositService.nativeUnwrap() AxelarDepositService.

#0 - re1ro

2022-08-05T07:12:11Z

1

Not applicable. Those contracts are not meant to receive ether directly.

2

Not applicable. Those are native ether transfers

3

Dup #3

#1 - GalloDaSballo

2022-08-31T21:01:53Z

missing zero address check on recipient in :

Valid Low

Rest is invalid, payable.transfer doesn't need to be checked

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter