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