To get a better understanding of the cyber security implications of this vulerability, Venkat Pothamsetty, director of product mangement for Industrial Defender (www.industrialdefender.com) provides some deep analysis and mitigation possibilities.
As of this posting, Siemens Industry (www.usa.siemens.com) and RuggedCom (www.ruggedcom.com) have not commented on the specifics of the vulnerability, only that "specialists from both companies are investigating this issue and will provide information updates as soon as they become available." Siemens acquired RuggedCom back in January 2012, which provides robust, industrial-quality Ethernet communication products and network solutions. These products are used primarily under rough environmental conditions, for example, in power distribution, in refineries, or in traffic control systems.
Question 1: Which Device Might be Affected?
Venkat Pothamsetty: The reported vulnerability is in Rugged Operating system's (ROS) Secure Socket Layer (SSL). So, it means that only web management of Rugged’s switches and some other small devices such as terminal servers might be affected by the vulnerability.
Question 2: What Does the Vulnerability Mean?
A hard-coded private key means that every device running RuggedCom’s ROS shares the same private key. This also means that the “private” key is not really private (as in secret).
Since the private key is shared across every device, anyone who possesses a vulnerable device or the firmware image for RuggedCom’s ROS can extract that private key and decrypt any network traffic encrypted by that private key.
Similar embedded devices from many vendors are also known to offer Secure Shell (SSH), a remote administration protocol which also relies on encryption for the secure transport of traffic. If the private key used for encrypting SSH traffic were also present in a device’s firmware that network traffic would also be vulnerable to the same vulnerability in the advisory. Any hard-coded encryption key, regardless of use or protocol, would suffer from the same vulnerability. To put this into perspective, if you use key-based authentication for SSH, this would be like having your own personal private key shared with the rest of the world –which would allow anyone to generate your public key and begin impersonating you with that public/private key pair.
Question 3: What are the Implications?
The higher level issue with the recent RuggedCom SSL “vulnerability” is the slow movement of secure communications into OT (operational technology)—and in particular the high barriers and resistance to implementing active Public Key Infrastructure (PKI) management in an OT environment. Many devices in OT don’t even support secure communications such as SSL let alone use an expensive PKI management system.
The utility industry went through this issue with Smart Meters two to four years ago. Ethical hackers demonstrated the ability to get at fixed factory keys in meters—and the industry rushed to new standards, upgradable meters (a do-over for many meters–lots of rip-and-replace and industry project delays)–and then a new market for folks like Certicom that sell PKI management platforms specifically designed for Advanced Metering Infrastructure (AMI) PKI management.
Of course with Smart Meters, the issue was much worse since there were few alternative mitigations–meters hanging on outdoor walls of buildings–and the meters are themselves important end points affecting revenue measurement and operational control. With most OT infrastructure, there is less overall vulnerability and more opportunity to use “Defense in Depth” approaches to mitigate threats despite some specific underlying weaknesses. Most RuggedCom Ethernet switches are presumably behind air gaps or firewalls that reduce the attack surface considerably. Access to the console prompt should then require UserID/Password authentication that provides a defensive layer even for ‘attackers’ with local access. Furthermore, Network Intrustion Detection System (NIDS) and Security Event Manager (SEM) can provide mechanisms to identify anomalies and attacks as they occur, enabling other defensive measures. And as newer versions of firmware are developed with additional security provisions, configuration auditing tools can help track and monitor implementation and ongoing compliance.
Question 4: What about Detection and Mitigation?
The ICS-CERT advisory has no details regarding any particular version of RuggedCom’s ROS. Until a distinction is made, it should be assumed that the most recent and all previous versions of ROS are vulnerable. It is highly unlikely that multiple public keys exist for the hard-coded private key in the advisory. So, a low false positive way to check and see if your RuggedCom devices share the same private key is to browse to the HTTPS web interface of your RuggedCom ROS devices and check the details of the public key being used. If you have multiple devices using the same public key, then it is highly likely that your devices also have the same private key. Taking this advice to heart, the presence of different public keys on your RuggedCom ROS devise does not necessarily indicate that you are NOT vulnerable. It is possible that private/public key pairs changed across versions of ROS yet the encryption keys were still hard coded. Hopefully, ICS-CERT will update the advisory and provide some insight into this particular situation.
Rugged’s switches are deployed deep inside the process control zone and to be exploitable, the switches should be managed by a HTTPS interface. Technically, it is highly unlikely that anybody would be in-between the engineer’s PC and the switch to exploit this vulnerability.
As the ICS-CERT advisory states, if the control operators follow the best practice of VPNing into the PCN (through a process control Firewall) before managing switches, that should serve as a mitigation technique to the vulnerability.
-
Locate control system networks and devices behind firewalls, and isolate them from the business network.
-
If remote access is required, employ secure methods, such as Virtual Private Networks (VPNs), recognizing that VPN is only as secure as the connected devices.
RuggedCom might take a while to fix the vulnerability; however, if the best practices for process control architectures are followed, the vulnerability could be easily mitigated.
