CVE-1999-0594

Executive Summary

This report provides a detailed analysis of CVE-1999-0594, a critical design flaw in Microsoft Windows NT 4.0. The vulnerability stems from the operating system's failure to restrict physical access to removable media drives, such as floppy disk and CD-ROM drives, even when the user console is locked. An attacker with physical access to a running but locked Windows NT machine can insert removable media to introduce malicious code or exfiltrate data.

The official CVSSv2 score is 7.2 (High), reflecting the requirement for local (physical) access. However, the potential impact is severe, allowing for complete compromise of the system's confidentiality, integrity, and availability. This is particularly dangerous for legacy systems operating in sensitive environments like Industrial Control Systems (ICS) or air-gapped networks where Windows NT may still be found.

As Windows NT is long past its End-of-Life, no official patch exists. The primary remediation is to decommission the affected systems. Where this is not feasible, stringent physical security controls and BIOS/UEFI hardening are critical compensating measures.

CVSS Breakdown & Threat Level

The CVSS score for this vulnerability requires careful interpretation due to its age. The official NVD rating is based on CVSSv2. The score of 10.0 mentioned in the prompt is inconsistent with a local-access vulnerability and likely a miscalculation; the official vector results in a score of 7.2 (High).

• CVSS v2.0 Score: 7.2 (High)

• Vector: AV:L/AC:L/Au:N/C:C/I:C/A:C

• Attack Vector (AV): Local (L): The attacker must have physical access to the target machine to insert removable media.

• Access Complexity (AC): Low (L): No special skills or conditions are required beyond physical access. The act of inserting a disk is trivial.

• Authentication (Au): None (N): No authentication is needed to exploit this vulnerability. The system can be in a locked state.

• Confidentiality (C): Complete (C): An attacker can boot into an alternate OS from the removable media and access all unencrypted files on the hard drive, leading to a total loss of confidentiality.

• Integrity (I): Complete (C): The attacker can modify system files, plant backdoors, or install ransomware, completely compromising system integrity.

• Availability (A): Complete (C): The attacker can delete critical system files, corrupt the OS, or install destructive malware, rendering the system completely unavailable.

Deep Dive & Mechanics

CVE-1999-0594 is a fundamental flaw in the security architecture of Windows NT. The operating system's security model was primarily focused on network and logged-on user permissions, with insufficient consideration for physical access scenarios against a locked console.

The mechanics of the vulnerability are straightforward:

1. Lack of Hardware Access Control: The Windows NT kernel and session manager do not enforce policies that disable or lock down removable media drives when the workstation is locked. The hardware remains active and accessible.
2. AutoRun/AutoPlay Feature: A primary attack vector was the AutoRun feature. An attacker could craft a floppy disk or CD-ROM with a malicious autorun.inf file. When inserted into a locked but running machine, the OS would parse this file and could automatically execute a specified payload. This would run with the privileges of the currently logged-in user, effectively bypassing the screen lock to gain code execution.
3. Boot Sequence Manipulation: A more devastating attack involves rebooting the system. Since the OS does not restrict the drive, an attacker can reboot the machine and, if the BIOS is configured to boot from removable media first, load a separate, malicious operating system (e.g., a lightweight Linux distribution or DOS). From this external OS, the attacker has raw, unhindered access to the entire contents of the NTFS file system, assuming no disk encryption (which was not a standard feature in Windows NT).

This vulnerability highlights a design philosophy from an era where physical security was often assumed to be a separate, non-OS-related control.

Vulnerable vs. Patched Code

This vulnerability is a systemic design flaw rather than a specific, patchable code error. Therefore, a traditional code diff is not applicable. Instead, we can contrast the behavior of Windows NT with a modern, hardened operating system like Windows 10/11.

Windows NT 4.0 (Vulnerable Behavior):

• No built-in mechanism to disable I/O ports or media drives via policy.
• The locked console state does not sever the OS's connection to hardware like floppy/CD-ROM drives.
• AutoRun is often enabled by default and does not check for a locked session state before executing.
• No native full-disk encryption like BitLocker.

Modern Windows (Patched/Hardened Behavior):

• Group Policy (GPO) / MDM: Administrators can enforce granular policies to control removable media access. Examples include:
  • Deny read/write/execute access to all Removable Storage Classes.
  • Allowing only specific, trusted USB devices (whitelisting).
• BitLocker Drive Encryption: Full-disk encryption protects data at rest. An attacker booting from an external drive would only see encrypted, unreadable data.
• Secure Boot: Modern UEFI firmware with Secure Boot enabled prevents the system from booting from unauthorized or unsigned operating systems.
• Smarter AutoPlay: AutoPlay in modern Windows is more restrictive and often prompts the user for action rather than silently executing code.

