Polkassembly Logo

Head 1
Head 3
Head 4
Head 2
Create Pencil IconCreate
TRACKS
ORIGINS
Report an issueNeed help with something?
Foot 1
Foot 2
Foot 3
Foot 4
OpenGov
View All Root
Executed

Emergency Response Plan for Securing 200,000 DOT

inRoot
5 months ago

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.
image.png

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.)
image.png
image.png

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.
    image.png
    image.png

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

  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
      image.png
      image.png
    • After the referendum executed
      image.png
      image.png
  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.

Comments (9)

5 months ago

Great to see collaboration with Parity and srlabs! This adds credibility and gives me confidence that the team can effectively execute this plan

5 months ago

May the proposer verify his identity please.

Load more comments
PleaseLogin to comment

Proposal Passed

3

of 3

Summary

0%

Aye

AyeNay

0%

Nay

Aye (168)0.0 DOT

Support0.0 DOT

Nay (8)0.0 DOT

Voting Data

Approval%

Support%

Threshold0.00%

Threshold0.00%

Help Center

Report an Issue
Feedback
Terms and Conditions
Github

Our Services

Docs
Terms of Website
Privacy Policy

A House of Commons Initiative.

Polka Labs Private Limited 2025

All rights reserved.

Terms and ConditionsTerms of Website
Privacy Policy