CryptoCart — Post Mortem and Recovery Timeline

As part of our recovery procedures following the breach that caused liquidity to be pulled from the CC ERC20 pool in the early hours of the 1st of November, we have carried out sleepless hours of investigation in order to better understand how such a breach occurred and how to completely prevent a breach from happening in future. With our own internal research and some external advice we will further outline what measures will be taken to ensure that such a breach in security can never happen again.

Here is a short timeline establishing the facts of what happened.

- On 1st November at 1:16 UTC liquidity was removed from Uniswap.

- Four minutes prior to this, the following Binance address added Ethereum to the deployer address: 0xBdaEda8ED778c126f81a4Ae06B6a1b5d6152b278

- We have reached out to Binance explaining the situation to assist with this further.

- 328 Ether was removed, separated into three wallets, and funnelled through Tornado Cash.

- The team were alerted approximately 30–45 minutes after this took place and a snapshot was immediately taken.

- By 14:56 on the same day, while investigations were under way, 309 Ether was sent back to the deployer in three separate transactions.

- All recovered funds were then moved offline, into a fresh hardware wallet for safekeeping whilst plans for a relaunch are in progress.

- Those responsible for the breach have not reached out since returning the funds, and we still encourage them to make contact.

Identifying Security Flaws and learning lessons.

First and foremost, liquidity was unlocked at the time that this happened, putting the liquidity pool at a higher risk of a breach. The only way we understand that liquidity can be pulled is if an unauthorized person had access to the private key for the deployer wallet, which was the owner of the liquidity lock on UniCrypt V2 and therefore UniSwap.

After running extensive security checks on all devices owned by team members who have control or access to the deployer wallet address, we have come to the conclusion that an internal device in which the private key was saved was compromised, resulting in the private key being compromised to an unauthorized person, consequently allowing them to gain full access to the deployer wallet and carry out the transactions that they did.

Furthermore, another security flaw identified is that the deployer wallet did not have a multi-sig. This allowed the perpetrator to act autonomously.

With these security flaws in mind, as a first step and with the funds now secure, all devices have been individually checked, scanned, wiped of any sensitive data, and restored to factory with multiple additional layers of security software to remove all possibility of a compromise on the devices happening again. Furthermore, we will outline the next steps we will take to ensure this can never happen again.

Preventing breaches in future — Security Improvements

After some discussions we have brainstormed the safest and most secure way to re-launch the token with multiple additional layers of security that will make security breaches of this nature completely impossible and prevent unauthorised individuals from gaining access to the deployer wallet. Additionally, there will be multiple redundancy measures put in place so that if the deployer was ever compromised and anyone did gain access to the deployer wallet, they would not be able to do anything nefarious or carry out any transactions at all, even if they had full access with the private key.

Our new approach will include the five following key measures for the prevention of a breach;

Multi-Sig Wallet
This security feature will only allow a transaction to happen when it is approved by multiple owners of the wallet, preventing an unauthorized person from being able to carry out any kind of transaction as they would need full approval from other owners of the wallet for the transaction to go through. Therefore, if an unrecognized transaction is requested, it cannot complete without authorization from the real owners of the wallet.

Permanently Locking Liquidity
This measure will prevent the liquidity from ever unlocking, meaning it can never be pulled even if the private key to the deployer is compromised. This is one of the most important features moving forward for the re-launch. Liquidity on the new V2 contract will be locked forever.

Renounced Ownership
By renouncing ownership to the new smart contract, there will be no special privileges granted to anyone who created the contract. Therefore, even if the private key were to be compromised, it would be impossible for an unauthorized person to carry out any dangerous or nefarious actions on the smart contract.

Improved Device Security
All core team members have had their devices checked, scanned, and had bare-metal restores done. This prevents any ongoing access to devices by hackers, bad actors, malware, or backdoors. Additionally, moving forward, all
sensitive information will never be stored on an owned device, including private keys. Once the deployer wallet is renounced, all private keys that were physically scribed offline will be permanently destroyed.

