In recent SIRN incidents and investigative efforts, we have identified multisigs and MPC wallets with security much weaker than their on-chain configuration or operators' understanding suggests. We are finding multisigs that are in reality a 1-of-1, signers who are identifiable, and failure scenarios for emergency response or continuity of operations.
1. Collapsed thresholds
Active incidents have exposed multisigs which were composed of multiple keys controlled by a single actor. This is something that can be fingerprinted through patterns of behavior and made obvious after the fact, or utilized by an attacker for planning purposes. In the worst scenario identified, a threshold number of keys were derived from the same seed phrase utilized by a software wallet.
-
How it is identified publicly:
- Repetitive signing patterns
- Same signers
- Same order of signing
- Narrow gaps between signing
-
What you should do:
- Separate signers, on separate devices, in separate places. Even if one person is using multiple devices, this still means that under duress, you have a single point of compromise.
2. Shared signers across multisigs
Having the same set of signers who reach threshold on multiple multisigs means that you have ONE multisig. A shared threshold set of signers means that all of the programs and authorities with shared configuration are at risk from the same signer set compromise.
-
How it is identified publicly:
- Viewing the authorities on your programs and identifying the associated multisigs
- Reviewing the signers of each multisig
- Identifying common signers up to threshold on each multisig
-
What you should do:
- Utilize separate signers per program that you control, and ensure that your most important authorities (such as program upgrade) at a minimum have a greater threshold of signers than the lower impact authorities.
3. Identifiable signers
Part of the security model for your multisig is the inability for an actor to identify and target your signers, this breaks down however when your signers utilize their keys for purposes other than multisig operations, or are funded personally.
-
How it is identified publicly:
- Funding from a personal wallet or a KYC’d exchange account also used for publicly identifiable wallets
- Trading activity tied to publicly available information on your signers
- Reuse of keys previously used on other protocols your signers were known to be associated with
-
What you should do:
- Fund your signers from a source under the control of your protocol and prohibit self funding.
- Prohibit activity unrelated to signing operations
-
Before adding a signer, have them create a new seed phrase on a separate hardware wallet or
at a minimum derive another key
- Remember, deriving another key introduces the risk that one compromised seed phrase can compromise all of the keys
4. Improper setup of MPC wallets
MPC wallets are effectively one key, the only difference is the vendor implementation in front of the assembly or usage of that key. MPC security depends on how the workspace management, policies, and recovery are set up. This is difficult as all MPC solutions are different in their capabilities and security model.
-
What we are seeing:
-
Workspaces that have been backed up in an insecure fashion which enables a single party to
re-assemble the key, or worse exposes the backup to easy theft
- The worst examples that have been identified were widely available MPC backups and key material accessible to an undetermined number of internal staff
- With some platforms this is exacerbated by the user not forming a secure backup plan before a timed forcing factor requires a backup before continued use
-
Poor admin configuration which allows for a single user to re-write policies within the
platform and afterwards sign transactions on their own
- In some cases this misconfiguration was coupled with misconfiguration of identity management which allowed admin account takeover by other admins
-
Workspaces that have been backed up in an insecure fashion which enables a single party to
re-assemble the key, or worse exposes the backup to easy theft
-
What you should do:
-
Plan for your MPC wallet backup in advance of establishing the wallet. Make sure that your
backup is both resilient to loss of material, and also prevents a single actor from gaining
the underlying private key.
- Prefer backup plans which enable you to shard the backup, or do so yourself through the use of Shamir's Secret Sharing
-
Review the admin settings for your MPC solution and ensure that you require a threshold of
admins to further change configuration, or execute a recovery sequence, especially for other
admins
- If your MPC solution lacks capability for this look for other mitigating factors such as forming a custom break glass solution around administrator access
-
Plan for your MPC wallet backup in advance of establishing the wallet. Make sure that your
backup is both resilient to loss of material, and also prevents a single actor from gaining
the underlying private key.
5. Improper configuration of emergency response functions
Many protocols lack emergency response functions, but amongst those that do have them, we are seeing configurations which are either incomplete in coverage, or are unable to be effectively executed due to the multisig with the associated authority.
-
How it is identified publicly:
- No emergency response function implemented
-
Emergency response functions with limited coverage
- Having limited coverage with your emergency response functions means that you may not be able to respond to the emergency at hand (eg. your protocol can pause deposits but is being exploited by a method requiring no/no-further deposits)
- Emergency response functions with a threshold greater than 1-of-N
-
What you should do:
-
Implement an emergency response function, even if it lacks granularity, capable of disabling
all methods of interaction with your program
- The best configuration is to have both a wide sweeping and also granular pause functions, however it is better to have full coverage and rapid response than a lack of coverage/agility where you need it
- If you find yourself without a response function in an emergency, utilize a rapid solution such as github.com/deanmlittle/sbpf-asm-abort
-
Configure all emergency functions for a single signer to be able to activate them, which
allows automated response or rapid response by the first signer identifying compromise
(including security automations)
- Restoring functionality should have a higher threshold than shutting off functionality
- An alternative M-of-N configuration is to have all emergency functions signed up to M and awaiting execution by any signer
-
Implement an emergency response function, even if it lacks granularity, capable of disabling
all methods of interaction with your program