CVE-2024-9309

Executive Summary

CVE-2024-9309 is a critical Server-Side Request Forgery (SSRF) vulnerability (CVSS 9.3) discovered in the POST /worker_generate_stream API endpoint of the Controller API Server within haotian-liu/llava version v1.2.0 (LLaVA-1.6). This flaw allows an unauthenticated attacker to trick the victim server into making arbitrary HTTP requests on behalf of the attacker, leveraging the server's credentials and network position. The impact includes unauthorized access to internal resources, data exfiltration, and potential lateral movement within the cloud or on-premise environment. As of this report, no official patch has been released, and the vendor status is marked as UNKNOWN/UNPATCHED.

Supply Chain & Package Security

This vulnerability affects the LLaVA (Large Language and Vision Assistant) project, which is distributed as a Python package via PyPI (llava). Organizations using this package in their AI/ML pipelines are at risk. The SSRF can be exploited to access internal metadata endpoints (e.g., cloud provider instance metadata), internal APIs, or other services that trust the LLaVA server's network identity. Supply chain risk is elevated due to the lack of a patch and the potential for the package to be used in privileged environments.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – Exploitable remotely.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): None (N) – No authentication needed.
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Unchanged (U) – The vulnerable component and the affected resource are the same.
• Confidentiality (C): High (H) – Full read access to internal resources.
• Integrity (I): High (H) – Ability to modify internal resources via POST requests.
• Availability (A): High (H) – Potential to disrupt internal services.

Threat Level: Critical. The combination of network exploitability, no authentication, and high impact makes this a top-priority vulnerability for any organization running LLaVA v1.2.0.

Deep Dive & Mechanics

The vulnerability resides in the POST /worker_generate_stream endpoint of the Controller API Server. This endpoint is designed to accept a worker_id parameter that specifies which worker node should handle a generation request. The server then makes an internal HTTP request to the worker's URL to forward the request.

