Full Report
Before even diving into the target itself, the author goes through how they themselves pick a target. Ecosystem: the more mature the thing, the more bugs it's going to have. TVL range: very large, lots of auditors, very small, fewer audits. Project type: knowing common pitfall in specific functionality can quickly allow for understanding a project. Forks: if a bug is found in a project with many forks, then many things are vulnerable. Additionally, changes to forks can be easily diffed. They then talk about going for depth, breath and speed. Since they were browsing this in their free time, I'm guessing they were looking for going for speed. They tend to look for things with a TVL of 5M+ and nice bug bounties. The sendFrom() function is responsible for sending staked users' tokens across chains. Additionally, a user can allocate allowance to another user for these cross-chain calls. Inversely, the function _debtFrom() checks that the user calling sendFrom() has been allocated the proper allowance from the send address. If this is true, it burns the tokens then sends them off to another chain. The allowance check is where the bug sits. Instead of checking the classic mapping of owner->spender->amount as they should, it instead was checking spender->spender->amount. Since an attacker now controlled both of these, they could allow themselves to spend their own value then spend the funds of other users arbitrarily. Yikes! This attack could have stolen $3M worth of funds. It's insane that such a simple bug went through the cracks through audits. Good find none-the-less.
Analysis Summary
# Vulnerability: Premia Finance Cross-Chain Allowance Logic Error
## CVE Details
- **CVE ID**: Not Assigned (DeFi Protocol Bug)
- **CVSS Score**: 9.1 (Estimated)
- **Severity**: Critical
- **CWE**: CWE-285 (Improper Authorization) / CWE-639 (Insecure Direct Object Reference)
## Affected Systems
- **Products**: Premia Finance (Staking/OFT Infrastructure)
- **Versions**: Protocol versions prior to July 31, 2023.
- **Configurations**: Instances utilizing the `sendFrom()` and `_debtFrom()` functions for cross-chain transfer of staked tokens (xPREMIA).
## Vulnerability Description
The vulnerability resided in the `_debtFrom()` internal function, which is responsible for verifying that a caller (spender) has the necessary allowance to spend tokens on behalf of another user (owner) during a cross-chain transfer.
In a standard ERC-20 implementation, the allowance check should validate the mapping of `allowance[owner][spender]`. However, the vulnerable code mistakenly checked `allowances[spender]`. Because the logic used the spender's own address as the key for the allowance mapping rather than the token owner's address, an attacker could grant themselves an allowance on their own account and then use that "self-authorized" allowance to burn and bridge tokens belonging to any other user.
## Exploitation
- **Status**: PoC available (Discovered by Zellic; not exploited in the wild).
- **Complexity**: Low
- **Attack Vector**: Network (Smart Contract Interaction)
## Impact
- **Confidentiality**: None
- **Integrity**: Critical (Unauthorized transfer and burning of user assets).
- **Availability**: High (Loss of user funds).
- **Financial**: Effectively put $3M TVL (Total Value Locked) at risk.
## Remediation
### Patches
- **Status**: Fixed as of July 31, 2023.
- The protocol updated the `_debtFrom()` function to correctly reference the `from` (owner) address when checking the allowance mapping:
`uint256 allowance = allowances[from][spender];`
### Workarounds
- No manual workarounds for users were required as the protocol team patched the smart contract logic directly.
## Detection
- **Indicators of Compromise**: Unexpected `Transfer` or `Burn` events on staked tokens where the `from` address did not initiate the transaction.
- **Detection Methods**: Static analysis of allowance-related logic in forked or custom Omnichain Fungible Token (OFT) implementations. Specifically, auditing for logic where `msg.sender` or `spender` is used where the `owner` (the person whose funds are being moved) should be.
## References
- **Zellic Research Advisory**: hxxps://www.zellic.io/blog/browsing-for-bugs-3m-bug-in-premia-finance/
- **Premia Finance**: hxxps://premia.finance/