Full Report
Cronos is a Cosmos based chain that uses Ethermint as the smart contract runtime platform. They have the largest TVL within the Cosmos system. Reentrancy is a vulnerability class where a user can execute some smart contract functionality, make an external call while the state is partially updated then abuse this partially updated state. It is a unique and common bug class to Solidity. Within the TectonicStakingPoolV3, a user can call the function performConversionForTokens() with a path of different tokens. However, this doesn't contain an allowlist or checks for reentrancy. Using the lack of protections, an attacker can stake their balance part way through the swap path. Why is this bad? Both before and after doing the swap, there is a call to balanceOf for TONIC on the current contract. The sent in amount of TONIC is thought to be amount that the user now has, crediting them all of this. By calling stake() part way through the execution of this, an attacker can send in tokens as part of the stake. So, they get counted both as the stake and as part of the transfer, leading to a double use of the TONIC. By repeating this over and over again, it's possible to steal almost all of the funds from the protocol. The response from Cronos is why this caught my attention. Cronos deemed that since this had a 10 day waiting period and they had sufficient monitoring in place that this wasn't a risk. So, instead of a large payout, they were going to give them 2K and move on. Immunefi rejected this, claimed it deserved a max payout then kicked Cronos off the platform when they refused. To me, 2K is too low but a max payout is too high. Defense-in-depth measures need to be taken into consideration. The timelock is sufficient to me to lower the impact but should still be high high or a low critical. I don't like the precedent of having private monitoring tools as a silver bullet. 1) they can't be audited and 2) how do we know that people will respond to it correctly? Regardless, good finding and it's a bummer that they didn't pay out for this.
Analysis Summary
# Vulnerability: Reentrancy in TectonicStakingPoolV3 Leading to Free xTonic Minting
## CVE Details
- CVE ID: Not specified in the provided context.
- CVSS Score: Not specified. **(Impact severity suggested as High/Critical based on the description of near-total fund drain.)**
- CWE: CWE-839 (Improper Restriction of Access to Sensitive (Write) Operation - *Inferred based on reentrancy leading to unauthorized state change/minting.*)
## Affected Systems
- Products: Cronos Chain (Cosmos-based chain utilizing Ethermint), TectonicStakingPoolV3 smart contract.
- Versions: The specific vulnerable contract address implies the deployed version: `0xE165132FdA537FA89Ca1B52A647240c2B84c8F89`.
- Configurations: The vulnerability is predicated on `tcmPublicAccess` being `true` in the Token Conversion Module, allowing public calls to `performConversionForTokens()`.
## Vulnerability Description
A reentrancy vulnerability exists within the `TectonicStakingPoolV3.sol` contract during the execution of the `performConversionForTokens()` function. This function facilitates swapping tokens held by the pool for TONIC, crediting any surplus to the caller as a reward.
The flaw arises because:
1. The function calculates `tonicBalanceBefore` (for TONIC held by the contract).
2. It performs the swap via delegatecall to the Token Conversion Module.
3. During the swap, an attacker, by injecting a malicious token into the swap path, diverts execution flow to an attacker-controlled contract.
4. The attacker contract invokes `stakingPool.stake()` *before* the contract calculates the final state (`tonicBalanceAfter`).
5. The staking action mints `xTonic` and erroneously credits the attacker with the TONIC balance, effectively counting the newly staked tokens both as a stake and as a swap surplus "reward."
This condition allows an attacker to repeatedly mint `xTonic` for free by leveraging the underlying TONIC tokens in the pool, leading to nearly complete extraction of protocol assets.
## Exploitation
- Status: Proof of Concept (PoC) documented, detailing how an attacker with $\approx\$23,000$ in TONIC could steal over $\$2,500,000$ in a single transaction by repeating the attack.
- Complexity: Medium (Requires setting up a custom malicious token, swap pairs, and a reentrancy exploiting contract structure).
- Attack Vector: Network (Remote unauthorized contract interaction).
## Impact
- Confidentiality: Low (No direct exposure of private data mentioned).
- Integrity: Critical (The attacker can mint tokens and steal the majority of the protocol's assets).
- Availability: High (The pool's liquid capital can be completely drained).
## Remediation
### Patches
- The context notes that Cronos initially viewed the 10-day waiting period as mitigating the risk, implying a delay in immediate patching based on their internal assessment. **No specific patch version or fix implementation is detailed in the summary.**
### Workarounds
- **(Mentioned by Cronos as sufficient but disputed):** A 10-day waiting period (timelock) on execution.
- **(Implied fix from the vulnerability analysis):** Implement standard reentrancy guards (e.g., Checks-Effects-Interactions pattern, OpenZeppelin ReentrancyGuard) around the swap and staking logic, ensuring all state changes are finalized before external calls, or disallowing external calls mid-process.
- Removing public access to `performConversionForTokens()` if `tcmPublicAccess` is not strictly necessary.
## Detection
- **Indicators of Compromise (IoCs):** Unusually high rates of `stake()` calls immediately following or concurrent with complex multi-token swap transactions involving `performConversionForTokens()`. Rapid and unauthorized inflation of `xTonic` supply relative to staked TONIC entering the system.
- **Detection Methods and Tools:** The reporter noted that reliance on "private monitoring tools" was cited by Cronos as a defense measure, but this method is considered insufficient as it cannot be externally audited or guarantee a timely response. Standard runtime monitoring for state inconsistencies during large DeFi operations would be key.
## References
- Vendor advisories: None explicitly cited, but a dispute with Immunefi and acknowledgment by Cronos are detailed.
- Relevant links - defanged:
- Gist containing report and PoC: gist.github.com/fatherGoose1/690fa2d8245488b6750b67a0fdeb34bc
- Cronoscan address for TectonicStakingPoolV3: cronoscan.com/address/0xE165132FdA537FA89Ca1B52A647240c2B84c8F89