Hacker Machine Interface – The State of SCADA HMI Security
May 23, 2017 | Brian GorencYou may not realize it, but at some point today, your life will be affected by a supervisory control and data acquisition (SCADA) system. These systems are responsible for maintaining key industrial processes throughout critical infrastructure – things like water treatment plants, electrical grids, and communication systems. Despite their critical nature, security vulnerabilities are not lacking in these systems. At the Positive Hack Days conference in Moscow, we present an analysis of more than 250 security vulnerabilities in SCADA human machine interface (HMI) systems from 2015-2016, based primarily on cases handled by the ZDI. Today, we’re releasing the companion paper that provides the details of what was covered in that presentation.
While various methods exist for exploiting SCADA systems, the HMI provides a tempting target. An HMI displays data from machines to a human and accepts commands from a human operator to machines. A modern HMI provides a highly advanced and customizable visualization about the current state of a system. If you control the HMI, you typically control the entire SCADA system.
More often than not, the operator controls a SCADA system through this interface, which is often installed on a network-enabled location. As such, the HMI must be considered a primary target within a SCADA system, which should be installed on either an air-gapped network or isolated on a trusted network. Experience shows this is not always the case.
Our analysis of both ZDI cases and issues covered by the ICS-CERT shows four primary types of vulnerabilities affecting these systems: memory corruption, credential management, insecure defaults and lack of authentication, and code injection. The paper provides case studies for each of these categories. We also offer some guidance on both finding other HMI bugs and how manufacturers can prevent these bugs.
Developers of HMI and SCADA solutions would be well advised to adopt the secure lifecycle practices implemented by OS and application developers over the last decade. By taking simple steps such as auditing for the use of banned APIs, vendors can make their products more resilient to attacks. SCADA developers also need to expect their products to be used in manners that they did not intend. For example, even though it should be considered a poor security practice, developers must assume their products and solutions will be connected to a public network. By taking the mindset that assumes a worst-case scenario, developers can implement more defense-in-depth measures to add protection.
Finally, we examine the vulnerability exposure window – meaning the time between when a bug is reported to the vendor until a patch is made available. Over the last four years, this averages out to around 140 days. Compared to other industries, this is roughly 30 days more than it would take highly deployed software such as those of Microsoft or Adobe, but significantly less than enterprise offerings from companies such as HPE and IBM. This means that it takes an average of five months before SCADA vulnerabilities ever get patched.
Bugs in SCADA systems will likely be with us for many years to come, and the ZDI program encourages researchers to find and report the bugs associated with HMI and other SCADA systems to our bounty program. By working together, the security of these systems will continue to improve. While a completely secure system will likely never be created, implementing strong research and development tactics will be our best chance to keep the lights on as long as needed.
