Skip to content

Latest commit

 

History

History
152 lines (130 loc) · 10.9 KB

attack-tree.md

File metadata and controls

152 lines (130 loc) · 10.9 KB

Attack Tree Analysis for app-vnext/polly

Objective: DoS, Data Corruption, or Unintended Resource Consumption via Polly Misuse

Attack Tree Visualization

Goal: DoS, Data Corruption, or Unintended Resource Consumption via Polly Misuse

├── 1. Abuse Retry Policies [HIGH RISK] │ ├── 1.1 Trigger Infinite Retries (DoS) [HIGH RISK] │ │ └── 1.1.1 Craft Input to Always Fail Transient Condition [CRITICAL] │ │ ├── 1.1.1.1 Identify Transient Failure Detection Logic │ │ ├── 1.1.1.2 Craft Input to Match Failure Condition │ │ └── 1.1.1.3 Flood System with Malicious Requests │ └── 1.1.2 Exploit Weak Retry Condition (e.g., overly broad exception handling) [HIGH RISK] │ │ └── 1.1.2.1 Identify Broad Exception Handling in Policy [CRITICAL] │ │ └── 1.1.2.2 Trigger Non-Transient Errors That Match Broad Condition │ ├── 1.2 Exhaust Resources with Excessive Retries (DoS) [HIGH RISK] │ │ └── 1.2.2 Trigger Retries on Resource-Intensive Operations [HIGH RISK] │ │ ├── 1.2.2.1 Identify Operations Wrapped by Retry │ │ └── 1.2.2.2 Craft Input to Trigger Retries on These Operations │ └── 1.3 Data Inconsistency via Retries [HIGH RISK] │ └── 1.3.1 Identify non-idempotent operations [CRITICAL] │ └── 1.3.2 Trigger retries on non-idempotent operations ├── 2. Abuse Circuit Breaker Policies │ ├── 2.1 Force Open Circuit (DoS) [HIGH RISK] │ │ └── 2.1.2 Generate Sufficient Failures to Trip Circuit [CRITICAL] │ │ ├── 2.1.2.1 Craft Input to Trigger Failures │ │ └── 2.1.2.2 Flood System with Malicious Requests │ ├── 2.2 Prevent Circuit from Closing (DoS) [HIGH RISK] │ │ ├── 2.2.1 Identify Half-Open State Behavior │ │ └── 2.2.2 Continuously Trigger Failures During Half-Open Attempts ├── 3. Abuse Timeout Policies │ └── 3.1 Trigger Timeouts to Disrupt Operations (DoS) [HIGH RISK] │ └── 3.1.2 Craft Input or Manipulate Network to Cause Delays Exceeding Timeout [CRITICAL] ├── 4. Abuse Fallback Policies │ └── 4.2 Exploit Weaknesses in Fallback Logic [HIGH RISK] │ └── 4.2.2 Analyze Fallback for Security Issues [CRITICAL] ├── 5. Abuse Bulkhead Isolation Policies │ └── 5.1 Exhaust Bulkhead Resources (DoS) [HIGH RISK] │ └── 5.1.2 Submit Concurrent Requests Exceeding Capacity [CRITICAL] │ ├── 5.1.2.1 Craft Input to Trigger Long-Running Operations │ └── 5.1.2.2 Flood System with Malicious Requests ├── 6. Abuse Cache Policies ├── 6.1 Cache Poisoning [HIGH RISK] │ └── 6.1.2 Inject malicious data for valid keys [CRITICAL] └── 6.2 Cache Exhaustion (DoS) [HIGH RISK] └── 6.2.2 Flood cache with unique keys [CRITICAL]

Attack Tree Path: 1. Abuse Retry Policies

  • 1.1 Trigger Infinite Retries (DoS)

    • Description: The attacker crafts input that consistently triggers the retry policy's failure condition, leading to an infinite retry loop and denial of service.
    • Critical Node: 1.1.1 Craft Input to Always Fail Transient Condition
      • Steps:
        • 1.1.1.1 Identify Transient Failure Detection Logic: Understand how the application determines a transient failure.
        • 1.1.1.2 Craft Input to Match Failure Condition: Create input that matches the identified failure logic.
        • 1.1.1.3 Flood System with Malicious Requests: Send a large volume of the crafted requests.
    • Mitigation: Strictly define transient failure conditions, limit retry attempts, and use exponential backoff.

  • 1.1.2 Exploit Weak Retry Condition (DoS)

    • Description: The attacker identifies an overly broad exception handling mechanism in the retry policy and triggers errors that, while not truly transient, match the broad condition, causing excessive retries.
    • Critical Node: 1.1.2.1 Identify Broad Exception Handling in Policy
      • Steps:
        • 1.1.2.1 Identify Broad Exception Handling in Policy: Analyze the policy configuration or code to find overly general exception handling.
        • 1.1.2.2 Trigger Non-Transient Errors That Match Broad Condition: Cause errors that are caught by the broad exception handler.
    • Mitigation: Use specific exception types in retry policies.

  • 1.2 Exhaust Resources with Excessive Retries (DoS)

    • Description: The attacker triggers retries on operations that consume significant resources (CPU, memory, database connections), leading to resource exhaustion and denial of service.
    • High-Risk Path: 1.2.2 Trigger Retries on Resource-Intensive Operations
      • Steps:
        • 1.2.2.1 Identify Operations Wrapped by Retry: Determine which operations are protected by retry policies.
        • 1.2.2.2 Craft Input to Trigger Retries on These Operations: Create input that causes these operations to fail and trigger retries.
    • Mitigation: Limit retry attempts, use a backoff strategy, and monitor resource usage.

  • 1.3 Data Inconsistency via Retries

    • Description: The attacker triggers retries on operations that are not idempotent, leading to data corruption or unintended side effects.
    • Critical Node: 1.3.1 Identify non-idempotent operations
      • Steps:
        • 1.3.1 Identify non-idempotent operations: Analyze the code to find operations that are not idempotent.
        • 1.3.2 Trigger retries on non-idempotent operations: Craft input to cause failures and retries on these operations.
    • Mitigation: Ensure all retried operations are idempotent.

