Background

When I started at ENLYZE at the turn of the year 2018/2019, we were tasked with reading process data from a relatively new welding machine. The machine was based on a modern Siemens PLC from the fail-safe S7-1500F series. As a newcomer to automation, I looked for existing implementations of the S7 protocol, found a few, and tried them out. None of them worked.

The only program that could connect to the PLC was the official TIA Portal software from Siemens. This worked surprisingly well: I just had to plug an Ethernet cable into one of the unused ports of the S7-1500F, type in the IP address displayed on the PLC, and I had full access. No password or any other form of authorization was required.

I could have done a few things with this access, but I only wanted to read process variables, and this worked very well. The consequence was clear: To read data from the welding machine, we had to forget all traditional S7 protocol implementations and approach it exactly like TIA Portal. And without a freely available implementation of TIA Portal, I had to reverse-engineer the program and analyze the protocol on my own.

The Breakdown of TIA Portal

What does one do when wanting to reverse-engineer a protocol that is transmitted over Ethernet? You start Wireshark and monitor the communication, in this case, between TIA Portal and the S7.

It quickly became apparent that Siemens had significantly increased the complexity of the protocol compared to an old S7. This was not a big surprise: It was clear that Siemens had to take action after the Stuxnet computer worm destroyed Iranian nuclear centrifuges and hindered their atomic program in 2010 – partly due to the non-existent authentication in the Siemens S7-400 controls used.

While Siemens was able to redevelop the communication protocol, they could not change the mentality in a factory overnight. At that time, industrial customers simply had no processes to manage individual PLC passwords per machine – and little has changed to this day. Most of the time, it was solely about physical security.

As a consequence, Siemens was able to build more and more complexity into the protocol, but could not force any customer to use passwords. I found, among other things, a 6-way handshake with proprietary challenge-response authentication, a self-developed signature method for validating messages, and a lot of obfuscation on top. Practically a prime example of “rolling out one’s own cryptography” and “security through obscurity” – both principles that should be strongly discouraged. Admittedly, all this helps to keep the average attacker from messing with your PLC. However, if TIA Portal can still connect to each PLC without a password, the entire security system becomes ultimately obsolete. Because there must be some sort of master key somewhere. And after 6 weeks of meticulous reverse-engineering work, I finally found all the necessary details and had a functioning PLC client.

Why am I telling you all this?

Well, if a single person like me took only 6 weeks in 2019 to crack the security system of the latest Siemens PLC series, just imagine what a team of reverse engineers could accomplish over the years. The door was practically wide open all the time.

A Siemens S7 should therefore never have been part of a corporate network. A separation of corporate and factory hall networks is mandatory, either physically or through a reasonably secured firewall, managed switch, or router. Take care of this before trying anything else!

Disassembling the modern S7 protocol -- a photo from the early days of the ENLYZE workshop

The Reality of Password Protection

As I mentioned in my introduction, this is not the first security vulnerability in the Siemens S7-1200 and S7-1500 PLC series. Earlier security advisories, such as SSA-232418, often recommended enabling password protection for all S7 communication channels. This could indeed have been an effective way to keep bad actors at bay, provided the passwords were individual, long, random, and securely managed.

In reality, however, 90% of the Siemens controls we encounter in our day-to-day operations are not protected by a PLC password. I am not aware that the recommendations from Siemens Security Advisories have made any significant difference here. Moreover, there are no incentives to enable password protection once a machine is already running:

• Machine manufacturers only become active upon customer request, and only if a customer is willing to pay. They are not obliged to provide regular security updates. Therefore, it is understandable that they do not change anything in a running system – rather than proactively solving a problem that the customers were not even aware of.

• Customers are in an even more disadvantaged position. First, they must know where modern S7 controls are used, what firmware versions and security levels they were installed with, and whether any security updates are needed. Then production must be stopped (with loss), the TIA Portal project modified, and the changes transferred to all affected devices (PLCs, but also HMIs, peripherals, etc.). However, this often fails because customers lack the necessary TIA Portal project file – or they have it, but the warranty expires with each modification.
  As a result, customers again rely on the machine manufacturer to activate password protection, which incurs significant costs in addition to the cost of production downtime.

When you also consider that insurers are increasingly including cyber-attacks in their insurance policies, you can understand why it often makes economic sense to simply do nothing.

By the way, the remaining 10% of controls with password protection use a simple short password for all machines of the same manufacturer. Do not expect that this small hurdle will actually improve your machine's cybersecurity.

The Latest Security Vulnerability and Its Solution

If you are now thinking about implementing passwords for your S7 devices and considering the matter settled, I unfortunately have bad news for you. The new aspect of the current security vulnerability (known as CVE-2022-38465 / SSA-568427 / SSB-898115) is the total failure of all existing protection systems. The Team82 research group from Claroty has not only extracted the private key of an S7-1500 but has also discovered that it can read the password of any protected Siemens control – which justifies the significant severity rating of 9.3. The door is wider open than ever before.

Therefore, it is no longer sufficient to simply assign a password to the S7. Such a total failure of existing security systems can only be remedied by a completely new security system. And Siemens has introduced this with TIA Portal V17 and its associated PLC firmwares.

