Context

Following the execution of Referenda 1339, the attacker has maliciously added their key as a proxy to the newly established sudo key, effectively freezing all associated PARA funds under the account. As a result, the new sudo key is unable to send transactions, while the attacker retains sudo ownership. Meanwhile, the attacker has initiated unbonding on all six of our accounts, putting 200,000 DOT at risk. We currently have only 16 days left to act, making it crucial to pass this referendum as soon as possible.

This referendum represents the first step of a two-part rescue plan. The first step is to break the chain and transfer funds to an account that no one controls. The second step will involve submitting another proposal to return the funds to users after securing them. Our team has been collaborating closely with Parity and srlabs, who have provided valuable feedback and a thorough review for this referendum.

The accounts at risk:

• 14quGMw2tot6JxY2wSyk1Vc1uns3EmMRs2eQS2C66Mdv6uE9 (22.649 DOT)
• 19cnUyebu52RUt4Rt67brDmmnVdaDD37xdxKbaJ7tuLnLfu (74.614 DOT)
• 16kTs7tsJ6tYYWAXSWDmm4vYnRTFPWEhXTk4rNCtbw6NRvte (1.566 DOT)
• 16ZbwPMyrp9yTbPScDqm9btzcNVKKQ5MHcMQp4rA1ztF4sBA (101.322 DOT)
• 1dMif8G4jrXsdPSkvF87uBfaiahh2EvC9fPnsi91v4i1xKC (3.413 DOT)
• 16cNboEKEudny4sdpZGNL542Re2sp4FDcTaZFFnYoqRixBwN (250.532 DOT)

Objectives

1. Break the Chain: Disable the attacker's control, effectively neutralizing the parachain and halting any potential malicious activities.
2. Remove All Proxies: Eliminate any proxies associated with the attacker’s key.
3. Force Unstake and Transfer: Unstake the affected accounts and transfer the funds to a Non-Controlled Address.
4. Rebond as a Fallback Case: Prepare for rebonding transactions in case the above strategy fails.

Proposed Changes

We have submitted the preimage (0x697eaaab356779518053f23f00eb0c56f53aafc0714556292974dfd7b0155d84), which includes the calldata to secure the funds. This calldata can be decoded on polkadot.js to verify the proposed changes. The following is a detailed description of the proposed changes. CallData Link

1. paras.force_set_current_code and paras.force_set_current_head

   • By setting the current code and head to "0x", we ensure that the parachain becomes inoperable, preventing any further malicious actions.
   • Consequences:
     • No Runtime Logic: The parachain will not execute any functions or processes defined in its runtime.
     • Inoperable Parachain: The parachain becomes non-functional, halting all operations.
     • Loss of State: Existing data and state information become inaccessible.
     • Recovery Difficulty: Re-deploying the parachain with a valid runtime becomes necessary, complicating recovery.

2. registrar.removeLock

   • The paraId of Parallel registered on Polkadot is 2012
   • This operation removes the lock that may prevent further modifications or actions on the parachain.

3. utility.dispatch_as ⇒ proxy.remove_proxies

   • This step is used to remove all proxies added by the attacker, both for the main sovereign account and all derivative accounts used for staking.
   • We iterates through these accounts and removes their proxies:
     • Six Staking Accounts:
       • 14quGMw2tot6JxY2wSyk1Vc1uns3EmMRs2eQS2C66Mdv6uE9
       • 19cnUyebu52RUt4Rt67brDmmnVdaDD37xdxKbaJ7tuLnLfu
       • 16kTs7tsJ6tYYWAXSWDmm4vYnRTFPWEhXTk4rNCtbw6NRvte
       • 16ZbwPMyrp9yTbPScDqm9btzcNVKKQ5MHcMQp4rA1ztF4sBA
       • 1dMif8G4jrXsdPSkvF87uBfaiahh2EvC9fPnsi91v4i1xKC
       • 16cNboEKEudny4sdpZGNL542Re2sp4FDcTaZFFnYoqRixBwN
     • Sovereign Account:
       • 13YMK2ebCdad8E87WTgv3ZX25yUmVy4wcUDnBN18x9wMVD3H
   • This ensures that no unauthorized access can occur after the initial removal.