True Decentralization
With renouncing ownership of the smart contract, this will essentially make CryptoCart a completely decentralized, community driven project. There will be no owners that will be able to control the smart contract and therefore no single points of failure or vulnerability. Complete ownership will be with the community. This does not mean that the team won’t continue to drive the project forward. Everything will remain the same, the only difference will be is that it will be physically impossible for the liquidity to get stolen again, and protected from any exploits or hacks going forward.

As the core team you know today, our roles will remain the same. We will continue to develop, roll out updates, build the ecosystem, secure partnerships, and continue marketing. The only difference is that there are no “owners” or central point of control for the smart contracts, making it truly decentralized.

All of the measures outlined above will be applied to every official CryptoCart wallet, for example the Vault and GiftCard wallets

The Roadmap Ahead — Recovery and Summary

We have compiled a short timeline below to summarise our four recovery steps, some of which have been achieved already, and the rest of which we aim to achieve very shortly so that we can get back on track and live with CC V2.

1. Secure & Investigate
2. Learn & Prevent
3. Audit & Redeploy
4. Airdrop & Automation

Firstly, we have secured and investigated all aspects of this breach with all of the resources we could pull together, resulting in this post-mortem article.

Secondly, we have learned our lessons, identified security risks, and have implemented several preventative measures moving forward to ensure complete safety and ensure this never can happen again.

Thirdly, we are in the stage now, as of writing this post-mortem, of having our V2 smart contract created from the ground up and audited. With the third stage, we have brainstormed how best to achieve anti-dump measures on the re-launch using the recovered funds and will release further information about this in due course before we go live. Additionally, we would like to note that all smart contracts relevant to the V2 relaunch will be redeployed, such as staking and bridging contracts.

Finally, the team are going through all historical transactions block-by-block using a script to ensure that we can reimburse everybody who lost funds before the fact and also deal with edge cases. This allows us to comprehensively draw a full picture of impact, block by block, to include stakers, people who panic sold immediately after the breach, and people who bought in after it happened.

What about BSC?

Some additional aspects to note are that, with regards to the current V1 BSC CC token, we will be attempting to counteract some of the sell pressure caused by panic sellers as best as we can on the BSC token temporarily, using our own personal funds to buy back and burn CC tokens. This will not be done using the recovered funds, and we will be using our own personal funds.

The bridge will remain closed until the V2 BSC CC contract is deployed and funded using V1 BSC CC liquidity. We would like to reiterate that you should not be buying any V1 tokens on any blockchain. Whilst we are certain the BSC side is unaffected, we advise not to be trading of the V1 token until the same security additions are put in place.

Liquidity for the V1 BSC CC token is unlocked on January 18th 2022 at 12:00 UTC. Therefore, our plan with this will be taking a snapshot at that exact time and date, redeploying the V2 contract, removing liquidity from V1 and supplying liquidity, airdropping all holders, and opening up the bridge again.
Ample notification will be given to all holders leading up to and before any of this takes place.

Final words from the team

Most importantly, we would like to apologize for everything that has happened in the past few days. We understand the immense stress and human impact this incident has caused to each of our holders, stakers, advisors, and everyone involved in the project. Our hope is that the steps we have taken
and are continuing to take are sufficient in showing everyone just how committed we are to the success and continuity of CryptoCart moving forward.

We would also like to thank each and every one of you who believes in our mission for standing by us throughout all of this. Whilst this could have turned out very differently at multiple stages, we are thankful that we had the opportunity to learn from this attack, and are grateful that this has now driven new innovation that ultimately leads to making CryptoCart safer and stronger moving forward. We are excited to continue on with fulfilling absolutely every objective we initially set, including automation as the next step after relaunch, followed by ongoing integrations, and partnerships.

Thank you for supporting us.