CVE-2015-10148: Hirschmann HiLCOS Information Disclosure

CVE-2015-10148 Overview

CVE-2015-10148 is a hardcoded credentials vulnerability affecting Hirschmann HiLCOS devices including OpenBAT, WLC, BAT300, and BAT54. These devices are shipped with identical default SSH and SSL keys that cannot be changed, allowing unauthenticated remote attackers to decrypt or intercept encrypted management communications. Attackers can perform man-in-the-middle attacks, impersonate devices, and expose sensitive information by leveraging the shared default cryptographic keys across multiple devices.

Critical Impact

Network attackers can intercept and decrypt management traffic, impersonate legitimate devices, and conduct man-in-the-middle attacks across all affected Hirschmann HiLCOS deployments using the shared default cryptographic keys.

Affected Products

• Hirschmann OpenBAT prior to version 8.80
• Hirschmann WLC prior to version 8.80
• Hirschmann BAT300 prior to version 8.80
• Hirschmann BAT54 prior to version 8.80
• Hirschmann OpenBAT prior to version 9.10

Discovery Timeline

• 2026-04-03 - CVE-2015-10148 published to NVD
• 2026-04-07 - Last updated in NVD database

Technical Details for CVE-2015-10148

Vulnerability Analysis

This vulnerability falls under CWE-321 (Use of Hard-coded Cryptographic Key), a critical cryptographic weakness where manufacturers embed the same SSH and SSL private keys across all devices in a product line. The fundamental security flaw lies in the inability to generate unique cryptographic key pairs per device, meaning any attacker who extracts the keys from one device can use them to compromise communications with all other devices of the same model.

The network-based attack vector allows remote exploitation without authentication. Once an attacker obtains the shared cryptographic keys (either by extracting them from a device they have access to or by obtaining them through other means), they can passively decrypt captured traffic or actively intercept and modify communications between administrators and any affected Hirschmann device on accessible networks.

Root Cause

The root cause of CVE-2015-10148 is a fundamental design flaw in the firmware manufacturing process. Hirschmann HiLCOS devices were shipped with pre-generated, static SSH and SSL cryptographic keys embedded in the firmware. The devices lack functionality to generate unique key pairs during initial setup or allow administrators to replace the default keys. This means every device of the same model shares identical cryptographic material, completely undermining the purpose of encrypted communications.

Attack Vector

The attack vector is network-based and does not require any authentication or user interaction. An attacker positioned on the network path between an administrator and the target device can exploit this vulnerability through the following approach:

1. Key Extraction: Obtain the default SSH/SSL private keys from any affected Hirschmann device (through firmware analysis or physical access to a single device)
2. Traffic Interception: Position themselves to capture encrypted management traffic (via ARP spoofing, network tap, or compromised network infrastructure)
3. Decryption: Use the extracted keys to decrypt the captured SSH or SSL/TLS sessions
4. Man-in-the-Middle: Actively intercept, modify, and forward traffic while impersonating either the device or the administrator
5. Credential Harvesting: Extract administrative credentials and configuration data from decrypted sessions

The vulnerability enables complete compromise of management session confidentiality and integrity across all affected devices sharing the same keys.

Detection Methods for CVE-2015-10148

Indicators of Compromise

• Unexpected SSH or SSL/TLS session anomalies or certificate warnings when connecting to Hirschmann devices
• Network traffic analysis revealing identical SSH host keys or SSL certificates across multiple devices
• Evidence of ARP spoofing or other man-in-the-middle positioning techniques on network segments containing affected devices
• Unauthorized configuration changes to Hirschmann devices without corresponding legitimate administrative activity

Detection Strategies

• Inventory all Hirschmann HiLCOS devices and verify firmware versions against the vulnerable versions (prior to 8.80 for WLC, BAT300, BAT54; prior to 9.10 for OpenBAT)
• Compare SSH host key fingerprints and SSL certificate fingerprints across multiple devices to identify shared cryptographic material
• Monitor network traffic for signs of interception attacks such as ARP cache poisoning targeting management VLANs
• Deploy network intrusion detection systems (NIDS) to alert on suspicious traffic patterns involving device management interfaces

Monitoring Recommendations

• Implement continuous network monitoring on management interfaces and VLANs where affected devices operate
• Enable logging and alerting for all administrative access attempts to Hirschmann devices
• Deploy certificate transparency monitoring if SSL certificates are used for web-based management
• Establish baseline network behavior for device management traffic and alert on deviations

How to Mitigate CVE-2015-10148

Immediate Actions Required

• Upgrade all affected Hirschmann HiLCOS devices to firmware version 8.80 or later (version 9.10 or later for OpenBAT)
• Isolate management interfaces on dedicated, segmented VLANs with strict access controls
• Implement additional authentication mechanisms such as RADIUS or TACACS+ where supported
• Use VPN tunnels or out-of-band management networks to protect administrative traffic

Patch Information

Hirschmann (Belden) has released firmware updates that address this vulnerability. Devices running HiLCOS firmware version 8.80 or later for WLC, BAT300, and BAT54 models, and version 9.10 or later for OpenBAT, include fixes for this cryptographic key management issue. Organizations should consult the Belden Security Bulletin for detailed upgrade instructions and additional guidance. The VulnCheck Advisory provides additional technical context on this vulnerability class.

Workarounds

• Restrict network access to device management interfaces using firewall rules and ACLs to limit exposure to trusted administrator IP addresses only
• Deploy jump hosts or bastion servers for all administrative access, adding an additional authentication layer
• Monitor and log all management traffic using network security monitoring tools to detect potential exploitation
• If firmware updates cannot be immediately applied, consider disabling SSH/SSL management interfaces and using console-only management where operationally feasible