4. utility.batchAll ⇒ staking.force_unstake, balances.force_transfer

   • For each affected derivative account, after unstaking, transfer the funds to the designated Non-Controlled Address(12pEEeQiChMDnMGDR34LeM3C379HaxKYDaoB2VKe4wMgdJCh) to protect them from potential further attacks.
   • Generate a Non-Controlled Address:
     • To facilitate secure transactions, we will generate a no-one controlled address: 12pEEeQiChMDnMGDR34LeM3C379HaxKYDaoB2VKe4wMgdJCh .
     • In our Rust code, we utilize a string directly instead of using bytes, and this approach will generate the exact same address. The code demonstrates how to generate a Polkadot-compatible address using a predefined identifier string. The address is derived from a unique input ("PARALLELFI_NEW_STAKING_ADDRESS\0\0") and encoded with the Polkadot-specific SS58 format.
     • The resulting address is safe and non-accessible because: It is generated from a hardcoded, deterministic input string; the input string does not correspond to a private key, meaning it cannot be used for signing transactions or accessing funds. This ensures the address can only be used as a placeholder without security risks. Here’s the code used to generate this special address:

   use sp_core::crypto::{AccountId32, Ss58AddressFormat, Ss58Codec};
   
   fn main() {
       let account = AccountId32::try_from([0x50, 0x41, 0x52, 0x41, 0x4C, 0x4C, 0x45, 0x4C, 0x46, 0x49, 0x5F,
           0x4E, 0x45, 0x57, 0x5F, 0x53, 0x54, 0x41, 0x4B, 0x49, 0x4E, 0x47,
           0x5F, 0x41, 0x44, 0x44, 0x52, 0x45, 0x53, 0x53, 0x00, 0x00]).unwrap();
       let format = Ss58AddressFormat::try_from("polkadot").unwrap();
       let addr_ss58 = account.to_ss58check_with_version(format);
       println!("Generated address: {addr_ss58}");
   }
   

5. staking.rebond

   • This is the final safeguard. If all previous operations fail, the funds must still be successfully rebonded.
   • This involves setting up a secondary process that can be triggered to re-establish the accounts’ staking status.

Testing

Verification on Chopsticks:
We conducted upgrade tests in the Relaychain fork environment.
Firstly, we submit the proposal in the relaychain fork environment, then place the decision deposit and vote on the referendum.

Then, we accelerated block production in the relaychain fork environment to ensure the proposal could be quickly approved and enacted. (Image 1 indicates the proposal has been successfully passed, and Image 2 indicates the proposal will be enacted at the target block.)

After the proposal is successfully passed, we can observe the following expected results:

1. The parachain's head and runtime code were successfully reset to null, preventing the hacker from accessing it. The result of setting the runtime code value to 0x does not have a storage key that can be read and displayed. And we can confirm it occurred based on the behavior of the triggered event log.
   
   

2. The remove_lock operation was successfully executed, which is a critical step allowing us to regain ownership of the parachain in the future.
   

3. For the sovereign address and all derivative accounts used for staking, the remove_proxies operation was successfully executed. Additionally, for the funds affected in the accounts used for staking, the force_transfer was successfully completed. Here is the comparison of the proxy and DOT balance states before and after the operation.

   • Before the referendum executed
     
     
   • After the referendum executed
     
     

4. Our rebond operation, intended as a backup plan, did not come into play as expected in this operation, as all DOT in the derivative accounts had already been successfully transferred prior to the rebond.

Conclusion

This proposal represents an urgent step in regaining control over our parachain and securing 200,000 DOT users' funds. By breaking the chain, removing proxies, unstaking and transferring funds, and preparing for a rebonding strategy, we aim to fortify our defenses against this attack. Due to the time-sensitive nature of this situation, we will only execute this first step of the two-step rescue plan. We expect to submit another proposal to return the funds back to users once funds are in a secure place.