Publicly exposed exit signatures can be used to perform DoS which breaks the core functionality of StakewiseV3

Github username: @akshaysrivastav Submission hash (on-chain): 0xb8f60c0cd7846b9c790947d801554d12e143d54a270bc363b5ec0f1f21b2eacc Severity: high

Description:

Description

Stakewise V3 intends to permissionlessly allow creation and management of validators. It also provides mechanisms to initialize and exit validators for vaults without having dependency on vault's deployer.

However while creating the open validator exit mechanism, the protocol exposes the exit signatures of validators publicly.

KeeperValidators.sol

  function approveValidators(ApprovalParams calldata params) external override {
    // verify oracles approved registration for the current validators registry contract state
    if (_validatorsRegistry.get_deposit_root() != params.validatorsRegistryRoot) {
      revert Errors.InvalidValidatorsRegistryRoot();
    }
    if (!_vaultsRegistry.vaults(msg.sender)) revert Errors.AccessDenied();

    // verify oracles approved registration
    _verifySignatures(
      ...
    );
    _collateralize(msg.sender);

    emit ValidatorsApproval(msg.sender, params.validators, params.exitSignaturesIpfsHash);
  }

  function updateExitSignatures(
    address vault,
    uint256 deadline,
    string calldata exitSignaturesIpfsHash,
    bytes calldata oraclesSignatures
  ) external override {
    ...

    // verify oracles approved signatures update
    _verifySignatures(
      ...
    );

    exitSignaturesNonces[vault] = nonce + 1;

    emit ExitSignaturesUpdated(msg.sender, vault, nonce, exitSignaturesIpfsHash);
  }

It can be seen that the approveValidators & updateExitSignatures functions openly accepts the exitSignaturesIpfsHash input, this value is also logged in events. The use of string type parameter also indicates that the parameter contains the IPFS hash of signatures and not the hash of IPFS hash.

Since data on IPFS network is publicly accessible, anyone can read the exit signatures of validators. After that these exit signatures can be submitted to Ethereum consensus network due to which all validators supported via Stakewise protocol will be removed from consensus protocol.

Impact:

An attacker can forcefully make all validators of all vaults exit the Ethereum consensus network. This breaks the core offering of Stakewise V3 as no validators can successfully propose blocks ever.

Attack Scenario

10 vaults gets deployed via Stakewise, each with 10 validators.
Total 100 validators are now being supported by Stakewise.
Since during the validator initialization, exit signatures were requested and stored onchain, an attacker gets hold of all exit signatures of the 100 validators.
The attacker submits all exit signatures to consensus network.
All 100 validators get exited from the network.

Mitigation

IPFS is a public network so storing sensitive signatures on IPFS is not safe. Moreover no such information should be stored on Ethereum chain as well. It will be better to store the signatures in the keeper oracle network.

Attachments

Proof of Concept (PoC) File Provided above

hats-finance / StakeWise-0xd91cd6ed6c9a112fdc112b1a3c66e47697f522cd