The incident occurred because the EOA private key, which was managed in an online environment, had critical authority to change ownership. Additionally, the multi-sig was set to 1/2, meaning that a transaction could be executed if just one private key was compromised.

*There were no vulnerabilities in the smart contracts.

In collaboration with our incident response partners, zeroShadow, we have developed a mitigation plan that focuses on completely updating and improving our key management system.

Read the overview and technical analysis of the incident in our previous article:

https://mirror.xyz/0x6FA2aF9a4d6fFe654361F713780963C10412e7c3/gN17YMrLhKKg9YT9a391U74pWr9IhqBUDWUqDyDamjE

• We confirmed that no private keys (configuration files) were ever pushed to GitHub.

• We verified that there was no unauthorized access to 1Password.

• We discovered that on Vercel’s dashboard, the private key information for the multi-sig signer was publicly accessible to four developers. Consequently, we requested Mandiant to investigate the devices of employees who might have had access to that file. However, no suspicious activity was found.

• Multi-Sig Keys: The private keys of all multi-sig signers, which were previously managed in online environments (e.g., Vercel, 1Password), will now be managed offline with secure hardware separate from personal devices.

• Keys for automated execution: Private keys for automated tasks will be generated and managed using AWS KMS. This system will ensure that no developer has access to view the private keys.

  Note*: *The AWS-generated private keys will be used for automated tasks such as rebalancing and pulling SYK tokens, but will not have authority for critical upgrades.

• Two-Step Multi-Sig Process: Critical transactions will now require a two-step multi-sig process, one from a Proposer and one from an Executor. Additionally, every transaction will be executed via a Timelock contract provided by OpenZeppelin(OZ), which offers a maximum grace period of up to 72 hours.

• New Multi-Sig Structure: We are transitioning from the previous 1/2 multi-sig setup to an operation managed by three distinct multi-sig systems:

  • Proposer: 3-of-5 approval.

  • Executer: 2-of-3 approval.

  • Pauser: 2-of-3 approval.

  Each multi-sig will be managed using a separate hardware wallet (private key). The Proposer role will be handled by five members of the Orange Finance Core Team, while the Executor and the Pauser roles will be managed by three founding members of Orange Finance. To prevent the targeting of any specific address or device, signers will be rotated periodically.

• Timelock Details: Using the Timelock contract by OZ, there will be a grace period of either 72 hours or 48 hours between proposal and execution. Critical operations that directly affect fund outflows (e.g., upgrades) will be executed via Timelock (High) after 72 hours, while other operations will use Timelock (Mid) with a 48-hour delay.

We will deploy a new monitoring tool provided by OZ to conduct continuous, 24/7 monitoring. This tool will detect unauthorized activity and trigger a pause. The monitoring will cover:

1. Orange Finance on-chain system

   1. State

      1. Assets in Vault

      2. Parameters (e.g. owner)

   2. Executed functions

      1. Regular function execution such as deposit/withdraw

      2. Unintended function execution (direct upgrade occurs, suspicious function execution due to unexpected reentrancy)

2. Administrator privilege wallet

   1. Unannounced changes of Signer

   2. Transaction creation without prior notice

• We will proceed with the implementation of the above mitigation plan.

• In collaboration with the security consulting firm zeroShadow, we are actively and aggressively pursuing the exploited assets and working to freeze them on centralized exchanges (CEXs).

• Additionally, we are waiting for the final report by Mandiant. We will share further updates as more information becomes available.

The incident occurred because the EOA private key, which was managed in an online environment, had critical authority to change ownership. Additionally, the multi-sig was set to 1/2, meaning that a transaction could be executed if just one private key was compromised.

*There were no vulnerabilities in the smart contracts.

In collaboration with our incident response partners, zeroShadow, we have developed a mitigation plan that focuses on completely updating and improving our key management system.

Read the overview and technical analysis of the incident in our previous article:

https://mirror.xyz/0x6FA2aF9a4d6fFe654361F713780963C10412e7c3/gN17YMrLhKKg9YT9a391U74pWr9IhqBUDWUqDyDamjE

• We confirmed that no private keys (configuration files) were ever pushed to GitHub.

• We verified that there was no unauthorized access to 1Password.

• We discovered that on Vercel’s dashboard, the private key information for the multi-sig signer was publicly accessible to four developers. Consequently, we requested Mandiant to investigate the devices of employees who might have had access to that file. However, no suspicious activity was found.

• Multi-Sig Keys: The private keys of all multi-sig signers, which were previously managed in online environments (e.g., Vercel, 1Password), will now be managed offline with secure hardware separate from personal devices.

• Keys for automated execution: Private keys for automated tasks will be generated and managed using AWS KMS. This system will ensure that no developer has access to view the private keys.

  Note*: *The AWS-generated private keys will be used for automated tasks such as rebalancing and pulling SYK tokens, but will not have authority for critical upgrades.

• Two-Step Multi-Sig Process: Critical transactions will now require a two-step multi-sig process, one from a Proposer and one from an Executor. Additionally, every transaction will be executed via a Timelock contract provided by OpenZeppelin(OZ), which offers a maximum grace period of up to 72 hours.

• New Multi-Sig Structure: We are transitioning from the previous 1/2 multi-sig setup to an operation managed by three distinct multi-sig systems:

  • Proposer: 3-of-5 approval.

  • Executer: 2-of-3 approval.

  • Pauser: 2-of-3 approval.

  Each multi-sig will be managed using a separate hardware wallet (private key). The Proposer role will be handled by five members of the Orange Finance Core Team, while the Executor and the Pauser roles will be managed by three founding members of Orange Finance. To prevent the targeting of any specific address or device, signers will be rotated periodically.

• Timelock Details: Using the Timelock contract by OZ, there will be a grace period of either 72 hours or 48 hours between proposal and execution. Critical operations that directly affect fund outflows (e.g., upgrades) will be executed via Timelock (High) after 72 hours, while other operations will use Timelock (Mid) with a 48-hour delay.

We will deploy a new monitoring tool provided by OZ to conduct continuous, 24/7 monitoring. This tool will detect unauthorized activity and trigger a pause. The monitoring will cover:

1. Orange Finance on-chain system

   1. State

      1. Assets in Vault

      2. Parameters (e.g. owner)

   2. Executed functions

      1. Regular function execution such as deposit/withdraw

      2. Unintended function execution (direct upgrade occurs, suspicious function execution due to unexpected reentrancy)

2. Administrator privilege wallet

   1. Unannounced changes of Signer

   2. Transaction creation without prior notice

• We will proceed with the implementation of the above mitigation plan.

• In collaboration with the security consulting firm zeroShadow, we are actively and aggressively pursuing the exploited assets and working to freeze them on centralized exchanges (CEXs).

• Additionally, we are waiting for the final report by Mandiant. We will share further updates as more information becomes available.