The flaw is that the worker_id parameter is not properly validated or sanitized. An attacker can supply a malicious URL (e.g., http://169.254.169.254/latest/meta-data/) as the worker_id. The server will then make an HTTP request to that attacker-controlled URL, using its own network credentials and IP address. This allows the attacker to:

1. Access Internal Resources: Reach cloud metadata endpoints, internal APIs, databases, or other services that are not exposed to the internet.
2. Perform Unauthorized Actions: If the internal service accepts POST requests, the attacker can send arbitrary data (e.g., modify configurations, trigger actions).
3. Bypass Firewalls: The request originates from the trusted LLaVA server, potentially bypassing network access controls.

The attack flow:

1. Attacker sends a POST request to /worker_generate_stream with a crafted worker_id pointing to an internal resource.
2. The LLaVA Controller API Server makes an HTTP request to that internal resource.
3. The response from the internal resource is returned to the attacker (if the endpoint returns data) or the attacker observes side effects.

Vulnerable vs. Patched Code

Vulnerable Code (v1.2.0):

# controller/api_server.py (simplified)
@app.post("/worker_generate_stream")
async def worker_generate_stream(request: Request):
    data = await request.json()
    worker_id = data.get("worker_id")
    # No validation of worker_id
    async with aiohttp.ClientSession() as session:
        async with session.post(worker_id, json=data) as resp:
            return await resp.json()

Patched Code (Hypothetical):

# controller/api_server.py (patched)
import re
from urllib.parse import urlparse

ALLOWED_WORKER_HOSTS = ["worker.internal", "10.0.0.0/8"]

@app.post("/worker_generate_stream")
async def worker_generate_stream(request: Request):
    data = await request.json()
    worker_id = data.get("worker_id")
    parsed = urlparse(worker_id)
    if not any(parsed.hostname in allowed for allowed in ALLOWED_WORKER_HOSTS):
        raise HTTPException(status_code=400, detail="Invalid worker_id")
    async with aiohttp.ClientSession() as session:
        async with session.post(worker_id, json=data) as resp:
            return await resp.json()

The patched version would validate the worker_id against a whitelist of allowed internal hosts, preventing SSRF.

Exploitation & Lab Setup

Red Team

Lab Setup:

1. Deploy LLaVA v1.2.0 in a Docker container with a simulated internal service (e.g., a simple HTTP server on port 8080).
2. Ensure the LLaVA server has network access to the internal service.

Exploitation Steps:

1. Identify the target LLaVA Controller API Server endpoint (e.g., http://target-llava:8000/worker_generate_stream).
2. Craft a malicious POST request with a worker_id pointing to an internal resource:

   curl -X POST http://target-llava:8000/worker_generate_stream \
     -H "Content-Type: application/json" \
     -d '{"worker_id": "http://internal-service:8080/admin/secret", "prompt": "test"}'
   

3. Observe the response. If the internal service returns data, it will be reflected in the HTTP response.
4. For blind SSRF (no response data), use out-of-band techniques (e.g., Burp Collaborator) to confirm the request was made.

Advanced Exploitation:

• Access cloud metadata: http://169.254.169.254/latest/meta-data/
• Scan internal network: Use the SSRF to probe internal IPs and ports.
• Chain with other vulnerabilities (e.g., if the internal service has its own flaws).

Blue Team

Detection:

• Monitor for POST requests to /worker_generate_stream with unusual worker_id values (e.g., IP addresses, cloud metadata URLs).
• Look for outbound HTTP connections from the LLaVA server to unexpected internal IPs or ports.
• Use network flow logs to detect anomalous traffic patterns.

Hunting:

• Search logs for worker_id parameters containing 169.254.169.254, localhost, 127.0.0.1, or private IP ranges.
• Correlate with any unusual responses or errors from the LLaVA server.

Mitigation (Immediate):

• Implement a Web Application Firewall (WAF) rule to block requests with suspicious worker_id values.
• Restrict outbound network access from the LLaVA server using a firewall or network policy.
• If possible, disable the vulnerable endpoint until a patch is available.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Outbound HTTP requests from the LLaVA server to internal IP addresses (e.g., 10.x.x.x, 172.16.x.x, 192.168.x.x).
  • Requests to cloud metadata endpoints (e.g., 169.254.169.254, fd00:ec2::254).
  • Requests to localhost or 127.0.0.1 on non-standard ports.
• Log IOCs:
  • Log entries containing worker_id with URLs pointing to internal or private IPs.
  • Error logs indicating failed connections to internal resources (if the internal service is not reachable).
• File IOCs:
  • No specific file-based IOCs; this is a network-based vulnerability.

Detection Engineering

YARA Rule

rule CVE_2024_9309_SSRF_LLaVA {
    meta:
        description = "Detects SSRF exploitation attempts against LLaVA Controller API Server"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "CVE-2024-9309"
    strings:
        $worker_generate = "/worker_generate_stream"
        $worker_id = "worker_id"
        $internal_ip = /(?:10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(?:1[6-9]|2\d|3[01])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|127\.\d{1,3}\.\d{1,3}\.\d{1,3}|169\.254\.\d{1,3}\.\d{1,3})/
        $metadata = "169.254.169.254"
    condition:
        $worker_generate and $worker_id and ($internal_ip or $metadata)
}

Sigma Rule

title: CVE-2024-9309 SSRF Exploitation Attempt
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects SSRF attempts against LLaVA Controller API Server
author: Valters IT
date: 2024-10-27
logsource:
    category: webserver
    product: generic
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/worker_generate_stream'
        cs-uri-query|contains: 'worker_id'
    filter:
        cs-uri-query|contains:
            - '169.254.169.254'
            - '127.0.0.1'
            - 'localhost'
            - '10.'
            - '172.16.'
            - '192.168.'
    condition: selection and filter
falsepositives:
    - Legitimate internal worker communication (if whitelisted)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-9309 SSRF Exploitation Attempt"; flow:to_server; content:"POST"; http_method; content:"/worker_generate_stream"; http_uri; content:"worker_id"; http_client_body; pcre:"/(?:169\.254\.169\.254|127\.0\.0\.1|localhost|10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(?:1[6-9]|2\d|3[01])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3})/Ri"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the vulnerable endpoint if possible, or restrict access to it via firewall or authentication.
2. Implement input validation on the worker_id parameter to only allow known, safe internal hosts.
3. Apply network segmentation to limit the LLaVA server's outbound access to only necessary internal services.
4. Monitor logs for exploitation attempts using the provided detection rules.

Long-Term Fix:

• The vendor (haotian-liu) should release a patch that validates the worker_id against a whitelist of allowed worker hosts. Until then, consider forking the repository and applying the fix manually.
• Upgrade to a patched version once available.

Workaround:

• Use a reverse proxy (e.g., Nginx) in front of the LLaVA server to filter out malicious requests:

  location /worker_generate_stream {
      if ($request_body ~* "169\.254\.169\.254|127\.0\.0\.1|localhost|10\.|172\.1[6-9]\.|172\.2[0-9]\.|172\.3[01]\.|192\.168\.") {
          return 403;
      }
      proxy_pass http://llava-backend;
  }
  

Valters IT
Securing Digital Frontiers