/vulnerability-chains

name: vulnerability-chains
description: This skill should be used when the user asks about "vulnerability chains", "chained exploits", "multi-step attacks", "SSRF to RCE", "pivot attacks", or needs to identify how vulnerabilities in different components can be combined during whitebox security review.

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:

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

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