CVE-2013-0335

Executive Summary

CVE-2013-0335 is a vulnerability in OpenStack Compute (Nova) that allows a remote authenticated user to gain unauthorized access to a virtual machine (VM) console by reusing the VNC token of a deleted VM that was previously bound to the same VNC port. The flaw affects all major supported distributions of the Essex, Folsom, and Grizzly release lines. Successful exploitation results in full console access to a tenant's VM, enabling data exfiltration, malware deployment, and lateral movement within the virtualized infrastructure, with a CVSS score of 7.6.

Technical Analysis

The vulnerability resides in the VNC proxy logic embedded within Nova's nova-vncproxy and nova-consoleauth services. In the affected versions, when a VM instance was deleted, the VNC port it was using was NOT immediately released or regenerated. The VNC token associated with that deleted VM remained valid for a window of time. If a new VM instance was subsequently created and assigned the exact same VNC port number (due to a race condition in port recycling), the old, still-valid token could be used to connect to the new VM's console.

The mechanism is as follows:

1. Token Generation: When a user requests VNC console access (nova get-vnc-console), nova-consoleauth generates a random token and maps it to a host:port tuple. The nova-vncproxy uses this token to proxy the WebSocket connection (via websockify) to the QEMU VNC server listening on the designated port (default 5900 + instance-specific offset).

2. Port Reuse: The critical flaw is that the VNC port for a deleted instance was not immediately tracked as "in-use" by the scheduler. The port number (e.g., 5905) could be assigned to a new instance shortly after the old one was destroyed, without sufficient token invalidation logic in nova-consoleauth.

3. Token Reuse: An authenticated attacker who had previously recorded a valid VNC token for a deleted instance could use that token to connect to the nova-vncproxy service. The proxy, relying on nova-consoleauth for validation, would check the token against the current host:port mapping. Because the token was still valid (not expired or revoked) and the new VM now occupies that exact host:port, the proxy would grant access to the new VM's console.

The root cause is classified as CWE-613 (Insufficient Session Expiration). The token lacked proper invalidation upon instance deletion and port reassignment. The attack surface is the nova-consoleauth API endpoint, typically listening on a RabbitMQ queue or directly on port 6080 (for the proxy), and the nova-vncproxy WebSocket endpoint. Authentication is required first, but any user with standard tenant credentials can exploit this.

Exploitation Scenarios

Attack chain for a malicious tenant user:

1. Reconnaissance/Target Identification:

   • Attacker authenticates to the OpenStack API with their valid tenant credentials.
   • The attacker lists all network hosts and VNC proxy public endpoints (nova get-vnc-console on the compute node).
   • Attacker identifies a target tenant and uses OS-level timing or API enumeration (nova list --all-tenants is not available, but they can monitor port allocation patterns) to predict when a target VM might be deleted.

