What is a SCADA System? An Introduction to Scada Security

What is a SCADA System?

A Supervisory Control And Data Acquisition system is a combination of software and hardware elements that allows for the remote management of processes and infrastructure. They form the backbone of a wide variety of critical infrastructures like power distribution, telecommunications, water treatment, agriculture, manufacturing, oil and gas, transportation, etc. These systems are essential for the normal operation of buildings, industrial plants, businesses, and cities, so when designing them the focus is on creating easily operated and extremely robust systems, sometimes to the detriment of their security.

While earlier examples would typically take the form of an isolated environment using proprietary solutions, modern SCADA systems are highly interconnected networks using standardised, open technology. While combining SCADA, IoT devices and Cloud management offers many benefits like flexibility, cost reduction and overall process efficiency, the risk of attack is also increased in no small part due to Internet connectivity and the ease of remote access.

In 2022, Waterfall Security Solutions reports that there were 57 different operational technology cyber attacks that had physical consequences, an increase of 140% over the previous year. It is likely that this number will only increase, so understanding how security failings can affect SCADA systems is more important than ever.

SCADA System Breakdown

A SCADA system is typically made up of four general components: Data Acquisition, Supervisory Control, Data Storage, and Communications.

Data Acquisition

Programmable Logic Controllers (PLCs) are ruggedized computers designed to be compact and reliable, and to use a simple programming language for easy alteration of internal logic. They can perform constant monitoring and control of site systems, and based on the programming, relay the required data back to the appropriate supervisory system. An Remote Terminal Unit (RTU) is a variant of PLC specialised for remote sites. Characterised by lower power use and wireless communications, they are primarily intended for communications management between process site and the central supervisor. It is common for a remote site to have a PLC managing site control and an RTU handling communications with the supervisory control system.

Supervisory Control

The Human-Machine Interface allows operators to supervise the entire SCADA system. Master Terminal Units are central controllers that communicate with data acquisition devices over the network and present information to the supervisory computer.

Data Storage

The majority of SCADA systems use some kind of SQL database for the collection and storage of the real-time data. Commonly called a Data Historian.

Communications

There are many different communication protocols available, some proprietary and vendor specific; some open and available for general use. DNP3 is one example of a set of communications protocols designed for components in process automation systems that is used in many SCADA networks.

Evolution of SCADA Architecture

The first generation of SCADA was based on standalone mainframes arranged into master/backup units and RTUs connected with wide area networks. One mainframe would act as the backup control system to correct any failures of its primary control system counterpart. WAN protocols were developed by the vendor only for use with their own systems, and did not allow for any functionality beyond transferring data between RTUs and master controllers. RTUs would be connected to the controller via adapters into the backplate of the master’s CPU. Interchanging multiple types of traffic between RTU and controller was not feasible, however it also meant that the SCADA system was completely air-gapped from the outside world. Monolithic SCADA was also incredibly expensive to maintain due to requirements for a standby switching arrangement in case of failure, necessitating a transition to a distributed solution.

The second generation of SCADA systems was facilitated by the development of internetworking and system miniaturisation, making hardware significantly less expensive and easier to set up into networks. While the first gen was just a monolithic controller connected to its RTUs, second generation used smaller, more specialised hardware so was a combination of mini-computers, RTUs and HMIs. Distributed SCADA would typically use a central bus LAN for communications between controllers and operation stations, then each of those would communicate to the RTUs over a WAN (still using proprietary protocols). This distribution of functionality to multiple redundant and less expensive computers across a network meant this SCADA arrangement could be cheaper and more reliable than the previous generation. This generation was still held back by the problems associated with proprietary protocols, software and hardware which the next generation would remedy.

Networked SCADA architecture is characterised by a transition from proprietary technology to cheaper and more standardised systems that make use of the internet protocol for communications. The typical arrangement involves the master control system connecting to the SCADA network over a WAN, local components connecting to each other over Ethernet, and RTUs connected to the local control network via IP over WAN.

The fourth and current generation involves the integration of both IoT technology and the cloud into the SCADA architecture. This means strides forward in flexibility, availability, overall efficiency and scalability. On the other hand this integration means the system’s attack surface is increased by the amount of management that takes place over the internet, as well as IoT hardware design reducing cost and power use at the expense of device security.

SCADA Vulnerabilities

System components being designed without sufficient thought being given to security considerations combined with IP integration and availability being singularly prioritised means SCADA systems tend to have large attack surfaces and thus a wide range of vulnerability types. Different components have different functions, capabilities and availability to an attacker; so each has different attack types commonly associated with them.

