Testing vulnerabilities in programmable logic controllers
Had you examined the controls handling automotive assembly lines before the mid 1970s you would have found cabinets full of relays, cam timers, drum sequencers and hard0wied controllers. All these controls had to be swapped out or modified to handle line retooling during a model-year change. To reduce the cost of such changeovers, General Motors worked with Bedford Associates to build the first Programmable Logic Controller (PLC) in 1968. It took a while for the PLC to replace hardwired logic, but it currently is used worldwide.
PLCs range from elementary hand-held bricks to arrays of large controllers in floor-to-ceiling steel enclosures with integral HMIs. PLCs are easy to power up, program and wire to remote sensors and actuators on the factory floor. The usual means of programming a PLC is via a ruggedized laptop PC. Logic is accessed in the form of on-screen ladder diagrams. Upon completion, the user’s computer is connected to the PLC via USB, Ethernet, RS 232, RS 485 or RS 422 with appropriate cabling.
One key parameter of every PLC is its scan time and a scan cycle. During one scan cycle, the PLC notes the status of the inputs (basically, it writes status info into memory locations), runs the PLC program, then updates the outputs (and updates memory locations recording current output status) according to what the PLC program dictates. The PLC then repeats this sequence, i.e. runs another scan, until commanded to stop. A single scan typically takes place in an amount of time often measured in milliseconds. The amount of time it takes for the PLC to make one scan cycle is called the scan time of the PLC.
PLCs are often still programmed with ladder logic programming languages that resemble the old ladder logic of hardwired relays and switches. One of the basic exercises in ladder-logic programming is to write a program that measures the scan cycle of a PLC. An example of such a program can be found on the sanfoundry.com site. Basically, it toggles an output every time the scan completes and counts the number of toggles in one second.
If this technique had been implemented with relays and contacts, the first rung of the ladder diagram would contain a normally closed contact wired in series with the coil of the same relay. When implemented on a PLC instead of with relays, the contact is a set memory location, and the coil is an associated memory address. The toggling bit (contact) serves as an input to an up-counter that increments every time the bit toggles. There is a one-second timer that stops the counter from counting at the one-second mark. A reset counter clears the accumulated scan count data to set things up for measuring the number of scan cycles in the next one-second interval.
The scan time of a PLC is a basic measure of its speed of response. Unfortunately, researchers have found that it’s possible to degrade PLC scan time using the same hacking techniques deployed against general-purpose computers. The problem seems to be particularly bad in PLCs that use the same CPU to handle both scanning and interfacing to a communication network, typically Ethernet. One hacking technique is to flood the Ethernet connection with action requests that demand CPU attention to such a degree that scanning cycles slow.
One example of these effects come from researchers at the Free University of Berlin and Augsburg University of Applied Sciences. They conducted three types of experiments in a testbed with 16 PLCs from six different vendors. They found that all but one PLC was prone to being influenced by network traffic. Specifically, most PLCs were affected by SYN packet floods. A SYN flood is a form of denial-of-service attack where an attacker rapidly initiates a connection to a computer without finalizing the connection. The packet that the attacker sends is the SYN packet, a part of the TCP three-way handshake used to establish a connection. The computer must spend resources waiting for half-opened connections. The process can consume enough resources to make the system unresponsive to legitimate traffic.
Researchers cycled the PLC at their maximum cycle rate, then applied the SYN flooding. This led to a slowing of cycle time in six PLCs. In three others, SYN attacks put the PLC into an out-of-operation state, defined as when the PLC cycle time rose by a factor of ten or more–in other words, the PLCs effectively stopped scanning. Researchers also varied the rate of the SYN packets. They found that some of the PLCs were not influenced at the maximum packet flooding rate but were indeed influenced when attacked at lower rates. Thus attacks carried out at data rates below the maximum can cause trouble for some PLCs, researchers say.
Researchers are careful to point out that their test wasn’t exhaustive for problems that can be caused by network attacks. Since SYN packets clearly influence PLCs, it can be expected that attacks mounted with higher-level protocols such as Hypertext Transfer Protocol (HTTP), Simple Network Management Protocol (SNMP), and ICS-specific protocols will be even more effective simply because they consume more CPU resources at higher levels of the network stack.
Talk of hacking PLCs may remind some readers of a notorious hacking incident involving the Stuxnet virus. As a quick review, Stuxnet affected gas centrifuges used by Iran to separate weapons-grade U-235 from U-238 gas isotopes. It is believed to have been introduced into Iran’s nuclear enrichment plant via flash drives unknowingly plugged into the network by contractors. Stuxnet caused PLCs to overspeed the VFDs controlling centrifuge motors, damaging them significantly and sabotaging the enrichment process.
The point to note about the Stuxnet caper is that it in no way resembled the kinds of network attacks simulated by the German researchers. Stuxnet had nothing to do with PLC scan times. Instead, the creators of Stuxnet had intimate knowledge about the kinds of centrifuges they were interested in defeating. Once introduced into a PLC, Stuxnet looked to see if the centrifuges of interest were attached. If they were absent, the virus simply ended itself. When it found a centrifuge, it silently began to do its dirty work only on the VFDs running the centrifuge motors.
A further point to note is that the level of expertise necessary to carry out network attacks simulated by the German researchers is such that juvenal delinquents with time on their hands could attempt them. On the other hand, a Stuxnet-type attack is something only conjured up by high-caliber professionals.
