Full Report
Tecra (TCR) is some ERC20 token. A burn in ERC20 is the destruction of a token; literally removing it from the total supply. Although this doesn't seem useful at first glance, pools rely on the amount of tokens in a pool to determine the price. The price isn't USD to token. The price is proportional to the pool ratio itself; trade 5 of token A for 2 of Token B. In ERC20, there is a concept called allowances. This allows other addresses to spend money on your behalf. The map for this is allowances[OWNER][SPENDER]. The check for burning as another user was written in reverse though: allowances[SPENDER][OWNER]. So, an attacker could burn tokens in an arbitrary account! The unlimited burn was exploited in a Uniswap pool. By removing the TCR tokens owned by the pool with the unlimited burn vulnerability, the ratio for the AMM got messed up. This resulted in extremely expensive TCR tokens to buy and really cheap of the other token in the pool. Step by step, this was exploited as follows: Approve a big number of tokens to the uniswap pool. This is crucial, since the burnFrom messed up the ordering. So, to satisfy the require, we must allow the pool to access our tokens. Buy 101 TCR tokens from the pool. Use the unlimited burn vulnerability remove the TCR tokens from the pool. This will increase the price of TCR drastically. Sell back the TCR take make a large profit from the other token in the pool Overall, a really bad vulnerability that is not uncommon to make. It's interesting this even got through QA testing.
Analysis Summary
# Vulnerability: Incorrect Access Control in Tecra (TCR) Token burnFrom Logic
## CVE Details
- **CVE ID:** Not explicitly assigned (Commonly tracked in DeFi security databases via the transaction hash or smart contract address).
- **CVSS Score:** 9.1 (Critical) - *Estimated based on the total loss of funds and unauthorized state changes.*
- **CWE:** CWE-284: Improper Access Control; CWE-696: Incorrect Behavior Order.
## Affected Systems
- **Products:** Tecra (TCR) Smart Contract.
- **Versions:** Original TCR ERC20 deployment on Ethereum.
- **Configurations:** Interactions involving decentralized exchanges (DEXs) like Uniswap where the contract is used in automated market maker (AMM) liquidity pools.
## Vulnerability Description
The flaw resides in the `burnFrom` function of the TCR smart contract. In a standard ERC20 implementation, an allowance check ensures that a `SPENDER` can only burn/transfer tokens owned by the `OWNER` if they have been granted permission.
The logic in TCR was implemented in reverse:
- **Expected:** `allowances[OWNER][SPENDER]`
- **Actual:** `allowances[SPENDER][OWNER]`
This inversion allowed an attacker to bypass the authorization check. If an attacker granted an allowance to a target (such as the Uniswap V2 pair address), the contract would incorrectly validate that the *target* had permission to spend the *attacker's* tokens, but then proceed to execute the burn against the target's balance.
## Exploitation
- **Status:** Exploited in the wild.
- **Complexity:** Low (Requires basic understanding of AMM mechanics).
- **Attack Vector:** Network (Smart Contract Interaction).
## Impact
- **Confidentiality:** None.
- **Integrity:** High (Unauthorized destruction of token supply).
- **Availability:** High (Liquidity pool exhaustion and price manipulation).
## Remediation
### Patches
- The original contract is immutable on the blockchain. A new version of the token (TCR 2.0 or patched contract) must be deployed, and liquidity migrated to the new address.
### Workarounds
- Users and liquidity providers are advised to withdraw liquidity from pools interacting with the vulnerable TCR contract address.
- Exchange platforms should delist or disable trading for the affected contract.
## Detection
- **Indicators of Compromise:** Unusual `burn` events where the caller is not the owner of the tokens; sudden, massive price spikes in TCR/ETH or TCR/USDT pairs on AMMs due to artificial supply reduction.
- **Detection methods and tools:** Manual code audit of the `burnFrom` function; automated static analysis tools (e.g., Slither, Mythril) can detect incorrect use of mapping keys and authorization flaws.
## References
- [hxtps://etherscan.io/address/0xe38B35EB5f3032d8C37759902640523C6ED93836] (Defanged Contract Link)
- [hxtps://coinmarketcap.com/currencies/tecra-coin/] (Defanged Market Data)