PLCs and RTUs Still Lack Security Features
At last week’s BlackHat press conference, we were able to participate in a press event specifically dealing with the number of recent security findings related to SCADA systems and PLCs/RTUs. We continued to send out the message that embedded devices such as PLCs and RTUs simply do not have the level of security commensurate with the level of risk represented by the functions that these devices serve in the SCADA system. Dillon showcased the research work that he did to send replay attacks back to several models of Siemens PLCs. He was able to use Wireshark to capture network traffic containing commands to turn outputs (lights) ON and OFF. He then took the captured packets, extract the protocol commands, then create Metasploit modules to send the exploit to the PLCs. It was an excellent use of replay attacks.
I then made the comment that these replay attack vulnerabilities are not unique to Siemens PLCs. Almost all PLC, RTU, and control system components that utilize routable TCP/IP based protocols are vulnerable to replay attacks. The issue goes much deeper than the fact that these devices do not have any timing capabilities to thwart replay attacks. Even after we initially discovered this over 8 years ago, these embedded devices continue to lack authentication, encryption, and almost all vendors that we are aware of allow any device on the same subnet to send command and control signals to PLCs that directly impacts real-world IO (inputs and outputs.)
Many of the control system vendors took their RS-232 serial protocols, which did not have authentication requirements built into the specifications, and simply encapsulated their old serial protocols in TCP/IP. In our training class, we break down ModbusTCP, and after you peel off the header information, the same old ModbusRTU structure still exists. PLCs, RTUs, Variable Speed Drives, MCC equipment, “smart” instruments, smart meters, and basically any control device with a routable IP protocol interface can not make a determination between the actual SCADA Master IO Servers that poll them for information or send them commands and another device on the same network. The equipment will accept a command from any IP-enabled device on its same subnet.
This means that either an attacker that has accessed the network remotely, or malware that has made its way into the control system network can also send commands to process and safety controllers and make the physical plant equipment do whatever the attacker or malware wants. It can easily open ALL valves in a plant, turn ON and then OFF all pumps in a plant very quickly, or cause pressure to ramp up to unsafe levels. An attacker or malware that has made it onto the SCADA network can do anything that an operator sitting in front of the HMI can do, including even issuing an ESD (emergency shut down) command.
I hope this message gets out to the industry, and to the control system vendors. We need to start designing and selling control systems that are truely secure out of the box, and also roll out solutions that can secure the exisitng legacy systems out in the field today.