Hacked traffic light systems – pure fiction?

Operational technology – or OT for short – is part of our everyday lives. It controls physical processes such as the pump system of a municipal water supply, room temperature control in the home or the control of a traffic light system. Usually, a programmable logic controller, called a PLC, is used for this purpose. It monitors processes and states and manages them in accordance with specifications.

The life cycles of such control devices are considerably longer than those of devices used in IT or home electronics. Depending on the area of application, they can be 15 years or more. Due to these long life cycles, the core programming of the devices has not changed over time. Or to be more precise: it must not change at all, because devices that were put into operation ten years ago and devices that are put into operation now must be able to be configured and programmed using the same software.

The IEC 61131 standard has become established as the standard for programming PLCs. The supported programming languages are:

The language used depends on several factors. In North America, programming is mostly done in Ladder Diagram, while in Europe, FBD is increasingly used in combination with structured text or SFC. Instruction List is hardly used any more. However, programming languages such as Python or Blockly are finding their way into newer PLC models.

In the standardised programming languages, PLC manufacturers and system integrators provide building blocks and libraries, for example to enable communication between devices or represent the display on a user interface.

No security by design

The five programming languages and the manufacturers’ supporting libraries have one thing in common: one will search in vain for security functions. In fairness, it should be mentioned that until about five years ago, there were virtually no security requirements for OT devices and their software. It was not until the ‘NotPetya’ wave of ransomware in 2017 that it became clear that the increasing interconnection of company IT and OT can lead to malware spilling into OT.

Since then, manufacturers have been making efforts to integrate security into their products. But here, too, the long life cycle of the devices is a disadvantage, as products that are currently no longer sold are generally not updated with security features. And there is generally resistance to changing systems that have already been put into operation, or certification reasons for not doing so.

Another challenge for integrating security into PLC programs is the creation of the PLC programs themselves. Only rarely is the PLC software created from scratch for a new project. As far as possible, program blocks that have already been tested and put into operation are reused.

Top 20 PLC programming practices

In order to nevertheless increase the cyber resilience of control devices, PLC programmers have teamed up and compiled the ‘Top 20 Secure PLC Coding Practices’ as part of a joint project. The project describes 20 programming practices for increasing cybersecurity around PLCs.

The aim of the project is to be able to implement the 20 practices with existing resources, the programming standard IEC 61131 and as little programming effort as possible. The practices were created by PLC programmers for PLC programmers and are publicly available at www.plc-security.com. Switch CERT has translated the description of the practices into German.

The list of practices is also interesting due to its cross-references to the OT / ICS security standard IEC 62443 and the ‘MITRE ATT&CK for ICS attack collection,’ a collection of potential cyber-attacks in the field of operational technology.

Device configuration without credentials

Here’s an example: one vulnerability (advisory number: CVE-2023–0053) is described as ‘allows the execution of commands without credentials’. This means that you can make changes to the device configuration without entering a username and password if you have network access to the device. This sounds bad, but it is a reality in the world of operating technology.

Practice number 13 helps to guard against such vulnerabilities: ‘Disable unneeded/unused communication ports and protocols.’ Looking at the example in practical terms, it is very likely that the communication ports on the device, in this case Telnet (TCP port 23) and FTP (TCP port 21), cannot be disabled because this would block the possibility of configuration. In other words, I would lock myself out as a user and would no longer be able to configure the device.

The next step is to block access to these ports in the network, which can be configured with a firewall, for example. If there is no firewall, it is still possible to monitor network traffic and trigger an alarm in the event of unauthorised access to these ports.

For experienced PLC programmers, some practices may seem simple. This was done deliberately to offer valuable help to inexperienced PLC programmers. Practice number 12, for example, the plausibility check of user input, reads as follows: ‘Ensure operators can only input what’s practical or physically feasible in the process. Set a timer for an operation to the duration it should physically take. Consider alerting when there are deviations. Also, alert when there is unexpected inactivity.’

Fancy a horror scenario?

Imagine criminals gaining access to a road traffic system’s network via phishing emails. On LinkedIn, you can quickly find out which people work with such systems. Once in the network, there is practically no protection of the control systems. The data is not encrypted. Does this strike you as fanciful? The following is a real, but anonymised, example from my work: not too long ago, I discovered the control system for a traffic light system in Fantasia on the internet. Graphical access to the plant was restricted, but access via the industrial protocol was open. I know this protocol, so I was able to click through until I came across the individual bits for the signal lights ‘red/amber/green’. I could have switched all the lights to green at the same time. I immediately reported the matter to the appropriate authorities. Together, we were able to correct it.

This example can easily be applied to other scenarios, where manipulated control systems can cause massive damage and consequently spread fear and terror. In contrast to IT, luckily every control system works differently in OT. This significantly increases the effort for hacker groups to attack such targets.

What's next for the joint project?

On the one hand, we want to raise awareness of the project. The author plans an example implementation of the practices with the ‘Codesys’ programming environment by the middle of this year.

On the other hand, we are trying to get OT device manufacturers interested in the project so that we can work with them to create ‘application notes’. In other words, an aid for programmers on how to implement the practices with the programming environment and the manufacturers’ libraries.