CVE-2015-10148

Executive Summary

CVE-2015-10148 is a critical cryptographic key reuse vulnerability affecting Hirschmann HiLCOS devices, including the OpenBAT, WLC, BAT300, and BAT54 series. The vulnerability stems from the use of identical, hard-coded default SSH and SSL keys across all shipped devices. These keys cannot be changed by the administrator, allowing an unauthenticated, remote attacker to perform man-in-the-middle (MitM) attacks, decrypt encrypted management traffic, impersonate legitimate devices, and exfiltrate sensitive information. The vulnerability has a CVSS score of 7.5 (High) and is currently unpatched for many legacy devices, though Hirschmann has released firmware updates for supported models. No public exploit code or Nuclei template is available, but the attack vector is well-understood and trivial to execute with standard network tools.

CVSS Breakdown & Threat Level

• CVSS Score: 7.5 (High)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
• Attack Vector (AV): Network – The attacker can exploit this vulnerability remotely over the network.
• Attack Complexity (AC): Low – No special conditions or complex steps are required.
• Privileges Required (PR): None – No authentication is needed.
• User Interaction (UI): None – The victim does not need to perform any action.
• Scope (S): Unchanged – The vulnerability affects only the vulnerable component.
• Confidentiality (C): High – Complete disclosure of all encrypted management traffic.
• Integrity (I): High – The attacker can impersonate devices and inject malicious commands.
• Availability (A): None – The vulnerability does not directly impact availability.

Threat Level: Critical for operational technology (OT) environments where these devices are used for industrial control or network management. The inability to change keys means that even after a compromise, the same keys remain valid, allowing persistent access.

Deep Dive & Mechanics

The vulnerability is rooted in the manufacturing process of Hirschmann HiLCOS devices. To simplify initial deployment, the vendor ships all devices with identical, hard-coded SSH host keys and SSL/TLS certificates. These keys are stored in non-volatile memory and are not regenerated during initial setup or factory resets. The keys are publicly known and can be extracted from any device or firmware image.

Attack Flow:

1. Key Extraction: An attacker obtains the default SSH host key (RSA/DSA) and SSL certificate private key from a publicly available firmware dump or a purchased device.
2. Traffic Interception: The attacker positions themselves on the network path between the administrator and the Hirschmann device (e.g., via ARP spoofing, rogue DHCP, or compromised network infrastructure).
3. Decryption: Using the known private key, the attacker decrypts all SSH and SSL/TLS traffic, including administrative credentials, configuration data, and sensitive network information.
4. Impersonation: The attacker can present the same default certificate to the administrator, establishing a valid-looking encrypted session. This allows the attacker to inject malicious commands, modify device configuration, or pivot to other network segments.

The vulnerability is particularly dangerous because it affects the management plane of the device, which is often the only encrypted channel for remote administration. Once the keys are known, all security provided by encryption is nullified.

Vulnerable vs. Patched Code

The vulnerability is not in the code logic but in the static key generation process. The "vulnerable" state is the use of a hard-coded key, while the "patched" state is the use of a device-unique key generated at first boot.

Vulnerable (Hard-coded key):

// Example of vulnerable key loading (pseudocode)
void load_ssh_keys() {
    // Static key embedded in firmware
    static const char *ssh_host_key = "-----BEGIN RSA PRIVATE KEY-----\nMIIEpAIBAAKCAQEA...\n-----END RSA PRIVATE KEY-----";
    // Key is loaded without any per-device uniqueness
    ssh_set_host_key(ssh_host_key);
}

Patched (Unique key generation):

// Example of patched key generation (pseudocode)
void generate_ssh_keys() {
    // Generate a unique key on first boot using device serial number and random seed
    char serial[32];
    get_device_serial(serial);
    RSA *key = RSA_generate_key(2048, RSA_F4, NULL, NULL);
    // Store key in non-volatile memory
    store_key_in_nvram(key, serial);
    ssh_set_host_key(key);
}

The patched firmware ensures that each device generates its own unique SSH and SSL keys during initial provisioning, making MitM attacks infeasible without physical access to the device.

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

• A Hirschmann HiLCOS device with default firmware (e.g., OpenBAT < 8.80).
• Network access to the device's management interface (typically port 22 for SSH, 443 for HTTPS).
• The known default SSH host key (publicly available from firmware analysis).

Steps:

