• Hacken
  • Blog
  • Insights
  • Why Team Finance was exploited for $14.5 million, despite its audit

Why Team Finance was exploited for $14.5 million, despite its audit

6 minutes

On 27th October 2022, Team Finance lost $14.5 million due to a smart contract exploit in its migration function. The “v2 to v3 migration function” – the one that caused the exploit – was added a few months after the audit completion by Hacken. 

After they added the “migrate” functionality, Team Finance chose Zokyo as their auditor. Zokyo flagged two vulnerabilities in the said function as critical, but the contract was nevertheless exploited. What went wrong? Let’s review the case to see how the attack unfolded.

Hacken Audit for Team Finance Contracts

When Hacken audited smart contracts for Team Finance, the scope did not contain the “v2 to v3 migration function,” which was exploited in October 2022.

Smart Contract Code Review and Security Analysis Report for TrustSwap

In February 2022, Hacken auditors reviewed and analyzed the smart contract for Team Finance contracts of Trust Swap.

Smart Contract Code Review and Security Analysis Report for TrustSwap

The audit was conducted between January 19th, 2022 – February 2nd, 2022, months before Team Finance added the exploited functionality.

Hacken’s Audit Scope

Location of GitHub Repository including audit scope

At the time of the audit, the scope included three smart contracts:
1. IERC20Extended.sol
2. IPriceEstimator.sol
3.LockToken.sol

Location of GitHub Repository: https://github.com/trustswap/team-finance-contracts
Commit: 8a18a0f7bc3df519236145b7375efe08d94fb192

In our audits, we found 2 medium and 2 low-level issues in the following functions: createMultipleLocks and lockTokens, both in the LockToken.sol contract. These functions have never been exploited. On top of that, the notorious “v2 to v3 migration function” was not featured in the contracts that Hacken audited back in February 2022.

Zokyo Smart Contract Audit for Team Finance

On 8th August 2022, Zokyo delivered a smart contract audit report for TrustSwap. 

Zokyo Smart Contract Audit: TrustSwap (token lock) audit report.pdf
Commit: 3f7f9dc3c6a7c2c7accd2829b160bd2120b9a23c

The Scope of Zokyo’s Audit

The first audit revision:
https://github.com/trustswap/team-finance-contracts/tree/master-merge-nft-liq-v2v3-migrate
The second audit revision:
https://github.com/trustswap/team-finance-contracts/tree/master-merge-nft-migrate-nftsvg

The contracts audited by Zokyo:
1. LockNFT.sol
2. NFTDescriptor.sol
3. NFTSG.sol
4. LockToken.sol

Zokyo was really close to finding the ‘culprit’

In their audit report on Page 8, Zokyo showed a detailed breakdown of “migrate” function. 

migrate() function breakdown

They described “v2 to v3 migration” functionality, “Migrates liquidity to v3 by burning v2 liquidity and minting a new position for v3. Initializes the pool if it has not been initialized yet. Refunds Ether or tokens. Updates token details.”

Zokyo auditors found two critical vulnerabilities in Team Finance contracts, including issues in migrate() function: use of arbitrary token addresses and reentrancy in main functions.

  • Use of arbitrary token addresses
Use of arbitrary token addresses
  • Reentrancy in main functions
Reentrancy in main functions

Zokyo did audit the “v2 to v3 migration” function and flagged it as critical. In both cases, Zokyo recommended using the nonReentrant() modifier. Team Finance responded to these critical issues post audit, “TrustSwap team verified that this is an intended logic and users should be able to use arbitrary token addresses.” On paper, Zokyo found the critical issue. TeamFinance verified it. The exploit nevertheless happened. So what went wrong?

Analysis from Hacken

Hacken’s Head of the Smart Contracts Audits Department offered the following explanation for the hack and found the issue:


The exploit happened due to the vulnerability in the ‘migrate’ function.

Why did it happen?

The code lacked input parameters validation, parameters that go directly into the v3migrator.

What could’ve been done (and was actually done as a fix)?

First, ensure ‘pair’ and ‘tokenAmount’ input parameters match the ones from the ‘lockedERC20’ structure stored on the contract.

Second, ensure the validity of some other parameters.

Did Zokyo find the right issue?

At first glance, it appears Zokyo spotted the issue. They did flag it as critical. But if we dive deeper, we see that Zokyo was very close to finding the issue, but couldn’t get to the bottom of it. It should have been formulated differently.

What is the issue mentioned in the Zokyo report?

The issue in the Zokyo report is about the missing whitelist for tokens. However, even if the whitelist was added, the real vulnerability would still be in the code. Whitelist does not solve the problem! You can still deposit whitelisted tokens and exploit the system.

Luckily, funds were returned to TeamFinance. But the whole crypto ecosystem has something to learn about in this case.

Lessons Learned

Audit Relevancy

Adding/updating functionality to the code changes it. The audit is no longer relevant after the code changes. To stay relevant and detect new vulnerabilities, projects must audit the contract after introducing any changes. Team Finance did audit the code after introducing new changes. Unfortunately, Zokyo couldn’t fully detect a real critical weakness.

Audit is relevant only when audited code fully matches deployed code

Is the audit still relevant?
✅ Option 1 – no changes made. Answer: Yes, the audit is still relevant because the deployed version fully matches the code. 
❌ Option 2 – changes were released. Answer: No, the audit is irrelevant, as we cannot guarantee its safety or what weaknesses it has now.   

This certainly is a hard lesson for those involved, but Web3 players must understand that hackers aren’t going anywhere. Bad actors will always look for weaknesses they can exploit to steal funds. In response, Web3 projects must pay more attention to security. Audit relevancy is vital for smart contract security. It’s necessary to perform external code reviews after all significant changes to the code. For everyone interested in audit relevancy and checking whether the audited code matches the deployed code, we recommend monitoring CER.live – the biggest independent database of crypto audits.

Get to the root cause of vulnerabilities

For auditors, the lesson is to be a bit more persistent, especially when it comes to critical issues. Finding and conveying all possible vulnerabilities is really difficult, but that’s what makes you an exceptionally good auditor. At the end of the day, the auditor vouches for the final score with their reputation.

Subscribe
to our newsletter

Be the first to receive our latest company updates, Web3 security insights, and exclusive content curated for the blockchain enthusiasts.

Speaker Img

Table of contents

  • Hacken Audit for Team Finance Contracts
  • Zokyo Smart Contract Audit for Team Finance
  • Analysis from Hacken
  • Lessons Learned

Tell us about your project

Follow Us

Read next:

More related

Trusted Web3 Security Partner