Axelar cross chain token transfers balance tracking logic is completely broken for rebasing tokens and the transfers of these type of tokens can be exploited
Audit: 2024-08-axelar-network-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-08-axelar-network/blob/69c4f2c3fcefb1b8eb2129af9c3685a44ae5b6fe/interchain-token-service/contracts/TokenHandler.sol#L91-L123
https://github.com/code-423n4/2024-08-axelar-network/blob/69c4f2c3fcefb1b8eb2129af9c3685a44ae5b6fe/interchain-token-service/contracts/TokenHandler.sol#L45-L80
https://github.com/code-423n4/2024-08-axelar-network/blob/69c4f2c3fcefb1b8eb2129af9c3685a44ae5b6fe/axelar-amplifier/interchain-token-service/src/contract/execute.rs#L101-L132
https://github.com/code-423n4/2024-08-axelar-network/blob/69c4f2c3fcefb1b8eb2129af9c3685a44ae5b6fe/axelar-amplifier/interchain-token-service/src/state.rs#L166-L197


# Vulnerability details


## Proof of Concept

> NB: This report is a 2 in 1, first sub section shows how the transfers would be exploited when there is a rebase _(focusing on the solidity implementation of the Hub)_ and the second sub section showcases how the balance tracking logic would be completely broken for rebasing tokens _(focusing on the Rust implementation of the ITS Hub)_.

First, would be key to note that per the scope of the contest we should count rebasing tokens _(whose balance change outside of transfers)_ in scope. See what's been stated in the readMe: https://github.com/code-423n4/2024-08-axelar-network/blob/69c4f2c3fcefb1b8eb2129af9c3685a44ae5b6fe/README.md#scoping-q--a

| Question                                                                                                                                                   | Answer                    |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------- |
| ERC20 used by the protocol                                                                                                                                 | Any (all possible ERC20s) |
| [Balance changes outside of transfers](https://github.com/d-xo/weird-erc20?tab=readme-ov-file#balance-modifications-outside-of-transfers-rebasingairdrops) | In scope                  |

### Sub-section 1

There are different token manager types that take care of the different types of tokens that get integrated to the system, i.e https://github.com/code-423n4/2024-08-axelar-network/blob/69c4f2c3fcefb1b8eb2129af9c3685a44ae5b6fe/interchain-token-service/contracts/interfaces/ITokenManagerType.sol#L10-L17

```solidity
    enum TokenManagerType {
        NATIVE_INTERCHAIN_TOKEN, // This type is reserved for interchain tokens deployed by ITS, and can't be used by custom token managers.
        MINT_BURN_FROM, // The token will be minted/burned on transfers. The token needs to give mint permission to the token manager, but burning happens via an approval.
        LOCK_UNLOCK, // The token will be locked/unlocked at the token manager.
        LOCK_UNLOCK_FEE, // The token will be locked/unlocked at the token manager, which will account for any fee-on-t