021.md

Sharp Mustard Gazelle

Medium

Signature replay attack via ethereum-signed message template

Summary

In the Ethos protocol’s createAttestation function, the signature validation process accepts signatures formatted as standard Ethereum-signed messages (see https://eips.ethereum.org/EIPS/eip-191). This introduces a vulnerability where signatures meant for Ethereum transactions and signed by the expectedSigner can be reused to forge attestations within the Ethos protocol. This could undermine trust in the attestations, as malicious actors may create false attestations by reusing valid Ethereum transaction signatures.

Root Cause

The createAttestation function uses the SignatureControl library to validate attestation signature. The validateSignature calls the signatureVerifier contract without modifying the message hash. At the end the signature is verified as following:

  function verifySignature(
    address expectedSigner,
    bytes32 messageHash,
    bytes memory signature
  ) external view returns (bool) {
    bytes32 ethSignedMessageHash = _getEthSignedMessageHash(messageHash);

    return SignatureChecker.isValidSignatureNow(expectedSigner, ethSignedMessageHash, signature);
  }

  function _getEthSignedMessageHash(bytes32 messageHash) private pure returns (bytes32) {
    return keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", messageHash));
  }

The vulnerability arises because verifySignature uses Ethereum's default signature format (\x19Ethereum Signed Message:\n + message.length + message). This format is widely used for transaction messages, so a signature intended for an Ethereum transaction can be reused within the Ethos protocol to falsely validate attestations, provided the message hash can be crafted similarly. See Web3.js documentation for example: https://web3js.readthedocs.io/en/v1.2.11/web3-eth-accounts.html#id13. Most of wallets also follow this method.

Internal pre-conditions

No response

External pre-conditions

1. The expectedSigner has to sign an ethereum transaction.

Attack Path

1. An Ethos-authorized signer creates a valid Ethereum transaction with a public signature.
2. The attacker obtains the signer’s publicly available transaction signature.
3. The attacker manipulates the createAttestation parameters to match the message hash of the original Ethereum transaction.
4. Using the obtained signature, the attacker submits a false attestation to the Ethos protocol. Due to Ethereum's signing format, Ethos incorrectly validates the forged signature.

Impact

Compromising the protocol’s integrity by allowing unauthorized or fabricated attestations.

PoC

No response

Mitigation

Implement EIP-712-compliant signing for attestations to ensure that only specifically formatted signatures intended for Ethos attestations are valid, preventing signature reuse from unrelated Ethereum transactions.