Full Report
Team Finance, a crypto token launchpad, was hacked. They were attempting to migrate from the Uniswap v2 to v3. This whole project was a safe keeping for funds will some sort of migration was happening. The migrate function for the smart contract had a faulty locking mechanism. The validation checked to see if the address belonged to a ERC20 token. Since this can be controlled by an attacker, they were able to lock their own ERC20 token in it and make the call themselves. Once the bypass on the call was found, they could perform a liquidity transfer to a new attacker controlled Uniswap v3 pair. Then, the leftover liquidity that wasn't transferred was considered the profit of the swap. Alongside the bypass of the caller verification, an attacker could set the initial price of the token in the pool. Now, the transfer was performed with a skewed price, giving the attacker a massive refund as profit. This finding was missed by Zokyo security. A good reference of this issue was on Rekt.news as well. Defense in depth of not letting any token be used in the contract would have solved this problem. The security of the migration function relied upon this. Further analysis was done by Slowmist. Overall, good audits don't solve everything (unfortunately) and migration code should be considered for the security of an eco-system. An interesting bug that allowed the hacker to get a major payout from specifying a bad initial price.
Analysis Summary
# Incident Report: Team Finance Liquidity Lock Exploit
## Executive Summary
In October 2022, Team Finance, a crypto token launchpad, suffered a significant loss during its planned migration from Uniswap v2 to v3. An attacker exploited a faulty locking mechanism within the smart contract's `migrate` function, allowing them to bypass caller verification, transfer locked liquidity to an attacker-controlled pool, and profit by setting a severely skewed token price during the transaction.
## Incident Details
- Discovery Date: Not specified (Implied shortly after the attack in October 2022)
- Incident Date: October 2022
- Affected Organization: Team Finance
- Sector: Decentralized Finance (DeFi) / Crypto Token Launchpad
- Geography: Unknown (On-chain incident)
## Timeline of Events
### Initial Access
- Date/Time: October 2022
- Vector: Smart Contract Vulnerability Exploitation
- Details: Attacker identified a vulnerability in the `migrate` function meant to facilitate liquidity position transfer during the Uniswap v2 to v3 migration. The function incorrectly validated that the address belonged only to an ERC20 token.
### Lateral Movement
- Date/Time: During the exploit execution
- Vector: Unauthorized Execution of Migration Function
- Details: The attacker deployed their own controlled ERC20 token contract. They bypassed the faulty validation by having the attacker-controlled token address pass the check. This allowed the attacker to execute the logic that performed a liquidity transfer to a new Uniswap v3 pool they controlled.
### Data Exfiltration/Impact
- Date/Time: During the exploit execution
- Vector: Price Manipulation and Profit Extraction
- Details: In addition to bypassing validation, the attacker could set the initial price of the token in the destination pool. They performed the transfer with a deliberately skewed price, resulting in a "massive refund as profit" relative to the transferred liquidity. The leftover, untransferred liquidity was also considered profit.
### Detection & Response
- Date/Time: Post-incident/Unknown
- Vector: External Analysis (Implied via external write-ups)
- Details: The mechanism of the attack became public knowledge, referenced in reports by Rekt.news and Slowmist. No specific immediate response actions (like pausing contracts) were detailed in the source text, only the nature of the discovery and external analysis.
## Attack Methodology
This incident focused entirely on smart contract logic and on-chain manipulation rather than traditional network intrusion.
- Initial Access: Identifying and leveraging a flaw in the smart contract's migration logic (specifically the `migrate` function within the Liquidity Locks contract).
- Persistence: Not applicable (Single exploitation sequence).
- Privilege Escalation: Not applicable in a traditional sense, but the attacker escalated their privileges by bypassing the intended caller verification mechanism.
- Defense Evasion: The vulnerability was a logical flaw missed during a security audit, allowing the execution without triggering intended protective measures.
- Credential Access: N/A
- Discovery: The attacker discovered that the logic checking for an ERC20 token address could be controlled by deploying their own ERC20 token.
- Lateral Movement: N/A
- Collection: The attacker manipulated liquidity positions.
- Exfiltration: The unauthorized transfer of locked liquidity to an attacker-controlled Uniswap v3 pair.
- Impact: Financial loss resulting from the transferred liquidity and the large "refund" generated by price manipulation.
## Impact Assessment
- Financial: Significant loss of locked liquidity (exact amount not specified in source).
- Data Breach: Not applicable (No PII or traditional data breach).
- Operational: Disruption to the intended secure migration process for Team Finance assets.
- Reputational: Negative impact stemming from the successful exploit of a pre-launched protocol component.
## Indicators of Compromise
* **Behavioral Indicators:** Execution of the `migrate` function under unusual conditions that resulted in an attacker-defined initial pool price and large liquidity transfer to an external pool.
* **Contract/On-Chain Indicators:** Calls to the Liquidity Locks contract facilitating large, non-standard liquidity transfers during the migration window.
## Response Actions
*The source material does not detail specific containment or recovery actions taken by Team Finance.*
## Lessons Learned
- **Audit Limitations and Migration Risk:** Security audits, even when performed by reputable firms (like Zokyo Security, which reviewed the code), can miss critical flaws, especially in complex migration or update logic.
- **Defense in Depth Failure:** The security of the migration function relied too heavily on a single vulnerability check (the ERC20 token validation). Implementing defense-in-depth, such as prohibiting *any* user-defined token from being used in the contract, would have prevented the exploit.
- **Migration Code Scrutiny:** Code related to contract upgrades, migrations, or changes to ownership/control should be considered the most critical part of an ecosystem's security posture.
## Recommendations
- Implement strict whitelisting or blacklisting for token addresses interacting with critical protocol functions, rather than merely validating token standards.
- Ensure audit scopes explicitly cover edge cases related to migration functions, especially concerning external calls and price setting mechanisms.
- For any financial process involving pre-set pricing or refunds, implement multiple independent verification steps to prevent single points of failure via parameter manipulation.