1. Extract the default key: Obtain the default SSH host key from a firmware dump or a known repository (e.g., from a similar device).
2. Perform ARP spoofing: Use a tool like arpspoof to redirect traffic between the administrator and the device.

   arpspoof -i eth0 -t <admin_ip> <device_ip>
   arpspoof -i eth0 -t <device_ip> <admin_ip>
   

3. Intercept SSH traffic: Use mitmproxy or a custom script to intercept the SSH handshake. Since you have the private key, you can decrypt the session.

   # Example using ssh-mitm (a tool for SSH MitM)
   ssh-mitm --remote-host <device_ip> --private-key default_ssh_key
   

4. Decrypt and capture credentials: Once the administrator connects, the MitM tool will decrypt the session and log all keystrokes, including passwords.
5. Impersonate the device: Use the same default key to present a valid SSH host key to the administrator, allowing you to execute commands on the device.

Note: No public exploit code is available, but the attack is straightforward with standard network tools.

Blue Team (Defensive)

Detection:

• Monitor for unexpected SSH host key changes or certificate mismatches.
• Use network monitoring to detect ARP spoofing or unusual traffic patterns.
• Implement SSH host key pinning (e.g., StrictHostKeyChecking yes in SSH config) to alert on key changes.

Prevention:

• Immediately upgrade to patched firmware (HiLCOS 8.80+ or OpenBAT 9.10+).
• If patching is not possible, isolate the management interface on a separate, physically secure network segment.
• Use out-of-band management (e.g., serial console) instead of SSH/HTTPS.
• Implement network segmentation and access control lists (ACLs) to restrict management traffic to trusted IPs only.

Indicators of Compromise (IOCs)

• Network IOCs:
  • ARP cache poisoning (multiple MAC addresses for the same IP).
  • Unexpected SSH host key fingerprints (compare against known good fingerprints).
  • SSL/TLS certificate mismatches (e.g., certificate issued to a different device).
• Host IOCs:
  • Unauthorized configuration changes on the Hirschmann device.
  • New SSH sessions from unknown IPs.
  • Log entries showing failed SSH key verification (if StrictHostKeyChecking is enabled).
• File IOCs:
  • Presence of known default SSH keys in network traffic captures.
  • Firmware images with hard-coded keys (hash of known vulnerable firmware).

Detection Engineering

YARA Rule

rule CVE_2015_10148_Default_SSH_Key {
    meta:
        description = "Detects the presence of known default SSH host keys from Hirschmann HiLCOS devices"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2015-10148"
    strings:
        $key1 = "-----BEGIN RSA PRIVATE KEY-----" ascii
        $key2 = "MIIEpAIBAAKCAQEA" ascii  // Base64 fragment of known key
        $key3 = "Hirschmann" ascii
    condition:
        all of ($key1, $key2) or ($key1 and $key3)
}

Sigma Rule

title: Detection of Default SSH Key Usage on Hirschmann Devices
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects SSH connections using known default host keys from Hirschmann HiLCOS devices
author: Valters IT
date: 2025-04-10
logsource:
    category: network_connection
    product: zeek
detection:
    selection:
        service: "SSH"
        host_key|contains: "MIIEpAIBAAKCAQEA"  # Fragment of known default key
    condition: selection
falsepositives:
    - Legitimate use of default keys on isolated test networks
level: high

Suricata Rule

alert tcp any any -> any 22 (msg:"CVE-2015-10148 - Default SSH Key Detected on Hirschmann Device"; flow:to_server; content:"SSH-2.0-"; content:"MIIEpAIBAAKCAQEA"; distance:0; within:100; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Action: Upgrade all Hirschmann HiLCOS devices to the latest firmware version (8.80 or later for OpenBAT, WLC, BAT300, BAT54; 9.10 or later for OpenBAT). This is the only definitive fix.
2. Workaround: If patching is not possible, disable SSH and HTTPS management interfaces and use only out-of-band management (e.g., serial console) or a dedicated VPN with strong authentication.
3. Network Segmentation: Place all Hirschmann devices on a separate management VLAN with strict ACLs that only allow trusted administrative IPs.
4. Monitoring: Implement the detection rules above to identify any exploitation attempts.
5. Key Rotation: For devices that cannot be patched, consider replacing them with models that support unique key generation.

Valters IT – Securing your infrastructure, one CVE at a time.

{/* [Security Hash: 0886533F3697E2E4F2358F9E] */}