Data Acquisition

RTUs and PLCs are the eyes, ears and hands of a SCADA system and will be specialised to the few tasks they have to perform. Lacking security practices can allow an attacker to seize control over the unit, obtain information about the wider SCADA network or escalate privileges. Attacks include:

Ladder Logic modification

In Rockwell Automation Micrologix 1400 PLCs an attacker can MITM communications between controller and PLC to send an authenticated packet with read-write operations. The index offset of the read-write operation is 0xFFFFFFFF, which isn’t considered a number when a floating point. This means when a float is set to read-write operations, the fault is triggered and can lead to info disclosure and modification of logic that manages the equipment the PLC is in control of (CVE-2017-14468).

Path Traversal leading to privilege escalation

The IDS 850C RTU has a file traversal vulnerability that allows remote authenticated users to read arbitrary files, giving an attacker information about file structure as well as access to critical files or directories (CVE-2015-3939). Only requires the addition of traversal elements like “../../” to a request.

Memory corruption

The We-con PLC editor versions 1,3 and 3U suffers from improper input validations which allow an attacker to corrupt memory using specially crafted input strings. This allows the attacker to execute code under the current process (CVE-2021-42707, CVE-2020-25177, CVE-2020-25181).

Authentication Bypass:

Emerson ROC800 RTUs has firmware that allows an attacker to manipulate undisclosed inputs leading to a takeover of the device, allowing for info disclosure and control of the device that could be used in a DoS attack (CVE-2023-1935).

Supervisory Control

The devices that both control the entire network and present information to the humans supervising it are of critical importance, so any attack can have serious consequences. Attacks include:

Path Traversal Denial-of-Service

In SpiderControl Webserver version 2.08 an authenticated attacker can abuse the file upload feature in the HMI to overwrite files anywhere on the server, effectively creating a DoS by overwriting system files (CVE-2023-3329).

Cross-Site Scripting leading to Arbitrary Code Execution

All SIMANTIC HMI versions in 2019 were vulnerable to an XSS vulnerability that would allow an attacker to steal cookies and bypass authentication. With these cookies the attacker could modify device configurations and execute code on the endpoint (CVE-2019-6577)

DLL hijacking to privilege escalation

OPC Systems.NET is an open source HMI that would use an untrusted search path to load DLLs, allowing an attacker to gain privileges via the loading of a trojan DLL instead (CVE-2015-7917).

Buffer Overflow

Eaton HMiSoft VU3 was vulnerable to specially crafted input files that when loaded causes a buffer overflow, possibly causing device crash, information disclosure or remote code execution (CVE-2020-10639).

Data Storage

Most often a type of SQL server, with the risks that they bring. Attacks include:

SQL Injection

The ARDEREG Sistemas SCADA Version 2.203 login page is vulnerable to an unauthenticated blind SQL attack due to insufficient input neutralisation. An attacker could execute arbitrary SQL queries through the login page, allowing for unauthorised access, data leakage, and disruption of industrial processes that relied on the server (CVE-2023-4485). Similarly, the InstanceName, ClassName, and InstancePath parameters in AVEVA’s eDNA Enterprise Data Historian’s web interface are vulnerable to injection, with similar results (CVE-2020-13499, CVE-2020-13500, CVE-2020-13501).

Denial of Service

Schneider Electric’s Wonderware Historian is vulnerable to malicious XML input due to failures in how it parses XML that can cause DoS or disclose file contents.

Communications

The whole SCADA architecture is dependent on effective communication. Attacks against this include are often DoS related, and include:

Denial of Service

DNP3, IEC 61850, Modbus and PROFINET TCP for EN100 Ethernet in 2018 all had a firmware vulnerability that would allow an attacker to send specially crafted Ethernet packets to port 102 that would cause a DoS, requiring a restart (CVE-2018-11451). In the same protocols, there is also a vulnerability that can crash affected applications with specialised HTTP packets, also causing a DoS (CVE-2022-30937).

Weak encryption

In DIGSI 4 and EN100 DNP3, PROFINET, IEC 104, IEC 61850 (and many others) there are vulnerabilities that let an attacker capture network traffic that contains authorisation passwords, and trivially decrypt them.

Example: October 20233 Ukrainian Blackout

On or before June of 2022, the APT “Sandworm” was observed deploying the Neo-reGEORG webshell on a Ukrainian internet-facing server. Approximately one month later, the GOGETTER tunneller was used to proxy C2 communications while also using a Systemd service unit to execute the GOGETTER binary on reboot. Sandworm proceeded to use these Systemd units to disguise the execution as a normal startup service.

