Decoding Transit Finance’s Contract Vulnerability

TL;DR

On October 2nd, 2022, Transit Finance lost $21 million after a vulnerability in their code-base allowed a hacker to drain the wallets of users who had approved the protocol’s swap contract.

Introduction to Transit Finance

Transit Finance is a multi-chain DEX aggregator that chooses and combines popular DEXs from public chains to improve transaction depth and yields.

Vulnerability Assessment

The vulnerability existed in the project’s code, but the attacker specifically targeted users by exploiting a weakness in the transferFrom function. The Transit Swap protocol did not strictly validate the data sent in by the user during token exchange, resulting in an arbitrary external call that the hacker exploited to steal approved tokens from users.

Any tokens approved for trading on Transit Swap could be sent directly from the user’s wallet to the address of the exploiter.

Steps

1. The smart contracts of the project are closed-source contracts. The published byte-code was decompiled to determine that the underlying cause of this vulnerability was a controllable transferFrom external call.
2. The first attack transaction by the exploiter lasted around thirty minutes until tokens were exchanged for ETH and BNB on the respective chains. The exploited transaction to drain all the funds can be seen in thorugh this Etherscan details.
3. When a user initiates a swap through Transit Swap, they initially pass through the routing proxy contract. Different contracts for routing bridges are selected based on the type of exchange.
4. The routing bridge contract will transmit the claimTokens function of the permissions management contract, which requires user authorization prior to token exchange. The claimTokens function then transfers the tokens to the routing bridge contract to be redeemed by the user.
5. The claimTokens function transfers funds by running the transferFrom function of the specified token contract. The parameters are unconstrained, except that the caller must be either a routing proxy contract or a routing bridge contract, and passed in by the upper-layer routing bridge contract.
6. After receiving the tokens to be exchanged by a user, the route bridge contract will then invoke the swap contract for specified swap operations. The address of the swap contract and the call data are all established by the upper-layer route proxy contract; therefore, the route bridge contract does not validate the the parsed swap contract address and call data.
7. The parameters sent by the route proxy contract to the route bridge contract likewise originate from the user-supplied parameters. The route proxy contract verifies just that the length of each data in the user-supplied calldata meets the expectations and that the called route bridge contract is the address in the whitelist mapping, but does not examine the calldata itself.
8. The attacker exploited the fact that neither the routing proxy contract, the routing bridge contract, nor the permissions management contract inspects incoming data.
9. With the constructed data from the routing proxy contract, the callBytes function of the routing bridge contract is invoked. The callBytes function decodes the attacker’s exchange contract and redemption data, where the exchange contract is the address of the permissions management contract and the redemption data is a call to the claimTokens function.
10. The claimTokens function is then used to transmit the tokens of the selected user to the token address of the attacker. This is accomplished by stealing tokens from all authorized users of the permissions management contract.

Aftermath

The hacker has returned over 83% of the stolen assets after the involvement of multiple security firms.

The project team continued to collect specific data from stolen users in order to develop a return plan for those affected by this incident.

How to prevent such an attack vector

Hiding contract code makes lengthy investigation practically impossible and impedes hackers’ ability to find vulnerabilities before they are exploited. Each protocol must take the appropriate procedures to include all validated contracts into its operations.

Hacks, exploits, frauds, and smart contract vulnerabilities are all too common in the blockchain world, and a DeFi team’s requirement to keep closed source code raises a lot of suspicion. Is this an insider job involving the use of privileged information against their users for yet another form of business marketing? We will let time decide on everything.

Protocol, and Platform Security

Our security team at Neptune Mutual can validate your platform for DNS and web-based security, smart contract reviews, as well as frontend and backend security. We can offer you a solution to scan your platform and safeguard your protocol for known and unknown vulnerabilities that have the potential to have catastrophic long-term effects. Contact us on social media if you are serious about security and have the budget, desire, and feeling of responsibility to do so.

About Us

Neptune Mutual project safeguards the Ethereum community from cyber threats. The protocol uses parametric cover as opposed to discretionary insurance. It has an easy and reliable on-chain claim process. This means that when incidents are confirmed by our community, resolution is fast.

Join us in our mission to cover, protect, and secure on-chain digital assets.

Official Website: https://neptunemutual.com
Blog: https://blog.neptunemutual.com/
Twitter: https://twitter.com/neptunemutual
Reddit: https://www.reddit.com/r/NeptuneMutual
Telegram: https://t.me/neptunemutual
Discord: https://discord.gg/2qMGTtJtnW
YouTube: https://www.youtube.com/c/NeptuneMutual
LinkedIn: https://www.linkedin.com/company/neptune-mutual