Cyber Security News: Introduction to Attacking ICS/SCADA Systems for Penetration Testers

Since coming into use in the late 1960s, Industrial Control Systems (ICSs) have become prevalent throughout all areas of industry and modern life. Whether in utilities, energy, manufacturing or a myriad of other applications, industrial control systems govern much of our lives.

From the invention of the Modular Digital Controller in 1968 until the mid-1990s, ICS networks were almost always isolated, operating with very limited input or output from outside sources. With the rise of cheap hardware, Microsoft Windows, Active Directory and standardization, corporate networks now receive and process data as well as fine-tune operations from networks outside of the traditional ICS network. While significant effort to ensure segmentation between IT (information technology) and OT (operational technology) networks in modern environments is occurring, the blurring of the lines between IT and OT networks has resulted in a security headache for many industries.

ICS vs. SCADA

While the terms Industrial Control Systems and Supervisory Control And Data Acquisition (SCADA) are often used interchangeably, an important distinction between the two exists. ICS is the name given to the broader category of technology, where SCADA is a subcategory of ICS. Examples of ICS subcategories include:

Distributed Control Systems (DCS)

Offers real-time monitoring and control over processes.
Typically several components are located within a geographically small distance such as an oil refinery, coal plant, hydroelectric dam, etc. DCS are usually contained within the four walls of a building.

Programmable Logic Controllers (PLC)

Typically, ruggedized computers that are the brains of smaller moving parts in a given process control system.

Supervisory Control And Data Acquisition (SCADA)

Acts as a manager of sorts.
Supervisory servers do not typically make decisions.
Supervisory servers typically relay commands from other systems or human operators.

Historians

Collect and store data regarding process statistics, sensor readings, inputs/outputs and other measures.
May be required for regulatory purposes.
Typically data is stored in a database such as MSSQL or Oracle.

Human Machine Interface (HMI)

HMIs are ‘pretty pictures’ allowing a process engineer to monitor an entire ICS system, at a glance.
Usually features graphics of various pumps, relays and data flows.

Remote Terminal Unit (RTU)

Small, ruggedized computers that collect and correlate data between physical sensors and ICS processes.

Adding additional complexity to ICS environments are the many different communications protocols in use. Examples of both common and proprietary protocols implemented in ICS environments include:

ANSI X3.28
BBC 7200
CDC Types 1 and 2
Conitel 2020/2000/3000
DCP 1
DNP3
Gedac 7020
ICCP Landis & Gyr 8979
Modbus
OPC
ControlNet
DeviceNet
DH+
ProfiBus
Tejas 3 and 5
TRW 9550

Typical ICS architecture

When designing ICS environments, high availability, regulatory requirements and patching challenges can significantly constrain design choices. In order to fit into the necessary restrictions, most ICS environments tend to follow the following three tiered structure:

At the uppermost level, the HMIs and SCADA servers oversee and direct the lower levels, either based upon a set of inputs or a human operator. Typically data from the SCADA servers is gathered by the HMI, then displayed to engineering workstations for ICS engineers’ consumption.

The middle layer typically collects and processes from inputs and outputs between layers. The devices performing at this layer, known as Field Controllers, include programmable logic controllers (PLCs), intelligence electronic devices (IEDs) and remote terminal units (RTUs). Field Controllers can coordinate lower level actions based upon upper level directions, or send process data and statistics about the lower level to the upper level.

At the lowest level, devices known as Field Devices are responsible for the moving parts and sensors directing the movement of pumps, robotic arms and other process-related machinery. Additionally, they typically include various sensors to monitor processes and pass data along to the middle layer (i.e. Field Controllers) for data processing.

Communication links between the layers are often required in ICS environments and this communication typically utilizes different protocols. Communication between the SCADA server located in the upper layer and Field Controllers in the middle layer typically utilize common protocols such as DNP3 or Modbus. For communication between Field Controllers and lower level Field Devices, commonly used protocols include HART, Foundation Fieldbus and ProfiBus.

Although designing networks that meet the ICS requirements can be challenging, organizations with ICS typically achieve this by having three zones in their infrastructure:

Enterprise Zones contain the typical corporate enterprise network. In this network are standard corporate services such as email, file/print, web, ERP, etc. In this zone all of the business servers and employee workstations reside.

The ICS demilitarized zones (DMZs) typically allow indirect access to data generated by the ICS system. In this zone there are typically the secondary Historian, as well as some web and terminal applications.

Finally, the Process Control Zones are where the three layers of ICS systems reside. This zone should be inaccessible from the Enterprise Zone and limited to read-only access from the HMIs and SCADA servers.

ICS and Risk

