By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage and assist in our marketing efforts.
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.
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.
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.
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
.
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.
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.
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.
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.
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.
The attacker exploited the fact that neither the routing proxy contract, the routing bridge contract, nor the permissions management contract inspects incoming data.
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.
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.
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.
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.
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.
We have sent email confirmation. Please confirm to receive our
newsletter.
Unfortunately, something went wrong while trying to complete your
request. Please try again later. If the problem persists, do not
hesitate to let us know through the community channels.
