“Behind most modern conveniences, there exists a SCADA system somewhere that controls them,” Trend Micro researchers pointed out in a new report that delves in the heart of vulnerabilities affecting SCADA systems’ Human Machine Interfaces (HMIs).
Mean time to patch vulnerabilities from the time they were disclosed by year
“SCADA systems are at the core of water treatment plants, gas pipelines, electrical power distribution systems, wind farms, expansive communication systems, and even civil defense sirens. Therefore, attacks on SCADA systems have the potential to impact a wide range of systems and numerous pieces of critical infrastructure.”
And HMIs are the most logical point of attack: if an HMI is compromised, attackers can do pretty much anything to the critical infrastructure it manages.
Vulnerabilities in HMIs
Trend Micro researchers reviewed ICS-CERT advisories from 2015 and 2016 dealing with HMI vulnerabilities, and have cross-referenced them over 250 zero days purchased by the ZDI program.
They found that:
- Some 20% of identified vulnerabilities are memory corruption issues (code security issues such as stack- and heap-based buffer overflows and out-of-bounds read/write vulnerabilities)
- 19% are credential management issues (hard-coded passwords, passwords stored in clear text, hidden support accounts with full privileges, etc.)
- 23% are issues tied with lack of authentication/authorization and insecure defaults (insecure default configurations, clear-text transmission of sensitive information, etc.)
- 9% are code injection issues that open HMI systems to both common injection types as well as domain-specific ones.
They also found that the mean time to patch vulnerabilities once they’ve been disclosed to the vendor is nearly the same as it has been in the last four years, i.e. around 140 days.
Naturally, some vendors are more quick to patch than others. Cogent Real-Time Systems and Trihedral Engineering are among the quickest, while larger vendors such as ABB, GE, Indusoft, and PTC take on average over 200 days to produce a patch:
Errors in development and patching, and what to do about them
“SCADA system vendors tend to focus on the actual industrial equipment and not on the software that manages them because they make the most profit selling the hardware,” the researchers noted.
“When it comes to the actual codes behind SCADA systems, a majority does not utilize basic defense-in-depth measures such as address space layout randomization (ASLR), SafeSEH, or stack cookies. This may be related to the mistaken belief that these solutions will operate in a completely isolated environment. SCADA solution developers often have little experience with regard to user interface (UI) construction. This is coupled by the fact that developers do not know what the final operating environment will be like for the systems. This causes developers to make assumptions that are often incorrect.”
The report also shows errors that companies make in fixing the reported vulnerabilities. In many instances, they fix specific issues, but don’t go beyond that and, for example, replace banned APIs, problematic functions, etc.
But, most importantly, the researchers have also offered solutions.
“Developers of HMI and SCADA solutions would be well advised to adopt the secure life cycle practices implemented by OS and application developers over the last decade,” they noted.
“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.”
They’ve also pointed vendors (and security researchers) in what they believe to be the right direction when it comes to finding vulnerabilities in HMI solutions:
- Employ basic fuzzing
- Use the Microsoft Attack Surface Analyzer to identify security misconfigurations and increases in attack surfaces, and
- Audit for unsafe, banned APIs, and other problematic functions.