Skip to content

Latest commit

 

History

History
128 lines (97 loc) · 11.8 KB

mitigations.md

File metadata and controls

128 lines (97 loc) · 11.8 KB

Mitigation Strategies Analysis for ethereum-lists/chains

Mitigation Strategy: Implement a Chain Verification Process

  • Description:

    1. Data Fetching: When the application needs chain data, fetch it from the ethereum-lists/chains repository (or a pinned version/fork).
    2. Cross-Referencing: Before using any chain data, compare it against at least two other independent, trusted sources. Examples:
      • The official website of the blockchain project (e.g., for Ethereum, check ethereum.org).
      • Reputable block explorers (e.g., Etherscan, Polygonscan).
      • Other well-regarded chain registries (if available and trustworthy).
    3. Hardcoded Fallback: For critical chains (e.g., Ethereum Mainnet, Polygon Mainnet), hardcode their essential parameters (Chain ID, RPC URL, Network Name) directly within the application's code.
    4. Discrepancy Check: Compare the fetched data from chains with both the cross-referenced sources and the hardcoded values.
    5. Alerting: If any discrepancy is found (different Chain ID, RPC URL, etc.), immediately:
      • Log the discrepancy with detailed information (which parameter differs, from which source).
      • Trigger an alert to the development/security team.
      • Prevent the application from using the potentially compromised chain data. Fall back to hardcoded values (if available and applicable) or enter a safe, restricted mode.
    6. Regular Review: Periodically (e.g., weekly) re-run the verification process for all supported chains, even if no changes were detected in the chains repository. This catches slow-moving attacks or errors.

  • Threats Mitigated:

    • Malicious Chain Addition (High Severity): Prevents the application from connecting to a completely fabricated chain designed to steal funds or phish users.
    • Malicious Chain Modification (High Severity): Prevents the application from using altered chain parameters (like a redirected RPC endpoint) that could lead to similar attacks.
    • Incorrect or Outdated Information (Medium Severity): Reduces the risk of using stale data that could cause application errors or minor disruptions.

  • Impact:

    • Malicious Chain Addition: Risk reduced from High to Low (assuming robust cross-referencing and alerting).
    • Malicious Chain Modification: Risk reduced from High to Low (with the same assumptions).
    • Incorrect or Outdated Information: Risk reduced from Medium to Low.

  • Currently Implemented: [Example: Partially Implemented - Cross-referencing with Etherscan is done for Mainnet only. Hardcoded values exist for Mainnet and Polygon. Alerting is implemented via Slack notifications.]

  • Missing Implementation: [Example: Cross-referencing is missing for all chains except Mainnet. No automated regular review process is in place. Alerting is not integrated with our incident response system.]