2. Trigger/Weaponization:

   • Attacker creates a sacrificial VM and immediately requests a VNC console token (nova get-vnc-console <instance> novnc). This returns a URL containing a token parameter (e.g., http://proxy:6080/vnc_auto.html?token=abc123def456&path=...). The attacker records this token.
   • Attacker deletes the sacrificial VM.
   • RAPIDLY, the attacker creates a new VM. Due to the scheduler's port recycling behavior, there is a statistically high chance the new VM receives the same VNC port (e.g., port 5903) as the deleted one, especially in a single-compute-node environment with few active instances.
   • If the attacker's new VM is the one that reuses the port, they have simply created a decoy. However, the exploit works better when the target's VM is the one that reuses the port.

   Alternative two-user attack:

   • Attacker runs a process that continuously creates and deletes VMs to rapidly cycle through port numbers, effectively "reserving" a specific port.
   • Victim tenant creates a new VM. The scheduler assigns it the port that the attacker just freed.
   • Attacker now uses the token they recorded during their rapid VM cycling to connect to the victim's VM.

3. Payload/Execution:

   • Attacker connects their WebSocket client to ws://<nova-vncproxy>:6080/?token=<stolen_token>.
   • The proxy validates the token against nova-consoleauth and finds it valid (still mapped to the target host:port).
   • The attacker receives the raw VNC framebuffer. They use a VNC client (like vncdotool or virt-viewer) to interact with the VM's graphical console.
   • Because VNC does not require credentials if the console is active, the attacker has full keystroke and mouse access to the VM's login screen (if the VM is locked) or full desktop access (if unlocked).

4. Post-Exploitation:

   • The attacker can log into the VM using any credentials the legitimate user might have typed into the VNC console (keylogging).
   • The attacker can inject keystrokes to run commands as the VM's local user, escalate privileges to root, and exfiltrate data via network connections.
   • The attacker can modify the VM's configuration to add backdoor SSH keys or alter firewall rules.

Impact Assessment

Business Impact: This is a complete confidentiality and integrity failure within the cloud boundary. A tenant can compromise another tenant's VM console, leading to:

• Confidentiality: Full read access to all data displayed on the VM console.
• Integrity: Write access to the VM filesystem via the console (if OS allows, e.g., recovery mode or login shell).
• Availability: An attacker can shut down the VM or corrupt its boot process.

CVSS Justification (7.6 — HIGH):

• AV:N — Exploitable over the network.
• AC:L — No special conditions are required; the attack only needs a port reuse event.
• PR:L — Requires valid cloud tenant credentials.
• UI:N — No user interaction from the victim.
• S:U — Scope is unchanged (the VM is within the tenant's logical boundary).
• C:L — Confidentiality impact is limited to the console output, not the full memory/storage.
• I:H — Integrity impact is high; attacker can inject commands.
• A:L — Availability can be reduced by shutting down the VM.

Blast Radius: Entire multi-tenant cloud environment. Any cloud running OpenStack Nova with Essex, Folsom (up to 2012.2.3), or Grizzly (up to 2013.1) is vulnerable. The issue is compounded in dense environments where port cycles are frequent.

EPSS Note: EPSS score of 0.02120 (80th percentile) indicates this is a known and potentially exploited vulnerability, though it has not made the CISA KEV list, suggesting no confirmed nation-state exploitation has been observed.

Detection Guidance

Sigma Rule

title: OpenStack Nova VNC Token Reuse Attempt
id: 9f8c7e2a-1c15-4a6b-9b7d-78a9f0c3e1b2
status: experimental
description: Detects requests to nova-vncproxy that use tokens that may have been previously issued for deleted instances.
logsource:
    product: openstack
    service: nova
detection:
    selection_auth_log:
        module: nova.auth
        event: authentication
        message|contains: 'token'
        outcome: 'success'
    selection_proxy_log:
        module: nova.vncproxy
        message|contains: 'vnc'
        outcome: 'success'
    filter_known_ips:
        dest_ip|cidr:
            - '10.0.0.0/8'  # Example trusted network
    condition: selection_auth_log and selection_proxy_log and not filter_known_ips
    timeframe: 5m
level: high
fields:
    - src_ip
    - user.name
    - instance.id
    - vnc.port
falsepositives:
    - Legitimate console requests from admins
    - Rapid instance lifecycle operations in CI/CD
tags:
    - attack.privilege_escalation
    - cve.2013.0335

YARA Rule

rule OpenStack_VNC_Token_Reuse_CVE_2013_0335
{
    meta:
        author = "Valters IT Security Intelligence"
        description = "Detect log entries indicating VNC console access that may correlate with token reuse"
        cve = "CVE-2013-0335"
        date = "2024-01-15"
    strings:
        $s1 = "get_vnc_console" ascii wide nocase
        $s2 = "vnc_token" ascii wide nocase
        $s3 = "token_expired" ascii wide nocase
        $s4 = "instance_deleted" ascii wide nocase
        $s5 = "port_allocated" ascii wide nocase
        $s6 = "nova-consoleauth" ascii wide nocase
        $s7 = "nova-vncproxy" ascii wide nocase
    condition:
        ( uint16(0) == 0x4D5A or filesize < 10MB ) and
        ( 2 of ($s*) ) and
        ( $s6 or $s7 )
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2013-0335 OpenStack Nova VNC token reuse attempt"; content:"/vnc_auto.html?"; http_uri; nocase; content:"token="; http_uri; distance:0; flow:established,to_server; reference:cve,2013-0335; reference:url,https://security.openstack.org/ossa/OSSA-2013-006.html; classtype:attempted-user; sid:20241335; rev:1;)

Elastic Detection

sequence by host.name with maxspan=5m
    [ authentication where event.outcome == "success"
        and message contains "nova-consoleauth"
        and user.name != "admin"
        and action == "get_vnc_console" ]
    [ web where url.path == "/vnc_auto.html"
        and url.query contains "token="
        and source.ip != "10.0.0.0/8" ]

Alternative: Monitor Nova compute logs for rapid instance create/delete patterns:

sequence by host.name with maxspan=2m
    [ process where process.name == "nova-compute"
        and process.args in ("virtual_power_delete", "instance_action") ]
    [ process where process.name == "nova-compute"
        and process.args == "allocated_port" ]

Splunk SPL Query

index=openstack sourcetype=nova:auth OR sourcetype=nova:vncproxy
| where match(message, "(?i)get_vnc_console|vnc_token")
| stats count by user.name, src_ip, instance.uuid, vnc_port
| where count > 1
| eval time_window = _time - lag(_time)
| search time_window < 300
| table _time, user.name, src_ip, instance.uuid, vnc_port, count
| sort - count

Alternate query for port cycling:

index=openstack sourcetype=nova:compute
| rex field=_raw "deleting instance (?P<del_uuid>\S+)"
| rex field=_raw "computing claim for instance (?P<new_uuid>\S+)"
| stats values(del_uuid) as deleted, values(new_uuid) as created, dc(del_uuid) as delete_count by host
| where delete_count > 20 AND _time > relative_time(now(), "-1d")

Wazuh OSSEC Rule

<group name="openstack,">
    <rule id="100335" level="12">
        <decoded>ossec</decoded>
        <field name="message">\.*nova-consoleauth\..*token.*</field>
        <description>OpenStack Nova: VNC token validation activity observed. Potential CVE-2013-0335 exploitation.</description>
        <group>authentication_success,openstack,</group>
    </rule>
    <rule id="100336" level="14">
        <decoded>ossec</decoded>
        <field name="message">\.*allocate_port\..*carryover.*</field>
        <description>OpenStack Nova: Port reuse detected shortly after deletion. Investigate for malicious token reuse (CVE-2013-0335).</description>
        <group>openstack,</group>
    </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 3/4 (LIKELY) — Confirmed fixed in Grizzly (2013.1) and Folsom (2012.2.4) per NVD and Debian security advisories.

1. Immediate Mitigations:

   • Restrict VNC Console Access: Disable VNC console access entirely for non-admin users via policy (nova.policy.json) or API filtering.
   • Network Segmentation: Isolate nova-vncproxy endpoints behind a VPN or jump host. Never expose the VNC WebSocket port (6080) to untrusted networks.
   • Enable Token TTL: If configuration supports, reduce the VNC token Time-To-Live to a very short window (e.g., 30 seconds) to reduce the exploit window.
   • Fix Port Allocation: Manually configure nova.conf to use a fixed port range and ensure vncserver_listen uses a non-cyclable pattern.

2. Patch/Upgrade Steps:

   • Grizzly (2013.1) or higher: Upgrade all nova-* packages (nova-compute, nova-conductor, nova-api, nova-consoleauth, nova-vncproxy) to the latest stable release for your distribution.
   • Folsom (2012.2.x): Upgrade to version 2012.2.4 or later.
   • Essex (2012.1.x): Apply the Debian security patch (DSA-XXXX) or upgrade to a newer release line immediately.
   • Verify Fix: After upgrade, delete a VM, create a new one, and attempt to reuse the old token. The system should reject it with a "Token expired" error.

3. Long-Term Hardening:

   • Enable Keystone-to-Nova v3 API: Use the newer API which has proper token revocation hooks.
   • Implement VNC Authentication: Use QEMU's built-in VNC password authentication in addition to the Nova token proxy.
   • Audit Lifecycle: Implement a periodic check that deletes orphaned VNC tokens upon instance deletion (cron job/cloud-init).
   • Monitoring: Deploy the Sigma/Splunk detections above to continuously monitor for rapid VM create/delete cycles or unusual console access patterns from the same user.

References

• NVD Entry: CVE-2013-0335 - NVD
• OpenStack Security Advisory: OSSA-2013-006 — original advisory with patch links.
• Debian Security Tracker: CVE-2013-0335 - Debian — provides patch details for Essex/Folsom.
• Red Hat Bugzilla: Red Hat Bug 918132 — includes a technical deep-dive and reproducer discussion.
• Launchpad Bug: CVE-2013-0335 on Launchpad — original bug report with upstream patch commit.

Threat Actor Activity: No specific APT group has been publicly attributed to exploiting CVE-2013-0335. The EPSS score (80th percentile) suggests it is a known target for opportunistic scanning in cloud environments, but no CISA KEV listing indicates it has not been observed in major government-backed campaigns.