Full Report
Optimism is a L2 sidechain of Ethereum. There are several bridges that allow for the taking of assets from L1 to L2 by creating a wrapped variant of the asset. One of these bridges is BitBTC. When going from L2 to L1, a user can specify the token in which they would like unwrap. Part of the unwrapping is finding the proper L1 token to use when going back to the other chain, Ethereum. The L1 bridge completely ignores the L2 token and simply mints the L1 token! This means that an attacker can create an arbitrary token on Optimism (which anybody can do) with all of the supply and set the L1Tokens address to be the L1 address. Using this, they could steal all of the tokens from BitBTC. Luckily, this bug would take 7 days to exploit... where somebody would likely notice. The author posted this on Twitter, hoping that the BitBTC team would respond. Eventually, they did and fixed the bug. It's amazing how bad the security of many of these platforms is. You think that handling this much money would require a deep look into the implications of the code written.
Analysis Summary
# Vulnerability: BitBTC Bridge Arbitrous Token Minting Logic Flaw
## CVE Details
- **CVE ID:** N/A (No CVE was officially assigned to this specific protocol bug)
- **CVSS Score:** 9.3 (Critical) - *Estimated based on total loss of funds*
- **CWE:** CWE-670: Always-Incorrect Control Flow Implementation / CWE-20: Improper Input Validation
## Affected Systems
- **Products:** BitBTC Bridge (L1-L2 cross-chain bridge)
- **Versions:** All versions prior to the January 2022 patch
- **Configurations:** Ethereum L1 and Optimism L2 bridge contracts
## Vulnerability Description
The flaw existed in the cross-chain unwrapping logic of the BitBTC bridge. When a user initiated a transfer from Layer 2 (Optimism) back to Layer 1 (Ethereum), the L1 bridge contract responsible for releasing the funds failed to validate that the L2 token being burned was a legitimate, authorized representative of the L1 asset.
Specifically, the L1 bridge contract would accept the user's input for the "L1Token" address and simply mint or release those assets on Ethereum, provided the message came through the standard cross-chain messenger. This lacked a security check to verify the 1:1 mapping between a specific L2 token address and its L1 counterpart.
## Exploitation
- **Status:** PoC disclosed; reported to the team via public channels; not exploited in the wild.
- **Complexity:** Low (Requires creating a custom ERC-20 token on L2)
- **Attack Vector:** Network (Cross-chain message passing)
## Impact
- **Confidentiality:** None
- **Integrity:** Total (Attacker could mint/withdraw tokens they did not rightfully own)
- **Availability:** High (Liquidity exhaustion of the bridge)
## Remediation
### Patches
- The BitBTC team updated the bridge smart contracts to include a validation step that strictly maps L2 token addresses to authorized L1 token addresses.
### Workarounds
- **7-Day Withdrawal Delay:** The inherent 7-day challenge period of Optimism acted as a natural buffer, allowing the vulnerability to be identified and patched before any malicious withdrawal could be finalized on L1.
## Detection
- **Indicators of Compromise:** Monitoring for large-volume withdrawal requests originating from unknown or recently deployed token contracts on the L2 side.
- **Detection Methods:** On-chain auditing of bridge contract state changes, specifically tracking "WithdrawalInitiated" events where the token address does not match known bridge assets.
## References
- hxxps[://]twitter[.]com/kelvinfichter/status/1450259838031388675
- hxxps[://]optimism[.]io/
- hxxps[://]github[.]com/ethereum-optimism/optimism