In October, Sandworm had access to a hypervisor that hosted a MicroSCADA management instance, it was able to run an ISO image that contained at least three files for exploitation. The system was configured to let inserted CD-ROMs autorun, so when “a.iso” was loaded as a virtual CD-ROM, “lun.vbs” and “n.bat” were executed, using SCIL commands from “s1.txt” (SCIL is a programming language developed for MicroSCADA).

The malicious files contained in “a.iso” worked because the MicroSCADA system was running an end-of-life software version that allowed execution of the SCIL-API. Analysis by Mandiant was unable to identify the exact SCIL commands executed, but the resulting effects on the substation environments suggests commands to open circuit breakers and switch off power through affected substations, depriving an unknown number of people of electricity (coinciding with a series of missile strikes on critical infrastructure across the country). Two days later, Sandworm deployed a new variant of CADDYWIPER in an attempt to make remaining data unrecoverable. This is achieved by wiping all available files, then mapped drives, then the drive partition. This was done with two Group Policy Objects from a domain controller compromised with TANKTRAP.

This is an example of the kind of wide ranging and severe impact resulting from a compromised SCADA system, as well as the importance of effective patch management. The SCIL-API interface utilised in this attack was disabled by default in 2014, meaning the victim instance either hadn’t been updated for more than 8 years, or had been insecurely configured on purpose for ease of use. On top of updating to a supported version, users of MicroSCADA should also:

Configure the software to require authentication and establish least-privilege user permissions.
Configure the base system in “read-only” mode and ensure no external SCIL-API programs are allowed.
Establish robust network segmentation between MicroSCADA hosts and IT networks to reduce available attack surface.
Monitor MicroSCADA management systems for newly created files, unauthorised configuration changes, execution of Scilc.exe and network traffic from MicroSCADA hosts for indicators of compromise.

Patching new vulnerabilities and ensuring functionality means in all likelihood a system must be taken offline while it happens. For an IT network there is generally ample downtime to accomplish this, but when the master controller of a water treatment plant or manufacturing complex absolutely needs to active at all times, it’s all too easy for patching outdated software or replacing legacy hardware to get postponed or simply ignored.

IT and SCADA systems

The operational requirements of SCADA and IT systems differ in important ways, so it is not feasible to have the same security approach for both of them. IT and SCADA systems both require effective patch management to be safe, but the requirement for SCADA to be operational at all times means patches are often not applied as soon as they are released, as is the case with IT systems. While all parts of the CIA triad are important in IT, confidentiality is generally given the highest priority, followed by integrity, then availability. This is essentially reversed for SCADA systems, as it is critically important that they function without obstructions being introduced by security measures. IT systems can be protected by security measures like firewalls that have no significant effect on the performance of the system. SCADA systems are dependent on real time data, and jitter/delay are both things that can be caused by firewalls due to their tendency to interfere with remote procedure calls. If the SCADA system uses proprietary communication protocols, it is always a risk that they were not designed with security as a priority. Rushed design and lack of rigorous pre-release testing makes it easier for malicious actors to find zero-days and exploit them. It can be risky to even test the security of operational systems as testing can cause an unintentional crash.

Conclusion

Every year brings new vulnerability discoveries at every level of SCADA architecture. These systems are getting increasingly interconnected and increasingly available to malicious actors who are willing and able to cause serious harm; for example on the first of December 2023, CISA, FBI, EPA, NSA and the Israel National Cyber Directorate (INCD) issued a joint advisory that “IRGC-Affiliated (Islamic Revolutionary Guard Corps, a branch of the Iranian military) Cyber Actors Exploit PLCs in Multiple Sectors, Including U.S. Water and Wastewater Systems Facilities.” Awareness around the problems SCADA systems face is increasing, but a history of missteps in secure design and implementation makes fixing these endemic issues costly and time consuming. A focus on availability makes sense, but given current threat landscape the only way this can be done properly is by sacrificing some availability for the sake of increased security. Not to the extent that the systems are hamstrung and unable to perform their function, but enough that the functionality they retain can be relied upon to be at least somewhat safe. Improvements can be made at every level: from better securing the IT infrastructure required to access SCADA systems; to using more secure coding practices and investing in the creation or acquisition of redundant systems that allow downtime for patching and upgrades. Ultimately, no useful security control is 100% effective, so a regularly updated disaster recovery plan is incredibly important.

For further reading, in September of 2023 the US National Institute of Standards and Technology published a special publication on every area of operational technology security (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf).