Transit Swap Hack Analysis

Transit Swap Hack Analysis

Overview

Another platform that was abused by cryptocurrency fraudsters was Transit Swap, a DEX integrator. On 2 October 2022, a hack happened that cost around $21 million. Inadequate validations and the approval of illegitimate contracts led to the permanent loss of $1.4 million to a black hole.

Attack Overview

Due to improper input validations, the contract’s function did not appropriately validate data. By taking advantage of it, the hacker stole almost $21 million in tokens from clients who had authorized the contract.

The claimToken()method in the transit swap permission management contract did not validate inputs submitted by attackers, i.e., if the address passed as an argument actually belonged to the owner who was using the function.

• Vulnerable Code: 0xed1a
• Attacker’s Address: 0x75f2
• Attacker’s Transaction: 0x181a, 0x743e
• Attacker Returned Token Address: 0xD989

Smart Contract Hack Analysis

Here’s how the attack works:

• Anyone may enter any user’s address in the callData to the routing bridge contract permission’s management contract (0xed1a)
• When an attacker invokes the routing proxy contract, the permission management contract (0xed1a) will execute transferFrom(), transferring money from innocent users to the attacker’s address.
• The permission management contract does not validate the owner’s account address; thus, anybody may query it without being the owner and pass it to claimToken(), which would then transfer all the tokens in that user’s account to the attacker’s account.
• All users who authorized the permission management contract were exposed to this, and the attacker drained all the tokens.

Vulnerability Analysis:

• We need to get to the assembly-level implementation in order to comprehend the hack because the code was made secret and is not immediately accessible to the public. https://bscscan.com/bytecode-decompiler?a=0xed1afc8c4604958c2f38a3408fa63b32e737c428
• The built data from the routing proxy contract is passed to the callBytes method of the routing bridge contract.
• The attacker’s exchange contract, which contains the address of the permissions management contract, and redemption data, which is intended to invoke the ‘claimTokens’ function, are parsed by the callBytes function.
• The above callData is sent to the routing bridge contract for the purpose of exchanging the tokens, and neither the routing proxy contract nor the routing bridge contract nor the permissions management contract verifies the incoming data.
• The route bridge contract does not verify the parsed swap contract address and call data since the address of the swap contract, and the call data are both specified by the upper-layer route proxy contract (0x8785bb.. )
• The code does not verify the contract’s owner and permits illegal addresses to be manipulated, allowing an attacker to swap tokens and move them to his own account by sending a user’s account address as the “from” address and his own address as the “to” address resulting in stealing victim’s token.

Smart Contract Security Mitigation & Best Practices:

• There should be input validation on all the critical parameters.
• Access control must be properly implemented, and only the contract owner should be allowed to perform any transactions.
• Making code available to the public improves contract confidence and could have helped white-hat hackers and auditors find and disclose vulnerabilities before they were exploited.

You can rely on SolidityScan, a cloud-based smart contract vulnerability scanner, to ensure that the proper steps are taken to achieve the highest level of smart contract security. Signup for a free trial at https://solidityscan.com/signup