sherlock-audit / 2024-10-ethos-network-judging

0 stars 0 forks source link

0xBhumii - Replay Attack Risk in `SignatureVerifier` Contract for `Ethos Network` #276

Open sherlock-admin4 opened 2 weeks ago

sherlock-admin4 commented 2 weeks ago

0xBhumii

Medium

Replay Attack Risk in SignatureVerifier Contract for Ethos Network

Summary

The SignatureVerifier contract's signature verification mechanism is susceptible to replay attacks if the Ethos Network is deployed on any other Layer 2 (L2) solutions, allowing attackers to exploit signed messages across different networks.

Root Cause

In SignatureVerifier.sol, the implementation of signature verification does not incorporate a mechanism to differentiate between messages signed on different networks or environments. As a result, valid signatures can be reused on any network that recognizes the same message format. https://github.com/sherlock-audit/2024-10-ethos-network/blob/main/ethos/packages/contracts/contracts/utils/SignatureVerifier.sol#L20C1-L29C1

Internal pre-conditions

  1. The signature must be valid for the message hash.
  2. The expected signer address must match the signer of the signature.

External pre-conditions

he protocol may be deployed on multiple Layer 2 networks, each capable of accepting valid signatures from the same message hash.

Attack Path

  1. An attacker obtains a valid signed message on the Ethos Network.
  2. The attacker deploys a similar contract or uses a compatible system on another Layer 2 network.
  3. The attacker calls the verifySignature function with the same signed message and expected signer address on the new network.
  4. The contract verifies the signature as valid, allowing the attacker to replay the signed action, potentially leading to unauthorized actions across networks.

Impact

The affected party, namely users of the Ethos Network, risks having their signatures replayed on other networks, leading to unauthorized transactions and actions. This could undermine the security and integrity of the protocol, eroding user trust and potentially resulting in significant financial losses.

PoC

No response

Mitigation

To mitigate this vulnerability, a unique nonce or network identifier should be included in the signature process to distinguish between different deployments and contexts. Here’s a suggested implementation:


function verifySignature(
    address expectedSigner,
    bytes32 messageHash,
    bytes memory signature,
    uint256 nonce // Unique nonce for the transaction
) external view returns (bool) {
    bytes32 ethSignedMessageHash = _getEthSignedMessageHash(messageHash, nonce);
    return SignatureChecker.isValidSignatureNow(expectedSigner, ethSignedMessageHash, signature);
}

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