Attack Tree Path: 2. Abuse Circuit Breaker Policies

  • 2.1 Force Open Circuit (DoS)

    • Description: The attacker generates enough failures to trip the circuit breaker, preventing legitimate requests from reaching the protected service.
    • Critical Node: 2.1.2 Generate Sufficient Failures to Trip Circuit
      • Steps:
        • 2.1.2.1 Craft Input to Trigger Failures: Create input that causes the protected operation to fail.
        • 2.1.2.2 Flood System with Malicious Requests: Send a large volume of the crafted requests.
    • Mitigation: Tune circuit breaker thresholds appropriately.

  • 2.2 Prevent Circuit from Closing (DoS)

    • Description: The attacker continuously triggers failures during the circuit breaker's half-open state, preventing it from closing and restoring normal operation.
      • Steps:
        • 2.2.1 Identify Half-Open State Behavior: Understand how the half-open state works.
        • 2.2.2 Continuously Trigger Failures During Half-Open Attempts: Send requests that cause failures during the half-open state.
    • Mitigation: Limit the number of requests allowed in the half-open state.

Attack Tree Path: 3. Abuse Timeout Policies

  • 3.1 Trigger Timeouts to Disrupt Operations (DoS)
    • Description: The attacker crafts input or manipulates the network to cause delays that exceed the configured timeout, disrupting normal operation.
    • Critical Node: 3.1.2 Craft Input or Manipulate Network to Cause Delays Exceeding Timeout
      • Steps:
        • 3.1.1 Identify Timeout Durations: Determine the configured timeout values.
        • 3.1.2 Craft Input or Manipulate Network to Cause Delays Exceeding Timeout: Create input that causes long processing times or manipulate the network to introduce delays.
    • Mitigation: Set realistic timeouts and use pessimistic timeouts.

Attack Tree Path: 4. Abuse Fallback Policies

  • 4.2 Exploit Weaknesses in Fallback Logic
    • Description: The attacker triggers the fallback mechanism and exploits vulnerabilities within the fallback logic itself (e.g., information disclosure, insecure defaults).
    • Critical Node: 4.2.2 Analyze Fallback for Security Issues
      • Steps:
        • 4.1.1 Identify Fallback Trigger Conditions: Understand what causes the fallback to be executed.
        • 4.1.2 Trigger Conditions to Force Fallback: Cause the conditions that trigger the fallback.
        • 4.2.1 Identify Fallback Implementation: Analyze the code or configuration of the fallback mechanism.
        • 4.2.2 Analyze Fallback for Security Issues: Look for vulnerabilities in the fallback logic.
    • Mitigation: Secure fallback logic and avoid returning sensitive information.

Attack Tree Path: 5. Abuse Bulkhead Isolation Policies

  • 5.1 Exhaust Bulkhead Resources (DoS)
    • Description: The attacker submits a large number of concurrent requests that exceed the bulkhead's capacity, preventing legitimate requests from being processed.
    • Critical Node: 5.1.2 Submit Concurrent Requests Exceeding Capacity
      • Steps:
        • 5.1.1 Identify Bulkhead Capacity Limits: Determine the maximum number of concurrent requests allowed.
        • 5.1.2.1 Craft Input to Trigger Long-Running Operations: Create input that causes operations within the bulkhead to take a long time.
        • 5.1.2.2 Flood System with Requests Targeting the Bulkhead: Send a large number of requests to the protected resource.
    • Mitigation: Set appropriate bulkhead capacity limits and use queuing.

Attack Tree Path: 6. Abuse Cache Policies

  • 6.1 Cache Poisoning

    • Description: The attacker injects malicious data into the cache, which is then served to other users.
    • Critical Node: 6.1.2 Inject malicious data for valid keys
      • Steps:
        • 6.1.1 Identify caching keys: Determine how cache keys are generated.
        • 6.1.2 Inject malicious data for valid keys: Craft requests that cause malicious data to be stored in the cache under legitimate keys.
    • Mitigation: Validate all data before caching and use complex, unpredictable cache keys.

  • 6.2 Cache Exhaustion (DoS)

    • Description: The attacker floods the cache with unique keys, causing legitimate entries to be evicted and leading to performance degradation or denial of service.
    • Critical Node: 6.2.2 Flood cache with unique keys
      • Steps:
        • 6.2.1 Identify cache size limits: Determine the maximum size of the cache.
        • 6.2.2 Flood cache with unique keys: Generate requests with unique cache keys to fill the cache.
    • Mitigation: Set appropriate cache size limits.