We got an intresting attack vector using these cases. Because

of when cross chain transactions occur it losses its atomicity if a call reverts on destination chain the sender chain wouldn’t know . Causing insolvency between chains. Ofcourse There are methods the reslove this .

• You send tokens from Chain A to Chain B via Axelar

• Axelar burns your tokens on Chain A immediately

• Then tries to execute your contract call on Chain B

• If Chain B fails → your tokens are gone forever

To Resolve this edge case we need emit a message know that in the destination chain that the transaction(tx) was reverted and following-ly , If the emitted message is read by the sender chain [chain A] it should revert the transaction.The Destination chain and the sender chain both need to monitor the emits.

function _deposit(
 address account,
 uint256 amount,
 uint256 duration
 ) private {
 if (_deposits[account] > 0 && amount > 0 && duration > 0) revert
ChangeAmountAndUnlockTimeForExistingAccount();
 if (amount > 0) {
 oneInch.transferFrom(msg.sender, address(this), amount);
 _deposits[account] += amount;
 totalDeposits += amount;
 }
 uint256 lockedTill = Math.max(_unlockTime[account], block.timestamp) +
duration;
 uint256 lockedPeriod = lockedTill - block.timestamp;
 if (lockedPeriod < MIN_LOCK_PERIOD) revert LockTimeLessMinLock();
 if (lockedPeriod > MAX_LOCK_PERIOD) revert LockTimeMoreMaxLock();
 _unlockTime[account] = lockedTill;
 _mint(account, _balanceAt(_deposits[account], lockedTill) /
_VOTING_POWER_DIVIDER - balanceOf(account));
 }

The external function calling this

function depositFor(address _account, uint256 _amount, uint256 _duration) external {
     _deposit(_account, _amount, _duration);
}        

Attacker can front run or block a user by withdraw amount . The depositfor allows to set 0 amount in to contract . Because of it attacker can provide the address of an user account and _duration can be set to any lock duration.

Because of this a user cannot withdraw until the arbitary duration completes, This allows an attacker to front run user deposits . It’s all about how you assume things, This was really easy to find. The more you assume things the more you get .

Thank you ~

Compound Finance is one of the largest Fianace yet . It lets users to deposit their ETH or the acceptable ERC-20 into the contract . Based on the deposited ETH user recieve corresponding amount of cToken. User can redeem their token back by burning the cToken.

It also specially integrates the TUSD , this has rather a special functionality , the compound mostly relies on TUSD if user deposits the TUSD the compound Fi mints the cTUSD.

Vulnerability Details

So the compund Finance allows TUSD as their underlying asset . TUSD has a special functionality, it has double entry point meaning they both have seperate contract addresses but they rely on one single balance. The primary address is used by Compound.

In the compund finance there was a function called sweepToken which is useful for the users who have lost their funds in the contract so , they could recover those funds.

function sweepToken(address _token) external override returns (unit256) {
if (_token == underlyingasset){
revert();
}
uint256 balance = token.balanceof(address(this));
token.transfer(admin, balance);
}

What if we provide TUSD primary asset ofcourse it’d fail on revert since it is an underlying asset. If provide the secondary asset on the _token it send all the balance of the TUSD to admins account . The price of cTUSD is based on the balance of the TUSDN in the contract.

Since the price is zero ‘0’ due to multiplier of token balance in to calculation is zero . Ofcourse there is some calculation of the token. This inconsistent price can advantage of the user.

A malicious user can swap tokens or Borrow token at high price from the protocol and sell off while performing the attack.

Thank you!!!