Hacking a PLC on an industrial network
Cyber security for industrial control systems is often focused on the Domain controller settings, configuring anti virus scanning applications and using managed switches for segregation.
A PLC is an example of a device which acts in a semi autonomous manner with where communication has become a norm with TCP based applications over Ethernet. Data flow between a HMI, DCS or Historian is essential in most designs and as such the question of how can I stop this system of being maliciously manipulated needs to be asked.
I have worked with many programmers at the OPC server development level which focuses on providing functionality for Automation Engineers and business intelligence specialists. There is a big question here however, if I deliberately write an application with malicious intent, can I be stopped by a cyber security team that doesn’t focus on the PLC Ethernet card. In the modern era the answer is most often no.
Using the S7 PLC as an Example
The Siemens PLC is the most widely used PLC in the world. Due to this it’s obviously the biggest target for infection. Several years ago I developed the APP_S7 driver which allowed me to focus on the low level communication between PC based applications and both the S7 1500 – S7 300.
The great thing here is that the S7 300 was a target for the famous stuxnet and the S7 1500 was created to be the roll model in cyber security defense. In the development process I tried to HACK the PLC and then tighten the security. As I did this, it became obvious that the enterprise applications or middle ware applications could not perform basic data acquisition.
With this in mind, I can compensate for my own applications but I cant recode software owned and maintained by third party developers.
Forming a basic segregation plan on the network
If controllers or other intelligent devices with no or minimum self-protection are located in a network segment, a good option to consider is to create a secured network environment for these devices. One approach to achieve this is by the use of network security appliances. Additional security can be provided by segmenting individual sub-networks, through a cell protection concept or a demilitarized zone.
As a basic example in plain English, only allow the machine with the OPC Server (Kepware, Makitron etc) to have network access to the PLC. This is a great start in reducing risk.
Online communication Methods and Protections
In TIA, the S7 CPU offers three (S7-300/S7-400/WinAC) or four (S7-1200(V4)/S7-1500) access levels to limit the access to certain functions. Setting the access level and the passwords restricts the functions and memory areas that are accessible without a password. The individual access levels and the respective passwords are defined in the object properties of the CPU.
|
Access
|
Description
|
|
Level 1 (no protection)
|
The hardware configuration and the blocks can be read and modified by anyone.
|
|
Level 2 (write protection)
|
With this access level, only read access is allowed without a password, which means that the following functions can be carried out:
- reading the hardware configuration and the blocks
- reading diagnostic data
- loading the hardware configuration and the blocks into the programming device.
- changing the operating state (RUN/STOP)(not for S7-300 / S7-400 / WinAC)
Without the password the following functions cannot be carried out:
- loading the blocks and hardware configuration into the CPU
- writing test functions
- firmware update (online)
|
|
Level 3 (write/read protection)
|
At this access level, only
- HMI access and
- reading diagnostic data
is possible without a password.
Without the password the following functions cannot be carried out:
- loading the blocks and hardware configuration into or from the CPU, writing test functions
- changing the operating state (RUN/STOP) (not for S7-300 / S7-400 / WinAC) firmware update (online).
|
|
Level 4 (complete protection) S7-1200 (v4) S7-1500
|
With a complete protection, the CPU forbids:
- read and write access to the hardware configuration and the blocks,
- HMI access,
- modifications in the server function for PUT/GET communication,
- read and write access in the area “Accessible devices” and in the project for devices that are switched online.
|
Considering Deactivation of PUT/GET communication (S7-1200(V4)/ S7-1500)
The CPU can be the server for a number of communication services. In this mode, other communication devices can access the CPU data without having been configured or programmed explicitly for the CPU. In the same way the local CPU does not have the possibility of controlling the communication to the clients. Whether this type of communication is admissible for the local CPU or not, is defined in the object properties of the CPU. In the default configuration, the option “Access via the PUT/GET communication…” is deactivated.
In this case, read and write access to the CPU data is only possible for those communication connections which require programming for the local CPU and for the communication partner (e.g. Access via BSEND / BRECV instructions, is possible even in the default configuration). Communications, for which the local CPU is only server (that means, that there is no configuration / programming of the communication to the communication partner), are not possible in the operation of the CPU.
This includes:
- PUT/GET, FETCH/WRITE or FTP access via communication modules
- PUT/GET access by other S7-CPUs
- HMI access via PUT/GET communication
Conclusion
The main goal of this blog is to focus on how PUT/GET is the really sensitive method of data retrieval. If this method of communication is disabled, serious consideration should be made to integrated applications generating all kinds of errors.
