The State of SCADA HMI Vulnerabilities

View Hacker Machine Interface: The State of SCADA HMI Vulnerabilities

Attacking SCADA Through HMIs

SCADA systems run the world’s various critical infrastructure sectors and are thus inherently attractive to different threat actors. Threat actors can use their access to SCADA systems to gather information such as a facility’s layout, critical thresholds, or device settings for use in later attacks. Sabotage, including disruption of services or triggering dangerous and even lethal situations involving flammable or critical resources, represent an undesirable extreme.

Threats like the Stuxnet and Ukranian power grid attacks give us clear ideas about how much damage a determined adversary can inflict not only on the business or operation concerned, but also on the general public. Attackers infiltrate SCADA systems through various means, one of which is through the exploitation of software vulnerabilities prevalent in HMIs. More often than not, the operator controls a SCADA system through the HMI, 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 only be installed on an air-gapped or isolated on a trusted network. Experience shows this is not always the case.

Most Common HMI Vulnerability Categories

We at the Trend Micro Zero Day Initiative (ZDI) Team examined the current state of SCADA HMI security by reviewing all publicly disclosed vulnerabilities in SCADA software that have been fixed from 2015 and 2016, including 250 vulnerabilities acquired through the ZDI program.

We found that most of these vulnerabilities are in the areas of memory corruption, poor credential management, lack of authentication/authorization and insecure defaults, and code injection bugs, all of which are preventable through secure development practices.

Memory Corruption: Memory corruption issues represent 20% of the vulnerabilities identified. The weaknesses in this category represent classic code security issues such as stack- and heap-based buffer overflows and out-of-bounds read/write vulnerabilities.

Credential Management: Credential management issues represent 19% of the vulnerabilities identified. The vulnerabilities in the category represent cases such as using hard-coded passwords, storing passwords in a recoverable format (e.g., clear text), and insufficiently protecting credentials.

Lack of Authentication/Authorization and Insecure Defaults: This category represents 23% of the SCADA vulnerabilities. It includes many insecure defaults, clear-text transmission of sensitive information, missing encryption, and unsafe ActiveX controls marked safe for scripting.

Code Injection Issues: These issues represent 9% of the vulnerabilities identified. While common injection types—SQL, command, OS, code—still occur, there are domain-specific injections that also pose a risk to SCADA solutions.

SCADA Industry Disclosure Statistics Versus Others

We observed that the average time between disclosing a bug to a SCADA vendor to releasing a patch reaches up to 150 days, 30 more days than it would take highly deployed software such as those of Microsoft or Adobe, but significantly less than enterprise offerings from companies such as Hewlett Packard Enterprise (HPE) and IBM.

This means that it takes an average of five months before SCADA vulnerabilities ever get patched. This, of course, differs among vendors. Some vendors may take as little as the same week while larger ones can take up to 200 days to do so.

A complete discussion of the different vulnerability categories, including case studies of vulnerable SCADA HMIs, can be found in our paper, “Hacker Machine Interface: The State of SCADA HMI Vulnerabilities.” We also provide some guidance for vulnerability researchers, including vendors who are auditing their own solutions, regarding discovering bugs quickly and efficiently.