QANX Bridge wallet disclosure analysis [continuously updated]
Original post: October 11, 2022
Last update: February 22, 2023
Update: February 22, 2023
We are pleased to announce the commencement of the QANX Token relaunch process.
On the 11th of October, 2022 the QANX Bridge deployer wallet suffered an attack.
At 08:16:39 AM +UTC the exploiter was able to drain 1,444,169,100.98 QANX from the QANX Bridge on Binance Smart Chain (BSC) and sold it for 3090.5 BNB on PancakeSwap which was later tunnelled into Tornado Cash.
At 08:17:59 AM +UTC the exploiter was able to drain 1,431,880,339.45 QANX from the QANX Bridge on Ethereum and sold it for 255.4 ETH on Uniswap which was later tunnelled into Tornado Cash.
QANplatform tweeted an announcement warning people not to perform any transactions with $QANX at 09:01 AM +UTC. All trading, withdrawals, and deposits on centralised exchanges had been paused.
Uniswap and PancakeSwap liquidity were both withdrawn at 09:41:23 AM +UTC, and 09:51:51 AM +UTC respectively to protect token holders.
Let’s dive right into the details to have a deeper understanding of what happened.
Is this attack related to the QANX Bridge at all?
This was a common misconception among analysts investigating the case most of whom believed that the exploit is related to malfunctioning of the QANX Bridge. Only the QANX Bridge smart contract deployer wallet was compromised as it was created using an open source vanity address calculation algorithm called cenut/vanity-eth-gpu which is a derivative of a compromised upstream project called johguse/profanity.
What is a vanity address?
As the name suggests, vanity addresses have the benefit of easy recognisability. Generating such addresses have high resource requirements (expensive graphic cards). As a result a lot less malicious attackers can generate fake addresses looking familiar to legitimate addresses. In this particular case the goal was to make official QANplatform addresses (token and bridge) start and end with triple “A“ (0xAAA…AaA) character sequence. While this does not fully prevent malicious attackers having the required resources from generating similarly looking addresses, it prevents the majority of them from doing so.
How could the QANX Bridge deployer wallet get compromised?
The upstream project which the wallet address generated tool was derived (forked) from had a fundamental security issue related to low entropy levels. In general the tool started out from 32bits of entropy and expanding that to 32bytes of secp256k1 private keys. Since the starting point was static it is fairly easy to regenerate any address along the same logical path given the required hardware resources.
Did this vulnerability affect other wallets as well?
Yes, the upstream fundamental security issue recognised in Profanity affected probably thousands of wallets throughout the entire blockchain ecosystem including publicly known projects like: Indexed Finance, The SolaVerse, ParaSwap, and Curve. The interesting fact that the latter handled TVL $5.91 billion but the attack was luckily stopped in time. Wintermute was not so lucky, where $160 million was stolen due to the vanity address vulnerability. To ensure that your wallet and all your tokens are safe in the future migrate to a new wallet if you used Profanity before.
Is this attack related to QANplatform’s quantum-resistant security?
No, the exploited vulnerability relies on improper private key seeding, it has nothing to do with QANplatform’s core technology using NIST recommended Crystals Dilithium post-quantum algorithm, nor any other QANplatform specific technology. This is a generic issue related to the Profanity address generator only.
How can this be mitigated in the future?
Mitigation requires either avoiding vanity addresses, fix the vanity address generator tool itself to seed private keys properly, or replace the owner of the generated vanity address contract to a securely generated one. All 3 options are viable, the QANplatform team will go with the most secure option.
Will $QANX token holders get compensated?
Yes, all $QANX token holders will get compensated who have purchased tokens in the timeframe between the execution of the attack and the warning announcement (to stop trading activities) published by QANplatform.
What are the next steps?
If you are $QANX token holder make sure that you do not conclude any trading activities (buying/selling/liquidity providing) neither on decentralised trading platforms nor centralised ones. Please also refrain from participating in OTC transactions until further official information. This is important so that a fair balance-restoration process can be designed.
The QANplatform team and its partners are already in touch with all exchanges to ensure a smooth transition to a new token with a fair balance restoration process to ensure that $QANX token holders are the least affected by today’s happenings.
Update: October 12, 2022
QANplatform team and its partners are closely working together on designing the balance restoration process. As per current information there will be a snapshot based logic. Four options are being evaluated, the pro/con aspects of these methods are being considered at the moment.
There will be a final decision about which path to go until the end of next week, which will be announced and described in detail.
Until this happens, make sure that you do not conclude any trading activities (buying/selling/liquidity providing) neither on decentralised trading platforms nor centralised ones. Please also refrain from participating in OTC transactions until further official information. This is important so that a fair balance-restoration process can be designed.
Update: October 13, 2022
We halted a Telegram AMA on October 13, 2022.
You can read the community questions and answers from our CTO here if you missed the AMA: https://t.me/QANplatform/276939
Update: October 15, 2022
We are collecting and analyzing the data from CEXes and DEXes like transaction counts, holder counts, volumes, etc. Our partner exchanges assist us and going to provide the missing information in 1–2 days. This is essential to make a fair final decision to move forward.
Update: October 16, 2022
Today we are considering the pros/cons of updating the token contract (development time, audit time, costs, etc.).
The potential upgrades are being collected and analyzed that could be the part of the new token contract. E.g. front-running bot protection, locking functionality, etc.
Update: October 17, 2022
Today, finally all major explorer sites placed a warning to not transact with the token (CoinGecko, CoinMarketCap, DEXTools).
Audit partners were contacted to book an audit slot beforehand — if we decide to upgrade the contract with new functionalities.
The potential upgrades that could be part of the new token contract are still being collected and analyzed. E.g. front-running bot protection, locking functionality, etc.
We are still waiting for some trading data from the exchanges.
Update: October 18, 2022
Today we published: “Factsheet: profanity vulnerability report” for the sake of transparency and educational purposes about the recently occurred event of the profanity vulnerability exploitation.
It is easy enough to inspect and evaluate the chain of events after they happened. This document’s sole purpose is to demonstrate whether there was any chance to avoid the incident (and if yes with what probability) given that prior decision-making events were made based only on information available at that time when those particular decisions were made.
Our goal is that by transparently disclosing and evaluating the said chain of events we can transfer additional knowledge to the crypto community so that we can collectively learn from it.
Update: October 23, 2022
In the past days we collected mostly all trading data. We are waiting only for one CEX.
We are researching various front-running bot protection solutions which we could implement in the new token contract. As for now, Libsubmarine seems to be the most promising option.
Besides that, we are researching the possibilities to add IQ Protocol and 0x API to the new token contract.
To clarify the situation: there will be a new QANX token contract where those holders who had QANX before the hack will get a 1:1 portion of the new QANX token. We still need the awaited one CEX data to calculate the final snapshot time.
The restoration and possible compensation options (for those who bought after the hack) strategy depends on the dataset we are still awaiting for from the last CEX which affects the after hack period trading.
Update: October 24, 2022
Today we finalized the new QANX token redesign with the following contract upgrades:
1) Front-running bot protection
The goal of this function is to prevent front-running bots from exploiting human transactors.
2) Quantum-resistant QAN XLINK integration into the contract
QAN XLINK public keys will be directly integrated into the new contract for a much more seamless MainNet transition.
3) Gas fee reduction for token unlocks
Gas fee savings for token unlocks will be implemented.
4) Unlock self-transfer event removal
Some CEX-es do not check the sender of the transaction which could lead to internal errors. This will be mitigated at the contract level.
5) Unlock custom event
The previous self-transfer event will be replaced with a custom unlock event.
6) Locked multi-transfer
Currently only one locked transfer per address was allowed, the update will allow multiple, if the same lock is applied.
7) Claim logic integration based on signature
Integrate token claim possibility based on snapshot data and relevant withdraw signatures.
8) ETH (& BNB) and token withdrawal option
Enable Ether and other ERC20 token withdrawal for mistaken transfers to the QANX token address.
Based on the above mentioned list, the new QANX Token contract will be developed in the upcoming days.
Update: November 1, 2022
We are progressing with the new smart contract and snapshot data collection.
We will update you as soon as there is a new milestone achieved.
Thanks for your support.
Update: November 18, 2022
We published the QANX smart contract restoration process.
Update: January 9, 2023
We received the first audit results from Hacken and Omniscia, they have been evaluated and we applied further adjustments to the smart contracts.
Update: January 30, 2023
The analytics for the Ethereum side compensations are ready. After going through hundreds of closed-source smart contracts manually, we are finishing the BSC side now.
The last date for the relaunch is February 22nd since we need to be ready before our partnership announcement.
Frequently Asked Questions:
The vanity related vulnerability was recognized in the profanity tool in September. Why the team did not fix it in time?
1.) As soon as the vulnerability was disclosed the team went through all in-house wallet addresses to check if there are any vanity addresses used internally. There were none.
2.) The bridge deployer wallet was specially crafted that the first CONTRACT it deploys would get a vanity address, not the wallet itself.
3.) The tool used back then to create this wallet was not profanity but another one which unfortunately was also based on profanity as it turned out, but it was not profanity itself.
4.) The bridge deployer wallet described above did not have direct access to funds, it could only sign transactions to be executed based on the signature.
For above reason it was concluded that the vulnerability would not affect us in any way. Sadly this was not the case as the attacker went one step further and figured out how to misuse the forged signature of the broken wallet.
How can an offline bridge get hacked?
The bridge itself was not hacked at all. The bridge being offline just means that the user facing interface (website with MetaMask integration) is not running.
The decentralized part of it (the smart contract) can not be put offline, since this is the purpose of blockchain to build unstoppable applications.
There was an offline private key in cold storage properly isolated which had the right to sign withdrawal transactions. This private key was remotely calculated by the attacker without physical breach. The private key was sitting all the time in a safe deposit box. There is no protection against that. The possibility that it could have been calculated relies in the bug identified in profanity.
The attacker then used the calculated private key to forge a signature.
It is unfortunate that the bridge deployer wallet private key was calculated, but this could have been any other wallet (other exchange, stable token, anyone’s personal wallet etc.) as we have seen in the numerous reports related to the profanity attack.
How can you claim being quantum-resistant if you got hacked?
This issue is not related to quantum-resistant cryptography. For example if tomorrow an issue within Ethereum / Binance Smart Chain would come up, the token could still be affected again and there is nothing the team could do about it for example.
This was an external vulnerability which got exploited.
Will there be a bridge in the future?
This question is still being evaluated internally, once a firm decision is concluded it will be shared in the official announcement channel.
