Many of the vulnerabilities and attacks Team82 writes about and presents all over the world at conferences may seem somewhat abstract. We talk about critical vulnerabilities in industrial equipment and connected cyber-physical systems, but in reality, it’s difficult to visualize the consequences of, for example, injecting an engineering workstation with code that is downloaded to a programmable logic controller (PLC) that disrupts or shuts down an industrial process.
We decided to throw back the curtain and help you visualize an attack against a factory floor through the use of a virtual environment called Factory/IO. We won’t be disclosing a new vulnerability or attack against operational technology. Instead, we’ll build a virtual factory inside this environment, and demonstrate a general layout and implementation of typical components, such PLCs, sensors, actuators, and an HMI as well to oversee this plant.
Building such a playground can allow us to not only simulate real world representation of a factory, but illustrate the dependencies between these systems, and also provide us a controlled environment to test different threat models and methodologies in an industrial setting.
In part one, we’ll:
Define some basic OT terminology
Use Factory/IO to build our simulated environment
Connect our factory to Rockwell Automation’s Control Logix5000 1765 L71 PLCs
Program the PLC using structured text (ST) through Rockwell’s RSLogix5000 software
Set up an Inductive Automation Ignition HMI that will allow us to design an HMI panel and visualize industrial processes inside our plant
In part 2 of this series, we showcase different attack techniques on OT technologies. This information should be especially useful for IT cybersecurity staff who are new to OT. Using this type of modeling and scenario helps visualize where risk may need to be managed and how actual exploits can interrupt or disrupt processes managed by OT equipment and impact the bottom line.
Before we begin, let’s define some basic terms:
Programmable Logic Controller (PLC): A rugged computer that processes customized programming for particular industrial tasks.
Engineering Workstation (EWS): An application—generally Windows-based—used to program and deploy automation logic to PLCs
HMI (Human Machine Interface): A user interface that a person can use to monitor and control industrial processes by visualizing data, tracking production processes, and monitor programming changes to devices
CIP (Common Industrial Protocol): This protocol, developed by Rockwell Automation, is used to organize and represent data on the OT network, as well as manage connections and messaging.
Factory/IO produces 3D factory simulations, and is generally used as a PLC training platform, the company says in its documentation. Users can build a virtual factory using its drag-and-drop interface with parts commonly found in typical industrial applications.
Using Factory/IO, we built a simple assembly line segment that transfers pallets with merchandise through our factory. Our assembly line consists of a series of conveyor belts and a turntable that rotates according to sensors that recognize the presence of pallets in their sight. The assembly line is carefully orchestrated by the different states of the sensors. Each sensor is positioned in a way that indicates the position of a pallet on the assembly line.
The next stage for our factory assembly is the wiring of the sensors and actuators to the PLC. The PLC we intend to use is the 1756-L71 CPU of the ControlLogix series from Rockwell Automation.
In order to make our virtual factory as close to reality as possible, we synchronized the virtual PLC inside the Factory/IO software to a physical PLC. To do so we need to go to the File → Drivers
screen and configure the EtherNet/CIP driver that will communicate with our physical PLC. Configuring this connection will allow the real PLC to be in charge of our factory machinery by controlling the wired sensors and actuators that we placed inside our simulated factory.
In order to program the PLC, we use our engineering workstation and open the RSLogix5000 (older version of Studio5000) software package to start building our automation logic using the structured text language.
We start our PLC programming by declaring the tags we are going to use in the automation script. Tags are similar to variables that hold data; they are used in industrial processes to represent a certain value of the underlying process. For example a tag can represent a temperature measurement inside a boiler and will be of the type integer.
In our factory, we have several components that are represented by tags inside our PLC program.
For instance, the on/off state of a diffuse sensor will be represented by a boolean tag of a single bit which holds true/false values and indicates the presence of a physical object in front of the sensor.
Inside the RSLogix5000 software, we define the different components represented by IO artifacts inside the program. We can also create aliases to have more meaningful names to use inside our structured text program.
Next we would like to write the actual code/program for our assembly line. Usually, PLCs support a wide range of programming languages/interfaces, including ladder-diagrams and structured text. We chose to write a simple program using ST; this program will be quite simple. It will sequentially bring merchandise pallets to the turntable, which turns 90 degrees, and send the merchandise further on the conveyor belt.
After writing the program, we compile and download our project to the PLC. By doing so we modify the logic stored inside the PLC, which modifies its behavior. Now the PLC controls the physical components in our factory, which start transferring merchandise on our assembly line.
With our PLC programmed, we next need a Human-Machine Interface (HMI) to bridge between the physical machinery on the plant floor and the human operators who have responsibility over the industrial process. This component connects to PLCs and displays their current status in a user interface. In the HMI, we can see alerts indicating different safety concerns, the status of different components, and other views critical to the proper operation of our process. The HMI is critical because it allows safe and efficient operation, and the ability to monitor and control a physical process.
To create our HMI screens, we chose to use Inductive Automation’s Ignition framework. Ignition enables engineers to create any type of monitoring panel they choose, giving them full control over its design, logic, sources, inputs, and outputs. Using their HMI screen, engineers are able to view and monitor the physical process on their production floor.
In our factory, we will create a panel that counts the number of pallets going through our assembly line. We will start by downloading the Ignition suite locally and setting up a local account.
After downloading the framework, we start the Ignition gateway software by opening the management panel using a browser and accessing http://localhost:8088
. This gives us access to Ignition’s control server, allowing us to start configuring our HMI project.
First, we connect Ignition to the PLC over CIP on port 44818.
Ignition has many drivers that communicate with different PLCs; in our case, a CIP driver connects to our PLC. Meanwhile a local OPC UA server (managed by the Ignition gateway software) externalizes an interface to our PLC. This OPC UA server will be used later by our HMI. Read more about OPC UA in our OPC UA Deep Dive Series.
Next we download the Ignition designer application from the local Ignition web interface. This will help us design the UI for the HMI and create event-driven scripts to display our factory’s status.
Using the designer application, we can start building our HMI view, which will contain a gauge counting the number of pallets moving in our assembly line. To implement this, we create a memory tag that holds the amount value of pallets in our factory.
We want this tag to be incremented each time the second_dif_sensor
is on. To implement this feature we create a simple python script that is invoked each time a sensor value change event occurs.
After saving our project we can open the HMI perspective from the web browser and monitor the industrial process in our virtual factory.
Our factory has come together and operates as expected, all the components have been set. Now we can start thinking about what could go wrong in such a factory. As illustrated below, our physical components are connected to the PLC using the CIP protocol connection maintained by Factory/IO's own drivers. The PLC is set up by downloading the logic for operation from the EWS using the RSLogix5000 software; this is done also over CIP communication. Finally, the Ignition CIP client communicates with the PLC and externalizes an OPC UA server to supply live feed of the PLC state for monitoring on the HMI.
In part two of this series, we will explain and demonstrate some practical and theoretical attacks against factories that defenders should understand and manage risk around. This will be particularly valuable for IT security staff newly responsible for OT, a trend picking up traction within enterprises where cyber-physical systems are prevalent.
CWE-547 USE OF HARD-CODED, SECURITY-RELEVANT CONSTANTS:
Optigo Networks Visual BACnet Capture Tool and Optigo Visual Networks Capture Tool version 3.1.2rc11 are vulnerable to an attacker impersonating the web application service and mislead victim clients.
Optigo Networks recommends users to upgrade to the following:
CVSS v3: 7.5
CWE-288 AUTHENTICATION BYPASS USING AN ALTERNATE PATH OR CHANNEL:
Optigo Networks Visual BACnet Capture Tool and Optigo Visual Networks Capture Tool version 3.1.2rc11 contain an exposed web management service that could allow an attacker to bypass authentication measures and gain controls over utilities within the products.
Optigo Networks recommends users to upgrade to the following:
CVSS v3: 9.8
CWE-547 USE OF HARD-CODED, SECURITY-RELEVANT CONSTANTS:
Optigo Networks Visual BACnet Capture Tool and Optigo Visual Networks Capture Tool version 3.1.2rc11 contain a hard coded secret key. This could allow an attacker to generate valid JWT (JSON Web Token) sessions.
Optigo Networks recommends users to upgrade to the following:
CVSS v3: 7.5
CWE-912 HIDDEN FUNCTIONALITY:
The "update" binary in the firmware of the affected product sends attempts to mount to a hard-coded, routable IP address, bypassing existing device network settings to do so. The function triggers if the 'C' button is pressed at a specific time during the boot process. If an attacker is able to control or impersonate this IP address, they could upload and overwrite files on the device.
Per FDA recommendation, CISA recommends users remove any Contec CMS8000 devices from their networks.
If asset owners cannot remove the devices from their networks, users should block 202.114.4.0/24 from their networks, or block 202.114.4.119 and 202.114.4.120.
Please note that this device may be re-labeled and sold by resellers.
Read more here: Do the CONTEC CMS8000 Patient Monitors Contain a Chinese Backdoor? The Reality is More Complicated….
CVSS v3: 7.5
CWE-295 IMPROPER CERTIFICATE VALIDATION:
The affected product is vulnerable due to failure of the update mechanism to verify the update server's certificate which could allow an attacker to alter network traffic and carry out a machine-in-the-middle attack (MITM). An attacker could modify the server's response and deliver a malicious update to the user.
Medixant recommends users download the v2025.1 or later version of their software.
CVSS v3: 5.7