Understanding industrial networks before attacking them
Introduction:
At the end of the 60s, Programmable Logic Controllers (PLCs) were designed to eliminate the high cost of control systems based on relays, we understand the relay as a small electrical / electronic component with a behavior similar to that of the switch that any of us have at home to turn on the lights, only that it is activated by an external signal without the need for a person to activate it. The Schneider Electric group can be considered as the protagonist of the so-called third industrial revolution along with its Modicon, recognized as the first programmable logic controller, its story began when a small group of young engineers who had created a small engineering company called Bedford Associates, directed by Dick Morley, decided to apply for an invitation to tender launched by the General Motors automobile company with the objective of seeking more efficient production processes.
Dick Morley together with his team had a great idea: replace the relays that we mentioned above with electronic cards, which would allow new features to be programmed without the need to rewire or change hardware. It was obviously the winning project and that’s how it was born more than fifty years ago Modicon (MOdular DIgital CONtroler), which they called 084 because it was precisely the Bedford Associates project nº 84. This company sold Modicon in 1977 to Gould Electronics, later it was acquired by the German AEG in 1989.
The Modicon 084, the world's first PLC introduced in 1969. Image used and modified courtesy of Allen-Bradley, Rockwell.
By the 1980's, Distributed Control Systems (DCS) gained popularity within industrial plant environments now increasingly automated, keyboards and workstations replacing large individual control cabinets. Entire production lines and processes could be connected via industrial cable/bus networks to provide monitoring and control from a supervisor's desktop.
The systems available at that time were, in every sense, proprietary, that is, different brands tried to capture a market share by remaining incompatible with competitive systems. At the beginning of the 80s, a strategy to decentralize these systems arose and gave rise to the birth of communication standards between devices such as Fieldbus among others. Thus began the unwinding of central control strategies with a view toward increasing intelligence in each field device and utilizing non-proprietary technology.
Present:
Today, almost all PLC controllers, DCS, Remote Terminal Units (RTU) or Integrated Security Systems (ISS) on the market have a commercial operating system as we can see in the following table:
Windows vulnerabilities are plentiful and reported in various sources on the Internet. The same goes for Linux and QNX. As for Microware OS-9 and VxWorks, these operating systems are not as famous as the previous ones, and consequently their bugs and vulnerabilities are less well known. However, vulnerabilities still exist and we will talk about them further forward.
On the other hand, industrial automation is one of the most popular terms that have been discussed in the last decade, the connections between devices are no longer limited to the same geographical region, going back to the previous example, now the supervisor could be monitoring miles away from the plant from their desktop thanks to the internet, this advance in architecture is known as the fourth industrial revolution or industry 4.0. However, together with it, the doors were opened to new security breaches that we will see throughout this post.
Automation is an important aspect when it comes to industrialization. The goal of this is to minimize human involvement both physically and mentally. Most of the world's critical infrastructure has been automated using electronic devices and systems. The most common examples are elevators, escalators and trains.
Industrial infrastructure relies heavily on automated industrial control systems (ICSs) that have achieved the highest standards in terms of efficiency and performance. ICSs consist of Supervisory Control and Data Acquisition (SCADA) systems, Distributed Control Systems (DCSs) and PLCs. The main functions of such ICS are to detect (collect data), monitor, manage and take action (decision making based on the collected data).
In the following diagram we can see the Purdue model that was adopted from the Purdue Enterprise Reference Architecturefor the ICS architecture. This can be summarized as follows:
- Enterprise
- Level 5: Enterprise network
- Level 4: Site business and logistics
- Industrial Demilitarized zone.
- Manufacturing zone (also called the Industrial zone):
- Level 3: Site operations
- Level 2: Área supervisory control
- Level 1: Basic control
- Level 0: The process
Many believe that PLCs are secure devices due to their isolation from external system networks. However attacks like Stuxnet (a dangerous computer worm created to attack physical infrastructures where its first objective was to compromise the infrastructure of the centrifuges of the uranium enrichment facilities in Iran) have shown the incorrectness of such thoughts. "Computer viruses" are ineffective with PLCs. But recent events suggest that SCADA systems are at significant risk even if they are isolated from the main plant network.
In the 2000s, a Queensland waste management plant was attacked by a former employee where 800,000 liters of raw sewage was dumped into public areas of the city. This happened in Australia only using a laptop and a wireless radio (this fact was taken as an example by MITRE to develop a new methodology regarding ICSs).br>
Maroochydore Sewage Treatment Plant
In 2003 two major monitoring systems at the Ohio Davis-Besse nuclear plant malfunctioned due to an attack that penetrated the computers. This type of malfunction could also lead to the loss of civilian life. Incidents in 1992 and1999 in Bernham, Texas and Bellingham, respectively, caused three deaths and extensive infrastructure damage due to a malfunction in the gas distribution system. There were two metro trains that collided in 2009, resulting in deaths and injuries to passengers. Although such incidents did occur, there was no enthusiasm among the scientific community to explore safety concerns in PLC-related automated systems until the recent past.
As we mentioned above after the malware Stuxnet In 2010, there was a special interest among PLC producers and users to determine the associated security vulnerabilities in PLC-based systems as this achieved a new, highly sophisticated level of attack. The first malware to include a rootkit, it was able to maliciously spy on, compromise, or even exploit other machines to initiate attacks on other systems. It demonstrated a real and sophisticated cybersecurity attack that catastrophically affected various systems such as operator interfaces, display screens, source code within PLCs, taking advantage of Windows Zero Days. In other words, Stuxnet paved the way for secure PLC designed networks. PLC manufacturers such as Hitachi, Mitsubishi, Panasonic, Samsung, and Siemens have been working with antivirus manufacturers such as Kaspersky and Symantec to determine solutions for such vulnerabilities and inefficiencies in PLC systems.
Although PLCs are reliable devices since they guarantee their correct operation in long periods of time and in extreme conditions. A highly customized malware targeting Siemens SCADA systems such as Stuxnetit's just one
typical threat that these devices could face; especially if there are cyber war attacks. Although Stuxnet is one of the most recognized, many other attacks were carried out by other threats such as Flame, Guass, Duqu, Wiper and BlackEnergy malware. More than 50 new attacks have been discovered lurking SCADA systems. Since the appearance of Stuxnet, PLCs have attracted the attention of the hacker community.
SCADA vulnerability disclosures by year - SCADA’s and other components vulnerabilities
Devices within an Industrial network:
In this section of the post we will see some basic definitions of devices and terms that we will use to pose vulnerabilities in said systems.
Reference architecture based on ISA-99
PLCs
PLCs contain an embedded real-time operating system (OS), called firmware, as we saw earlier (OS-9 or VxWorks). It is usually stored in the internal memory of the PLC or in EEPROM (read-only memory programmable and electrically erasable). If an attacker compromises the OS, all the devices controlled by the PLCs can be completely taken over; opening the door to various threats and malicious attacks. Due to their nature and environment, PLCs generally lack security features such as cryptography or intrusion detection through the response times expected under normal operating conditions.
Firmware
It is a set of programming language methods, code, that the programmer writes to communicate information to the PLC. PLC program code can be written using five languages standardized by the international standard IEC 61131, which is an open international standard. RSLogix5000, for example, is software used to write, edit, and compile ladder logic code. The software complies with IEC 61131 standards. The languages are as follows:
PLC language
Es un conjunto de métodos de lenguaje de programación, código, que el programador escribe para comunicar información al PLC. El código de los programas PLC se puede escribir utilizando cinco lenguajes estandarizados por la norma internacional IEC 61131, que es una norma internacional abierta. RSLogix5000, por ejemplo, es un software utilizado para escribir, editar y compilar códigos de lógica en escalera. El software cumple con las normas IEC 61131. Los lenguajes son los siguientes:
Ladder Diagram (LD): It is a representation of instructions, symbols, arranged in steps that imitate wiring diagrams.
Function Block Diagram (FBD): It is a representation of Interconnected graphic blocks represent the process flow and parameters.
Sequential Function Chart (SFC): It's a graphical language consisting of states or steps (with associated actions) and transitions (with associated conditions) used to move from one current state to the next. LD, FBD and ST programs can be written in the SFC structure.
Structured Text (ST): Is a high-level language that resembles "C" or "Pascal".
Instruction List (IL): It is a low-level language that uses mnemonic instructions and is similar to Assembler.
HMIs and other terminals:
These are user interface panels or dashboards that connect operators to field devices; to monitor or control. HMIs used to be simple, isolated, dedicated panels consisting of electrical buttons, lights, switches, etc. The HMIs, for example, allow operators to put the PLC in "Automatic" or "Manual", open or close valves, acknowledge alarms, stop certain devices, etc. Currently, HMIs are more sophisticated and complex. They are built on widely known operating systems like Windows and run Windows based programs. They may be equipped with touch screens, ActiveX, databases, and remote access capabilities; and some are even server or web based. The need to remotely monitor, view, archive or even access related data has brought HMIs to a highly different advanced stage. Currently, HMIs have developed more towards computer-based solutions; for example, WinCC and FactoryTalk.
Human Machine Interfaces (HMIs) make it easy to access any industrial process or event, saving operators from having to review ladder logic code. They can be used as stand-alone, PC-based terminals or even as smartphone applications. The HMIs support leading industrial network protocols such as Ethernet, PROFINET, Modbus, ControlNet, etc. They can be used to control large systems and most PLC related devices. Additionally, many computer-based HMIs are equipped with all the necessary PLC software and tools, such as TIA and RSLogix. These HMIs allow users to access, monitor, modify or even program any associated PLC code; online or offline.
- Display Terminal Units (DTUs) allow operators to control and monitor production processes, associated events or alarms. They display the status of the collected information graphically. They are similar to HMIs but less sophisticated. They run on well-known operating systems like Windows CE. Windows CE, for example, comes with ActiveX controls, remote connectivity via Ethernet, VNC, and FTP.
- Historians Terminal Units (HTU) are recording devices that are based on servers or PC units. They are used to record or archive (events, alarms, activities, etc.), monitor devices and activities related to PLC. They are typical IT computers and therefore suffer from the same vulnerabilities.
Peripherals and I/O devices:
The I/O (in/out) devices are often interconnected through industrial communication networks or physical point-to-point connection to monitor or control activities. They generally consist of:
- Sensors: provide the status of a device or process (such as temperature, flow, position, etc.) as inputs to the PLC by converting physical information into electrical signals.
- Actuators: convert received electrical signals into physical actions. Examples of actuators: valves, solenoids, stepper motors, power relays, etc.
- Other devices that have physical operations: industrial robots (welding, material handlers, vision robots, sealing, etc.), elevators, etc.
Networks:
Data communication between PLCs and field devices can be established via industrial communication networks. Those networks need to be reliable, real-time, and accurate to handle data monitoring and data controllability between various devices. Originally industrial networks began as a direct, limited, point-to-point communication link. A good example of that is a serial port connection.
A signal is used to transmit (carried from the PLC to other devices or actuators, that is, an output) or receive (sent to the PLC from a sensor, that is, an input) through a point-to-point connection or terminal cards. Although limited, a point-to-point serial communications link is less vulnerable to security threats. However, with the advancement of technology and emerging needs, industrial networks have evolved to a more complex level. LAN (Local Area Network) and WAN (Wide Area Network) are good examples. Some industrial networks can handle diagnostics and power on interconnected related devices as well as carry signals from/to toward PLC via I/O modules or scanners such as DeviceNet. Field devices, for example, such as I/O devices or modules, have become more interconnected and software (firmware) based. I/O module devices are now locally or remotely connected to industrial networks for better modularity, lower costs, reduced wiring, quick and easy installation or maintenance, and good diagnostics.
Some of the current and widely used industrial networks are: Modbus, PROFINET, PROFIBUS, DeviceNET, ControlNet, EtherNet/IP. In general, industrial networks consist of I/O devices, scanner modules, and network cables. A PLC communicates with other sensors, actuators or devices through one of the networks mentioned above. DeviceNet, which is widely used, would be a good example of such advancements. DeviceNet mainly consists of the following modules: DNET Scanner, Armor-Block/ArmorPoint and Flex I/O, as we could see in the previous graphs. Each module has its own firmware that could be vulnerable to security threats.
Threats and vulnerabilities
In this section of the post we will see basic concepts about vulnerabilities of the devices mentioned above.
PLC code vulnerabilities
Attention to PLC code vulnerabilities has not been as big of a concern as those related to the network. That's because companies, developers and programmers assume that the codes running inside PLCs are safe and are protected as long as there are no intruders on the network. But that is not the case. PLC codes can carry within their own destructive threats and vulnerabilities that can be exploited by malicious agents or disgruntled users. Vulnerabilities come from the way the code is written or designed. The following are some typical examples:
- Incomplete handling of faults or alarms: Malicious code can disable or silence certain alarms. Basically, the manipulated logic code does not handle or scan all critical faults, alarms, related logic code, or parameters. That is why the operators will not notice the problem since a malicious code goes stealthily and unnoticed; that is, recognizing threats after the damage has occurred.
- Fake results: It occurs when the PLC code skips certain rungs or parameters; for example the inappropriate use of MCR (Master Control Reset) which normally used to ignore non-retentive instructions once enabled.
- Spy Code: A user can use certain instructions, such as the "ADD ON" instruction, which can be exploited to record or monitor some sensitive data or parameters. Those instructions can be added to any logical code and go unnoticed.
- Overflow: Occurs when an instruction or operand or input or output parameter length does not match what the PLC expects. This usually happens because of unskilled programmers or when a malicious attack manipulates parameters./li>
- Duplicate instructions: For some instructions, like the one shown in the graphic below, if they are duplicated on more than one rung, their values will be unpredictable, affecting the logic code and the process controlled by it. Also, that will make it more difficult to debug the code. and find or identify the problem.
- Unused tags: Defining tags in the driver database that are not used in the logic could increase the level of threats; especially if the tags are not driven by a Well-defined ladder logic.
- Missing certain coils or instructions: These can result in unwanted behavior. A user can exploit such a situation to add incorrect output that could severely affect the logic code and associated controlled hardware. For example, if the outputs, defined as Y1, Y11, and Y2 in the controller database—they are used in code, but the value of Y2 has never been driven by logic, a user can exploit this defined instruction for malicious attacks within logic code.
The following graphic shows one way to correct such a scenario; making sure the value of Y2 is driven by a clear and well defined logic
- Canceled instructions (Bypass): When a statement is aborted by an empty parallel branch, it affects the rung-condition-out. When malicious agents or regular developers use such techniques, it would go unnoticed which makes it difficult to debug and detect unless there is a clear warning from the compiler which is often ignored. Also, passes could be done by misplaced jumpers (JMP) or jump to subroutines (JSR).
- Hardcoded values: In certain situations, the use of hard-coded parameters in instructions as comparative ones could increase vulnerabilities. Parameters used in the compare statement can be manipulated by users, attackers, or malicious code without being noticed or overwritten constantly for the appropriate legitimate value.
- The following graphic shows a solution to protect the value "SourceB '' by constantly moving the real time value of the counter.
- Executions: Stray branches, calls, or instructions can lead to inconsistent results. The logic is going to behave in an undesired way based on the unexpected result of executions, in the following graphic, "tmr1.DN", which is a state of the timer "tmr1", is placed just before the parallel bifurcations creating a running scenario between the timer or energizing "Valve 01". To avoid this, instructions or branches must be placed correctly.
The following graphic shows the proper placement of the instruction to prevent an execution.
- Compiler warnings: PLC programmers pay close attention to compiler errors, but often miss the warnings. Compiler warnings could be of great value that could shed light on inappropriate code or instructions that could be exploited by malicious attacks.
- Denial of Service (DoS) : A PLC can be compromised by using malicious code within its own implementation or by performing incorrect programming. The following are some scenarios: Infinite loops, using JSR (Jump to Subroutines) instructions, JMP instructions, nested timers, etc. And fatal faults, which trigger certain failures that could cause the PLC program to not respond correctly.
PLC Vulnerabilities
As we mentioned at the beginning of the post when we show the table of operating systems (OS) most used we talked about Microware OS-9 and here are some examples:
This is a UNIX-like, multi-user, multi-tasking operating system. It has been shown to be susceptible to attacks using ICMP redirects. An attacker could forge ICMP redirect packets and possibly alter the host's routing tables and subvert security by causing traffic to flow in a path the network administrator did not intend.
VxWorks (product of Wind River Systems, acquired by Intel in 2009) is a most famous embedded real-time operating system. It has been used to power everything from Apple Airport Extreme and BMW iDrive hotspots to Mars rovers and the C-130 Hercules aircraft. Unfortunately, it has two serious failures:
The first failure srefers to an exposed VxWorks debugging service (WDB Agent). This service runs over UDP port 17185 and allows full device access, including the ability to manipulate memory, steal data, and ultimately hijack the entire operating system. This service was accidentally left exposed by more than 100 different vendors and affects at least 250,000 Internet-connected devices today.
The second failure relates to a weak password hashing implementation in the VxWorks operating system. Any device that uses the built-in authentication library to handle Telnet and FTP authentication can be compromised. The failure occurs because there are only 210,000 possible hash outputs for all possible passwords. An attacker can simply traverse the most common ranges of hash outputs of around 8,000 similar passwords to gain access to a VxWorks appliance. Using the FTP protocol, this attack would take only about 30 minutes to test all common password permutations.
Schneider Modicon devices are stories apart. It can be easily seen directly from the Schneider firmware that there are a large number of hard-coded accounts on the devices. These accounts allow a user to do anything with the device, that is, they all have the same privileges. For example, new firmware can be uploaded to the device and the Ethernet module in a Modicon used as a general purpose computer. You can even run Linux on it. Schneider left debugging symbols in the firmware, which are quite easy to revert.
Another problem is that the threats are not adequately addressed and not widely reported. This is due to isolated networks, undocumented issues, or untraceable threats. It is difficult, for example, to update a firmware vulnerability or report it to vendors if the PLCs are not directly connected to the vendors' network or internet.
The providers are not going to track down the problems that occurred and get enough details. This makes patching and even validation feedback difficult, especially when PLCs have varieties of platforms.
Unrestricted upload: Having a PLC access point allows the user to upload any malicious code to the PLC, tamper with the currently running one or even upload new firmware. PLCs don't normally check if the uploaded code comes from a verified and trusted source or not. Furthermore, PLCs do not have the ability to know if the uploaded code is malicious or not; as long as it is compiled without errors, the currently running one can be uploaded and overwritten.
Unlocked mode: The PLCs are, in most cases, unlocked and are not protected by any password. This would allow others to access the running logic code, monitor tags, manipulate the code, or even download completely unrelated or wrong logic. Some vendors offer a physical security key to lock the PLC, such as turning the key to "Run". A locked PLC prevents any modification, update or download of code.
The PLC code can be exploited by malware to launch attacks on other PLCs that are on the same network.
Vulnerabilities of IHMs and DTUs
HMIs, DTUs and HTUs are increasingly remotely accessible and interconnected with other networks and devices. Like any other computer, they are vulnerable to any threat within the network and inherit all the vulnerabilities of the operating system on which they are based. For example, HMIs have become generic or “off the shelf” software products that are based on common computer or IT (information technology) systems such as Windows OS, ActiveX, Java, etc. For this very reason they are becoming more vulnerable devices; as attackers consider them to be regular PCs or just another vulnerable operating system on the accessible infected network.
Attacking any HMI, including its related database, could have serious consequences on the software (removing or tampering with codes, alarms or database records) as well as on the hardware; especially since PLCs are immediate real-time systems. Software attacks often take advantage of unsecured networks or infected devices to create software tampers or steal sensitive information. Software vulnerabilities can be exploited by sophisticated cybersecurity attacks that affect PLC devices, such as HMIs, encoders, variable frequency drives, motors, etc. Software attacks are summarized as follows:
External Malware: It can be deployed over the internet, the company network or locally by users - for example, by inserting an infected USB into an HMI, server or PC that is on the PLC-BS network. Malware can spy on and damage industrial systems, slow down or crash networks, and even include PLC rootkits.
Deception Attacks: They include unauthorized and mistaken identity of a command issuing device that can allow remote access and cause fatal damage to software and hardware.
SQL injection: Affects web-based HMIs and servers with database applications (some HMIs or servers). It is a way to take control of a system or insert unexpected SQL statements in a query to manipulate a basis of data.
Field Device Vulnerabilities
One of the main vulnerabilities that can be exploited to manipulate and threaten the integrity and reliability of the PLC is the one that comes from an incorrect or false hardware state, either from inputs or from output commands. The threat occurs when the physical values of a hardware device are manipulated by sending or receiving false values or signals. Altering any value, even one bit, of an input or output would fool the PLC and lead to undesired results in the ladder logic program, endangering equipment, productivity, the environment, and human life. This is accomplished by compromising the associated network, which occurs inadvertently and without modifying any PLC ladder logic code or firmware. In addition to faking their inputs/outputs, hardware devices can be vulnerable if related PLC programs are compromised; whether they are related to the HMI or those of the PLC, such as the ladder logic code or the database. Here is a summary of the hardware vulnerabilities:
Fake entries: Status, parameters or values of compromised sensors or input devices (for example, photocells, part presence sensors, safety emergency stops, VFD - frequency inverters, regular and safety switches, etc.). Furthermore, these vulnerabilities can lead to false inputs made from the HMI to the PLC, e.g. manual operator selection, operator input data, etc.
Fake outputs: Status, parameters, or values of compromised actuators or field devices (for example, valves, VFDs, encoders, stepper motors, etc.). PLC or HMI outputs can also be spoofed, affecting other related devices.
As in all the previous cases, the field devices inherit the vulnerabilities of his companions.
Network vulnerabilities
Currently, most of the PLC network architectures distribute their functionalities through common or open protocols, such as WAN and LAN; Ethernet/IP, DeviceNet, ControlNet, Profibus, PROFINET, and Modbus. The lack of security mechanisms in the protocols makes the network vulnerable to:
- Packet manipulation (latency, spoofing, snooping, dropping, etc.)
- Attacks on the communication stack: network layer, transport layer, application layer and the implementation of protocols (TCP/IP, OPC, ICCP, etc.).
- Attacks on remote or local field devices; Intelligent Electronic Devices (IEDs).
- Address Resolution Protocol (ARP) spoofing, password attack, and denial of service (DoS).
- Back doors and holes in the limits of the network.
- Database attacks.
- Interference, blocking or hijacking of communications; man-in-the-middle attack (MITM).
Network segmentation vulnerabilities
Many companies still assume that they are secure if their industrial networks are disconnected from the internet or isolated. There are still those who believe that segmenting a network is to keep safe and secure PLC networks. They assume that the industrial control network (ICS), which is a form of network slicing, secures all PLCs and associated field devices, including HMIs. But segmenting the ICS network in this way is not secure enough for the following reasons:
- USB threats: The malicious attack could be deployed by an infected USB.
- Inherited: A malicious attack can be carried out by another computer or infected HMI that is connected to the same PLC-BS network. Also, some worms can pass from one PLC to another if they are on the same networks.
- Disgruntled Employees: A disgruntled employee can cause significant damages. They can hack code, infect HMIs or PCs, write latent malicious code inside ladder logic, or even open certain ports to attackers.
- Bad code practice: A programmer could inadvertently write pieces of code that could break certain machines or create DoS; for example, infinite loops.
- Stealthy access: : Some vulnerabilities could take years to detect. Their job is not to create direct damage. They are only there to spy on, collect and steal sensitive information and data.
Next steps
In this post, we have provided an overview of PLCs, (language and hardware), plus an overview of associated industrial networks, field devices, HMIs, and DTUs. Also we have summarized the main vulnerabilities of PLC based devices. Now that we assimilate these concepts about industrial networks and their associated elements, we invite you to follow us on the upcoming publications, where we will refer to cases where this theory applies.
Other links and readings of interest:
return
