Skip to content

Latest commit

 

History

History
77 lines (58 loc) · 3.75 KB

File metadata and controls

77 lines (58 loc) · 3.75 KB

Active Taffy Hornet

High

The SignatureControl::validateAndSaveSignature function allows signature replay upon change of expectedSigner by admin

Summary

The SignatureControl::validateAndSaveSignature function saves signature as a mechanism to avoid signature replay attacks, but when an admin decides to update the expectedSigner using the AccessControl::updateExpectedSigner function, it would allow anyone to use the payload which was used in past as the message hash does not contain anything like expectedSigner address or nonces which allows an emulation of signature replay in EthosAttestation::createAttestation

  function createAttestation(
    uint256 profileId,
    uint256 randValue,
    AttestationDetails calldata attestationDetails,
    string calldata evidence,
    bytes calldata signature
  ) external whenNotPaused {
    validateAndSaveSignature(
      _keccakForCreateAttestation( // Creates a hash without considering anything from the current expectedSigner
        profileId,
        randValue,
        attestationDetails.account,
        attestationDetails.service,
        evidence
      ),
      signature
    );
    // Rest of the code
}

and EthosProfile::registerAddress

  function registerAddress(
    address addressStr,
    uint256 profileId,
    uint256 randValue,
    bytes calldata signature
  ) external whenNotPaused onlyNonZeroAddress(addressStr) {
       // Rest of the code
    validateAndSaveSignature(
      _keccakForRegisterAddress(addressStr, profileId, randValue), // Creates a hash without considering anything from the current expectedSigner
      signature
    );
   // Rest of the code
  }

Root Cause

The functions EthosProfile::_keccakForRegisterAddress and EthosAttestation::_keccakForCreateAttestation lacks a differentiator that allows expected signer to be linked with the hash in some way in order to prevent same payload being used when expectedSigner is changed by admin.

Internal pre-conditions

  1. Attacker interacts with protocol as a normal user by performing activities such as creating attestation and register address.

External pre-conditions

No response

Attack Path

  1. As soon as attacker realises that the expected signer was changed, he will use the old payload as now the signature would be different as new expectedSigner signs the message in the off-chain mechanism.
  2. This will allow him corrupt data viaEthosAttestation::createAttestation and EthosProfile::registerAddress.

Impact

This allows emulation of signature replay attack. This would lead to data being override / inconsistent storage via both EthosAttestation::createAttestation and EthosProfile::registerAddressfunction.

PoC

No response

Mitigation

It is recommended to addexpectedSigner address while creating hash.