The new firmwares protect their communication using TLS 1.3 and individual certificates for each participant. Unlike Siemens' previous security system, TLS 1.3 has been standardized in an open process. The TLS family has already proven itself over the past decades to secure web communication.

It remains to be seen which TLS implementation Siemens has chosen for its PLC models, what encryption modes are supported, and how TLS is specifically used. But choosing an open standard over a self-developed cryptosystem is already a significant step in the right direction.

Sounds good, right? How do we now get the update onto the millions of affected devices out there?

The sad truth is: This simply will not happen.

Unlike monthly updates for computer operating systems, there are no comparably established processes for rolling out security updates on PLC devices. Just like setting an PLC password, installing the update is a tedious manual process that requires a shutdown of production and a joint effort from the machine manufacturer and customer. To specifically transition a single machine to TLS-secured communication, you must:

• Update your engineering workstations to TIA Portal V17 (which incidentally requires a new license),

• Update the firmwares of all PLCs, software versions of all HMIs, and other devices that communicate with the S7,

• Update all devices in the TIA project file,

• Switch off legacy communication,

• Set up TLS certificates for each device, and finally

• Load the modified project onto all affected devices.

The incentives to act were already low when it was just about setting a password. Unfortunately, they are not any higher for this critical security vulnerability, which requires a significantly more complex solution. For these reasons, I do not expect a widespread rollout of this update in the near future.

What actually helps, however, is once again the separation of corporate and factory hall networks. As already mentioned, these should either be physically or through a reasonably secured firewall, managed switch, or router isolated from one another. This solution can be implemented without interrupting ongoing production. It can be carried out completely without support from Siemens or the machine manufacturer and also protects against future unknown attacks on your S7 PLC.

Of course, firewalls, managed switches, and routers are not immune to security issues either. However, compared to PLCs, these devices are more widely available, constantly tested for vulnerabilities, and have functioning processes for installing security updates.

Outlook

We will continue to have these problems over and over again if installing PLC security updates remains this complicated and the incentives for updating remain so low. Transitioning to standardized TLS 1.3 communication means a lasting improvement in PLC security, but this will by no means be the last security update you will ever need. The next security vulnerability is just a matter of time.

This tricky situation cannot be solved by a single company. It requires a joint effort from Siemens, machine manufacturers, and their customers. Therefore, here is a wish list and an open call to all stakeholders in the industry:

• Customers must demand regular security updates from their machine manufacturers. This must become part of the specifications when ordering a new machine.
  I am realistic enough to understand that such updates cannot be installed at any time on production systems. But installing software updates should at least become part of maintenance during planned machine downtimes.

• Machine manufacturers must realize that they are no longer just delivering machines but connected computers. Such devices require regular security updates. Every machine manufacturer must offer a streamlined process for implementing these updates.

• Ultimately, Siemens is the only stakeholder that can make regular security updates possible. Siemens must develop practical processes for the end customer of a machine so that they can quickly apply security updates to all affected components. We have already seen that updates simply are not installed when the process is too complicated and thus costly.
  Furthermore, fixes for critical security vulnerabilities should also be backported to older TIA Portal versions. Currently, these only reach machine manufacturers who continuously pay for new TIA Portal functionality updates and then update all their engineering workstations. Anyone else still using TIA Portal older than V17 is now delivering controls with a known backdoor.

A few weeks ago, the EU mandated 5 years of free software updates for smartphones. These updates reliably reach billions of devices shortly after their release. There is no reason why our PLC-based production landscape and all critical infrastructure should be treated worse in this regard.

Currently, no one can confidently connect a PLC to a public network and rely on its own security functions.

Acknowledgments

Four years, in which we successfully used our own ENLYZE S7 communication client, and thousands of recorded process variables later is a good time for some acknowledgments. This time, I would like to thank the Team82 from Claroty first, for their continuous research on PLC security, their latest publication, and for successfully convincing Siemens to use TLS 1.3 in S7 communication.

We all build on the great work of countless people. The ENLYZE S7 communication client was not the first implementation of the modern S7 protocol, nor will it certainly be the last. I would therefore like to specifically thank the following individuals, whose work was immensely helpful during my research and development of our S7 client:

• Thomas Wiens for his immensely valuable S7comm Wireshark dissector plugin

• Maik Brüggemann for his analysis of the unencrypted S7-1200 V3 communication and TIA Portal V11

• Cheng Lei, Li Donghong, and Ma Lian for their fundamental analysis of the encrypted S7-1200 V4 communication and TIA Portal V13

• Eli Biham, Sara Bitan, Aviad Carmel, Alon Dankner, Uriel Malin, and Avishai Wool for their publication of much more detail on S7 communication

About ENLYZE

The ENLYZE GmbH based in Cologne positions itself as a vertically integrated Industry 4.0 solution provider. With its cloud platform tailored to continuous manufacturing, it enables medium-sized companies to capture machine data from heterogeneous equipment parks, analyze it based on products, and make it available to other systems. In this way, ENLYZE customers can optimize production processes, digitize vital production knowledge, and thus significantly increase their OEE. Thanks to the full-service approach and in-house development of hardware and software, the ENLYZE platform can often be integrated 20 times faster and at significantly lower costs than comparable platforms. Instead of costly machine retrofits, the ENLYZE platform connects securely to your machine's existing data communication interfaces. For more information, visit our website ENLYZE or write us an email.