ICS technology was originally designed without consideration of authentication, encryption, anti-malware tools, firewalls or other defense mechanisms. The lack of such considerations influences how these systems are designed and operated. For example, one of the traditional IT risk mitigation strategies is the timely application of security patches to vulnerable systems. While traditional IT systems can absorb downtime, most ICS systems incur significant costs in loss of production preventing them from being patched on a routine basis. Additionally, unlike traditional IT systems, a failed update on an ICS device could have catastrophic consequences such as contaminated food, blackouts, severe injury, or death.

While a determined attacker may gain direct access to the ICS environment via social engineering or physical attacks, it’s more likely they will pivot from the corporate network leveraging trusted network connections to SCADA servers and HMIs. Even if the attacker doesn’t manage to exfiltrate sensitive data or perform sensitive actions, the fines, investigations and regulatory reprisals generated with a breach to the ICS environment could prove financially catastrophic for organizations. The following are real-world ICS incidents and attacks:

In 1982, it is rumored the CIA introduced a piece of malicious software into a Soviet gas pipeline in Siberia that was responsible for the largest non-nuclear explosion ever recorded. (http://www.telegraph.co.uk/news/worldnews/northamerica/usa/1455559/CIA-plot-led-to-huge-blast-in-Siberian-gas-pipeline.html)
In March of 1997, a Massachusetts teenager shut down the Worcester, MA airport by crashing its distributed phone system, main & backup radio transmitters and a printer used to monitor flight progress. (http://www.cnn.com/TECH/computing/9803/18/juvenile.hacker/index.html)
In the Spring of 2000, Vitek Boden, a disgruntled Australian SCADA engineer at Maroochy Water Services intentionally caused 800,000 liters of raw sewage to spill into local parks, rivers and even the grounds of a Hyatt Regency hotel.
(http://csrc.nist.gov/groups/SMA/fisma/ics/documents/Maroochy-Water-Services-Case-Study_report.pdf)
On January 25th, 2003 the SQL Slammer worm caused a safety monitoring system at the Davis-Besse nuclear power plant in Ohio to go offline for nearly five hours. (http://www.securityfocus.com/news/6767)
In 2007 at Idaho Falls National Laboratory, the Aurora generator test was conducted to demonstrate how a simple python script can cause physical hardware components in an electric generator to fall out of sync, causing massive physical damage. (https://www.youtube.com/watch?v=fJyWngDco3g)
In 2008 a Polish teenager demonstrated risks to field devices, in this case rail switches, when he used a repurposed TV remote to transmit commands to his city’s rail systems, causing several derailments. (https://www.wired.com/2008/01/polish-teen-hac/)
In 2010 possibly the most widely known ICS attack occurred at the Natanz nuclear facility in Iran. The malware, eventually named STUXNET, was found to be the most sophisticated ICS malware ever discovered. The malware specifically targeted the PLCs and HMIs associated with the centrifuges used to create fissile nuclear materials.
(https://www.wired.com/2014/11/countdown-to-zero-day-stuxnet/)
In 2014, an unidentified German steel mill sustained damage due to a cyberattack on their ICS network that prevented the mill’s blast furnace from shutting down properly. (https://www.wired.com/2015/01/german-steel-mill-hack-destruction/)
On December 23, 2015 attackers cut power to at least seven 110 kV and twenty three 35kV substations operated by Ukraine’s Prykarpattya Oblenergo and Kyivoblenergo utilities. This attack on their SCADA system cut power to 80,000 customers for six hours. (http://www.theregister.co.uk/2016/01/15/malware_clearly_behind_ukraine_power_outage_sans_utility_expert_says/)

Although attacks like STUXNET may seem like an easy way to cause mayhem and destruction, several special considerations should be taken into account when attacking ICS:

If an attacker can intercept and modify data between Field Devices and Field Controllers, it is possible to feed false data back to HMIs. The HMI will present inaccurate data causing the human operators to make potentially dangerous changes based on this inaccurate data. Proof of a successful man-in-the-middle attack that alters data like this will likely top the list of critical findings.
Many Field Controllers require no authentication, allowing commands to be issued by any system on the network. Leveraging tools such as Scapy, Modbus or DNP3 packets can be crafted with ease.
IT knowledge, when combined with process knowledge, can be leveraged to cause specific kinetic impacts through cyber means; that is the key to the ‘big boom’ Hollywood scenarios. A Proof of Concept attack demonstrating an attack like this will make for a 5-star report.

In our next blog post we’ll walk through a typical ICS/SCADA security assessment, including a description of each of the major phases, what to look out for, and common issues and misconfigurations we’ve seen in the field.