vulnerability-chains

# 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

```bash
# 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:

| Pivot Type | What It Enables |
|------------|-----------------|
| SSRF | Reach internal services |
| Header Injection | Modify downstream requests |
| Open Redirect | Phishing, OAuth token theft |
| Path Traversal | Read configs, source code |
| SQL Injection | Read files, execute commands (in some DBs) |

### Step 3: Map Impact Sinks

High-impact sinks in each service:

| Sink Type | Impact |
|-----------|--------|
| Template Injection (SSTI) | RCE |
| Command Injection | RCE |
| Deserialization | RCE |
| SQL Injection | Data breach, sometimes RCE |
| File Write | Code execution via webshell |

### 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:

```markdown
## 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