The "patch" for this CVE was, in effect, the evolution of the Windows operating system architecture over the subsequent decade.

Exploitation & Lab Setup

The exploitation of this vulnerability is a classic physical access attack.

Lab Setup:

1. Virtualization Software: Use VirtualBox, VMware, or QEMU.
2. Virtual Machine: Create a new VM and install Windows NT 4.0 Workstation or Server.
3. Configuration:
   • Ensure a virtual floppy drive and/or CD-ROM drive is attached to the VM.
   • Log in to the Windows NT VM and lock the screen (Ctrl+Alt+Del -> Lock Workstation).

Exploitation Scenario 1: AutoRun Attack

1. Create a file named autorun.inf with the following content:

   [autorun]
   open=payload.exe
   shell\open\command=payload.exe
   

2. Create a simple payload, for example, a batch file converted to an executable (payload.exe) that creates a file on the C: drive to prove execution:

   @echo off
   echo CVE-1999-0594 exploited > C:\pwned.txt
   

3. Place both autorun.inf and payload.exe onto a floppy disk image (.img) or an ISO file (.iso).
4. With the VM running and locked, "insert" the media by mounting the .img or .iso file to the VM's virtual drive.
5. The OS will detect the media and execute payload.exe. After unlocking the machine, the file C:\pwned.txt will be present.

Exploitation Scenario 2: Data Exfiltration via Boot

1. Create a bootable Linux Live ISO (e.g., a small distro like Tiny Core Linux).
2. Configure the VM's BIOS/UEFI to prioritize booting from the CD-ROM drive.
3. With the VM running, mount the Linux Live ISO and restart the VM.
4. The VM will boot into the Linux environment, automatically bypassing the Windows NT security model.
5. From the Linux shell, you can mount the Windows NT hard drive (e.g., /dev/sda1) and have full read/write access to the entire file system.

Detection Engineering

Detecting an exploit of this specific CVE on a Windows NT system is nearly impossible with modern tools due to the primitive logging capabilities of the OS. However, the principle of detecting unauthorized removable media usage is a critical security control for modern systems. The following Sigma rule is designed for modern Windows environments to detect this class of threat.

This rule detects the connection of removable storage devices, which should be a high-fidelity alert on servers or critical workstations where such devices are prohibited by policy.

title: Removable Media Device Connected
id: 5d1385c7-4f6c-4f7f-94d7-4d7a8585e5c7
status: stable
description: Detects the connection of a removable storage device (e.g., USB drive, external HDD, etc.) which is often a precursor for data exfiltration or malware introduction.
references:
    - https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=6416
    - CVE-1999-0594
author: Valters IT
date: 2023/10/27
logsource:
    product: windows
    service: security
detection:
    # This event ID requires enabling "Audit Removable Storage" policy
    selection:
        EventID: 6416 # A new external device was recognized by the System. In older systems, check System log for PNP events.
    condition: selection
falsepositives:
    - Legitimate use of removable media by authorized users on standard workstations. This rule is best deployed on high-value assets where removable media is restricted.
level: medium
tags:
    - attack.initial_access
    - attack.collection
    - attack.t1200
    - attack.t1052.001

Remediation & Mitigation

As Windows NT is an End-of-Life (EOL) product, there is no patch. The following measures are essential for mitigating risk.

1. Decommission and Upgrade (Primary Solution): The most effective and highly recommended solution is to decommission any remaining Windows NT systems. They should be migrated to a modern, supported operating system like Windows Server 2019/2022 or a suitable Linux distribution.
2. Physical Security (Critical Compensating Control): If decommissioning is absolutely not possible (e.g., legacy operational technology), the system must be protected by robust physical security controls.
   • Place the host in a locked server rack within a secure, access-controlled data center or room.
   • Implement video surveillance and entry logging for the physical location.
   • Physically disable I/O ports such as USB, and if possible, physically remove floppy and CD-ROM drives.
3. BIOS/UEFI Hardening:
   • Set a strong administrative password for the BIOS/UEFI to prevent unauthorized changes.
   • Disable booting from removable media (CD-ROM, USB, floppy drives). Configure the system to boot only from the internal hard disk.
4. Operating System Hardening:
   • Disable AutoRun/AutoPlay: This can be done via a registry modification to prevent automatic code execution when media is inserted. Set the NoDriveTypeAutoRun value in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer to disable it for different drive types.
   • Principle of Least Privilege: Ensure that any accounts used on the system have the minimum necessary privileges.

By combining these layers of defense, the risk posed by this and other physical access vulnerabilities on legacy systems can be significantly reduced.

[!] This Threat Intelligence report was automatically generated by Valters IT (valtersit.com) Neural Engine.

{/* [Security Hash: 2DB5E7437958EC935CEB901A] */}