Vulnerability Chain Detection

Modern applications consist of multiple services and frameworks. Critical exploits often require chaining vulnerabilities across components.

Why Chains Matter

Single vulnerabilities may have limited impact:

• SSRF with no response → Blind, hard to exploit
• SSTI in internal-only service → Unreachable from internet
• SQLi returning only boolean → Data extraction is slow

Chains amplify impact:

• SSRF → reaches internal SSTI → RCE
• Auth bypass → accesses admin SQLi → full database dump
• Path traversal → reads source → finds hardcoded credentials

Chain Detection Methodology

Step 1: Map the Architecture

# Find orchestration configs
find . -name "docker-compose*.yml" -o -name "supervisord.conf" -o -name "*.k8s.yaml"

# Extract service topology
grep -E "ports:|expose:|links:|depends_on:" docker-compose.yml

# Identify internal-only services
grep -E "127\.0\.0\.1:|localhost:" docker-compose.yml supervisord.conf

Step 2: Identify Pivot Points

Pivot vulnerabilities enable reaching other services:

Step 3: Map Impact Sinks

High-impact sinks in each service:

Step 4: Connect Pivots to Sinks

For each pivot found:

1. What internal services can it reach?
2. What sinks exist in those services?
3. Can attacker-controlled data reach the sink?

Common Chain Patterns

SSRF → SSTI → RCE (DoxPit Pattern)

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Next.js   │────►│   Flask     │────►│    Shell    │
│   (SSRF)    │     │   (SSTI)    │     │   (RCE)     │
└─────────────┘     └─────────────┘     └─────────────┘
     │                    │
     │ Host header        │ render_template_string()
     │ → internal fetch   │ with user input
     │                    │
     ▼                    ▼
  Attacker server      Jinja2 payload
  redirects to         executes code
  internal Flask

Detection:

1. Find SSRF in externally-accessible service (Next.js redirect, fetch with user URL)
2. Find SSTI in internal service (render_template_string)
3. Verify SSRF can reach SSTI endpoint with controllable input

SSRF → Cloud Metadata → Credential Theft

┌─────────────┐     ┌─────────────────┐     ┌─────────────┐
│   Web App   │────►│ 169.254.169.254 │────►│  AWS/GCP    │
│   (SSRF)    │     │ (Metadata)      │     │  (Creds)    │
└─────────────┘     └─────────────────┘     └─────────────┘

Detection:

1. Find SSRF capability
2. Check if app runs in cloud (AWS, GCP, Azure)
3. Verify no IMDSv2 or metadata endpoint blocking

SQLi → File Read → Source Code → Credentials

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   SQLi      │────►│  LOAD_FILE  │────►│   Config    │
│             │     │  (MySQL)    │     │   Secrets   │
└─────────────┘     └─────────────┘     └─────────────┘

Detection:

1. Find SQL injection
2. Check database type and permissions
3. Identify sensitive file paths (config, .env, etc.)

Auth Bypass → Admin Function → High-Impact Vuln

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  Middleware │────►│   Admin     │────►│   Command   │
│  Bypass     │     │   Panel     │     │   Injection │
└─────────────┘     └─────────────┘     └─────────────┘

Detection:

1. Find authentication/authorization bypass
2. Identify what protected functionality becomes accessible
3. Audit protected functionality for high-impact vulns

Chain Documentation Template

When documenting a chain:

## Chain: [Name]

**Impact:** [RCE/Data Breach/Account Takeover/etc.]

**Components:**
1. [Service A] - [Vulnerability Type] at [location]
2. [Service B] - [Vulnerability Type] at [location]

**Prerequisites:**
- [What attacker needs: account, network position, etc.]

**Flow:**
1. Attacker [action] → [result]
2. [Result] enables [next action]
3. [Final impact]

**Evidence:**
- [File:line] - [code snippet]
- [File:line] - [code snippet]

Integration with Full Audit

During /full-audit:

1. Architecture phase maps services and connectivity
2. Threat model identifies trust boundaries
3. Deep dive finds individual vulnerabilities
4. Chain analysis connects vulnerabilities across services

Verification Checklist

Before reporting a chain as exploitable:

• Each component vulnerability confirmed
• Network path between components verified
• Data flow from attacker input to sink traced
• Filters/sanitization accounted for
• Prerequisites documented