Incident Summary
On Sep-26-2024 06:28:23 PM UTC, a vulnerability in the uniBTC smart contract was exploited, allowing the exploiter to mint 30.8 uniBTC and swap them for wBTC in Uniswap pools. In response, we paused the vulnerable contract and implemented a fix to mitigate the vulnerability, which was later confirmed to have affected approximately $2 million in liquidity, primarily within the Uniswap pool.
The vulnerable contract was deployed across eight different chains: Ethereum, BNBChain, Arbitrum, Optimism, Mantle, Mode, BOB, and ZetaChain. A total of 125 exploiters are identified (refer to appendices).
Following the fix, we can confirm that all assets in reserve remain secure. We have conducted a thorough investigation into the root cause of the exploit, and below is a comprehensive report detailing the incident.
*Please note that the vulnerability is limited to the uniBTC smart contract only. Other Bedrock assets, uniETH and uniIOTX, are safe and completely unaffected by this incident.
Timeline of the Events
Sep-25-2024
- 06:17:00 AM UTC: Vulnerable code deployed
Sep-26-2024
-
04:27 PM UTC (00:41 AM local time): Issue reported by Dedaub
-
04:41 PM UTC: War room on Seal 911 created on Telegram
-
06:28 PM UTC: Exploiter transaction on Ethereum
-
06:34 PM UTC: Bedrock Incident response team got notified
-
09:03 PM UTC: Bedrock paused smart contracts
Sep-27-2024
- 05:39 AM UTC: Bedrock posted an announcement tweet after checking all contracts and verifying the vulnerability
Root Cause Analysis
The uniBTC contracts are designed to enable users to convert their BTC assets into an equivalent amount of uniBTC tokens. By design, minting uniBTC using native tokens on non-native BTC chains should NOT be allowed, as the native token no longer represents native BTC.
Specifically, in the Vault contract, there are two ways to enforce this:
-
Pause mechanism
-
Caps restriction
The handling of native tokens differs from wrapped tokens because msg.value is already transferred into the contract. As a result, the check on Line 170 does not need to account for the _amount transferred, unlike the check on Line 184. Therefore, if the cap is set to 0, the mint function will revert for native tokens.
The vulnerability lies within the SigmaSupplier (Sigma) contract.
First, tokens must be registered to be included in the current total balance of native or wrapped BTC tokens. Second, if a token is not registered, the contract returns 0, meaning it cannot be found in the tokenHolders variable. The following figure shows that only FBTC, WBTC, and cbBTC have been registered, while NATIVE_BTC has NOT. On one hand, NATIVE_BTC should NOT be registered in this contract, as it is not intended to be supported. On the other hand, failing to register NATIVE_BTC results in the totalSupply always being ZERO, which contradicts the caps restriction mechanism.
Since the total supply at that time was ZERO instead of reflecting the msg.value received by the contract, the check the Vault contract passed, allowing the minting of uniBTC using native tokens on non-native BTC chains.
Therefore, on a non-native BTC chain, replacing the balance with the total supply is acceptable for wrapped BTC tokens but problematic for native tokens.
Credits to Blocksec who confirms our fix and conducts an independent analysis report (refer to appendices)
Mitigation & Recovery
Integration with Chainlink for Proof of Reserves (PoR): This integration will enhance transparency and trust by allowing users to verify that we hold sufficient reserves to back uniBTC. By utilizing Chainlink’s reliable oracles, we aim to provide real-time data and assurance to our community regarding our asset backing.
Development of Unstaking Functionality: We are currently in the process of enabling the unstaking functionality, which will allow users to withdraw their staked assets easily. We will keep our community updated on the development timeline.
Redeployment of DEX Liquidity: Following the completion of new audits, we will launch an LP incentive program and work with partners to redeploy liquidity to decentralized exchange (DEX).
uniBTC 1:1 Redemption: We guarantee uniBTC can be 1:1 redeemed, ensuring that for every unit of uniBTC, there is a corresponding equivalent amount of BTC available. This guarantees our users that their investments are secure, providing confidence in the stability of our platform.
Bounty & Airdrop Plan
For Exploiters
We invite those who exploited the contract to contact us via bounty@bedrock.technology for bounty solutions. We believe in transparency and collaboration and are open to finding a mutually beneficial resolution.
For uniBTC holders
Each uniBTC holder (snapshot at Sep-26-2024 06:28:23 PM UTC) will receive an airdrop of 100 Bedrock Diamonds as an appreciation for the continued support. Additionally, Bedrock’s token airdrop ratio to community will be increased by 0.5% to further benefit our loyal users.
Preventative Measures
-
Conduct Further Security Audits. We will perform additional rounds of security audits on smart contracts, continuously enhancing the security of the entire architecture.
-
Enhance Monitoring Measures. Establish a 7x24 real-time security monitoring mechanism.
-
Set up Bedrock Security Fund. Upon TGE, we will initiate a governance proposal of the Security Fund. The security fund is used to take necessary and possible rescue measures for asset losses.
-
Launch Bug Bounty Program. We encourage the community to continue to review our code. We will work with a security audit platform to launch a Bug Bounty program.
Shout-outs to everyone who reached out to offer help at the critical moment. We are especially thankful to Dedaub for their prompt notification upon discovering the vulnerability. Our sincere appreciation also goes to SEAL911, BlockSec, PeckShield, Certik, SlowMist and all the partners and community members who contributed their support.
Appendices
Official Links
Website | App | Documentation | Twitter | Discord