Mitigation Strategy: RPC Endpoint Validation

  • Description:

    1. Pre-Connection Checks: Before establishing a connection to any RPC endpoint obtained from chains, perform the following:
      • Syntax Check: Ensure the URL is syntactically valid (e.g., valid protocol, hostname, port).
      • Allowlist (Optional but Recommended): If feasible, maintain an allowlist of known-good RPC endpoints. Only allow connections to endpoints on this list. This is a strong defense but requires careful maintenance.
    2. Sanity Check Call: After a connection is established, immediately make a simple, read-only RPC call, such as eth_blockNumber.
    3. Response Validation:
      • Verify the response is received within a reasonable timeout (e.g., 5 seconds).
      • Check that the response is in the expected format (e.g., a valid JSON-RPC response).
      • For eth_blockNumber, ensure the returned block number is a non-negative integer and is within a reasonable range (not excessively large or small).
    4. Timeout Handling: Implement strict timeouts for all RPC calls. If a call takes too long, terminate the connection and consider the endpoint potentially compromised.
    5. Proxy/Firewall (Optional, but related to chain interaction): Use a proxy to restrict outbound connections. Configure to allow connections to known RPC endpoints, limiting connections to specific ports/protocols (HTTPS on port 443).

  • Threats Mitigated:

    • Malicious Chain Addition (High Severity): Helps detect and prevent connections to completely fake RPC endpoints that don't respond or return invalid data.
    • Malicious Chain Modification (High Severity): Helps detect if an existing chain's RPC endpoint has been redirected to a malicious server.
    • Incorrect or Outdated Information (Medium Severity): Can detect if an RPC endpoint is simply down or unresponsive.

  • Impact:

    • Malicious Chain Addition: Risk reduced from High to Medium (it's a good first line of defense, but not foolproof).
    • Malicious Chain Modification: Risk reduced from High to Medium (similar to above).
    • Incorrect or Outdated Information: Risk reduced from Medium to Low.

  • Currently Implemented: [Example: Basic syntax checks and timeouts are implemented for all RPC calls. eth_blockNumber sanity check is done for Mainnet only.]

  • Missing Implementation: [Example: No allowlist is used. Sanity checks are not performed for most chains. No proxy or firewall restrictions are in place.]

Mitigation Strategy: Chain ID Verification

  • Description:

    1. Uniqueness Check: Maintain a list of all Chain IDs your application supports. Before adding a new chain, ensure its Chain ID is not already present in this list.
    2. Trusted List (Optional): Maintain a separate list of known, trusted Chain IDs (e.g., for major networks). Flag any deviations from this list.
    3. Replay Protection: When processing transactions, always include the correct Chain ID. This is a fundamental security practice, but it's especially important when dealing with potentially untrusted chain data.
    4. Alerting: If a duplicate or unexpected Chain ID is detected, trigger an alert to the development/security team.

  • Threats Mitigated:

    • Malicious Chain Addition (High Severity): Prevents replay attacks where a transaction intended for one chain is maliciously replayed on another.
    • Malicious Chain Modification (Medium Severity): Detects if an attacker tries to change the Chain ID of an existing chain to cause conflicts.
    • Incorrect or Outdated Information (Low Severity): Helps catch accidental Chain ID misconfigurations.

  • Impact:

    • Malicious Chain Addition: Risk reduced from High to Low (critical for preventing replay attacks).
    • Malicious Chain Modification: Risk reduced from Medium to Low.
    • Incorrect or Outdated Information: Risk reduced from Low to Very Low.

  • Currently Implemented: [Example: Chain ID uniqueness check is implemented. Replay protection is implemented in transaction signing.]

  • Missing Implementation: [Example: No trusted Chain ID list is maintained. Alerting for Chain ID conflicts is not implemented.]

Mitigation Strategy: Delay Chain Adoption

  • Description:

    1. Monitoring: Continuously monitor the ethereum-lists/chains repository for new chain additions.
    2. Waiting Period: Implement a mandatory waiting period (e.g., 7 days, 14 days) after a new chain appears in the repository. During this period, the chain is not considered valid by your application.
    3. Community Vetting: Use the waiting period to observe community discussions and reports related to the new chain. Look for any red flags or security concerns.
    4. Manual Review (Optional): After the waiting period, perform a manual review of the chain's parameters and any available information before enabling it in your application. This review should include the steps from "Chain Verification Process".

  • Threats Mitigated:

    • Malicious Chain Addition (High Severity): Gives the community time to identify and report malicious additions before your application uses them.
    • Incorrect or Outdated Information (Medium Severity): Allows time for corrections and updates to be made to the chain data.

  • Impact:

    • Malicious Chain Addition: Risk reduced from High to Medium (effectiveness depends on community vigilance).
    • Incorrect or Outdated Information: Risk reduced from Medium to Low.

  • Currently Implemented: [Example: No delay is currently implemented. New chains are used as soon as they appear in the repository.]

  • Missing Implementation: [Example: This entire mitigation strategy is missing.]

Mitigation Strategy: Maintain a Local Cache (with Chain-Specific Considerations)

  • Description:

    1. Data Storage: Store a local copy of the chain data that your application uses. This could be in a database, a local file, or in-memory (depending on your application's needs).
    2. Regular Synchronization: Periodically synchronize the local cache with the ethereum-lists/chains repository (or your pinned version/fork). This synchronization should always be followed by the "Chain Verification Process" and "RPC Endpoint Validation" steps.
    3. Fallback Mechanism: If the repository is unavailable or a chain is removed, your application can continue to function using the data from the local cache.
    4. Stale Data Handling: Implement a mechanism to detect and handle stale data in the cache. This is crucial for chain data:
      • Expiration: Set a relatively short expiration time for cached chain data (e.g., 24 hours).
      • Forced Refresh: Before using cached data, always attempt to refresh it from the repository (and re-verify). Only use the cached data if the refresh fails.
      • Stale Data Warning: If the cached data is used because a refresh failed, clearly indicate to the user (and log internally) that the chain information might be outdated.
      • Disable sensitive operations: If using stale data, disable any operations that could be vulnerable to replay attacks or other issues caused by outdated chain parameters.

  • Threats Mitigated:

    • Legitimate Chain Removal (Medium Severity): Allows the application to continue functioning even if a chain is removed from the repository (but with caveats about stale data).
    • Repository Unavailability (Medium Severity): Provides resilience against temporary outages of the ethereum-lists/chains repository.
    • Incorrect or Outdated Information (Low Severity): Can mitigate the impact of outdated information, but only if stale data handling is robust.

  • Impact:

    • Legitimate Chain Removal: Risk reduced from Medium to Low (with strong stale data handling).
    • Repository Unavailability: Risk reduced from Medium to Low.
    • Incorrect or Outdated Information: Risk slightly reduced, potentially to Medium if stale data handling is weak.

  • Currently Implemented: [Example: A simple in-memory cache is used, but it's not persisted and is lost on application restart. Basic expiration is implemented.]

  • Missing Implementation: [Example: No persistent storage for the cache. Forced refresh before use is not implemented. No warnings about stale data are displayed. Sensitive operations are not disabled when using stale data.]