On the hype around the critical Siemens S7-1200/S7-1500 vulnerability CVE-2022-38465

Around two months ago, the Team82 research group at Claroty disclosed a critical vulnerability in Siemens current S7-1200/S7-1500 series of PLCs. This is the next issue in a series of recent disclosures ^{1 2 3 4} on the security of these ubiquitous logic controllers.

What’s different this time is the whopping CVSS severity score of 9.3 (of a possible 10). The identifier CVE-2022-38465 was assigned to this vulnerability and Siemens published the related security advisory SSA-568427 and security bulletin SSB-898115. Even Germany’s national cybersecurity organization BSI got involved, raised its alarm level to yellow, and published its own advisory 2022-266796-1112.

Since then, the apparent urgency of this problem has only been amplified by various media outlets reporting about it ^{5 6 7 8 9}.
A recent thread on SPS-Forum confirms that customers and PLC programmers are rightfully unsure what to do. Likewise, the infosec community may not understand what is actually preventing customers from just applying the security update.

As one of the early members of ENLYZE, I successfully reverse-engineered the communication protocol of the Siemens S7-1200 and S7-1500 PLC families in 2019. The information has been used to develop a client for capturing process variables from these PLCs and feed them into the ENLYZE data platform. Over the past 4 years, we have visited a lot of shopfloors and successfully integrated a multitude of S7-based production machines at various customers.
Thus, we can provide a unique perspective on this matter, with our insights into the modern S7 protocol on the one side, and our experience with actual Siemens PLC installations at customers on the other side.

Background

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

The only application I managed to connect to the PLC was the official TIA Portal software from Siemens. This went surprisingly well: I only needed to plug an Ethernet cable into the unused port of the S7-1500F, enter the IP address displayed on the PLC, and I had full access. No password prompt or any other kind of authorization was required.

I could have done a few bad things with that access, but I only wanted to read process variables and that worked very well. The consequence was clear: To read data from the welding machine, we had to forget about all legacy S7 protocol implementations and do it exactly like TIA Portal. And in the absence of any freely available implementation of TIA Portal, I had to reverse-engineer the program and analyze the protocol myself.

Dissecting TIA Portal for profit

What do you do when you want to reverse-engineer a protocol transmitted over Ethernet? You fire up Wireshark and monitor the communication, in this case between TIA Portal and the S7.

It quickly turned out that Siemens drastically increased the complexity of the protocol compared to an old S7. And this came as no big surprise: It was clear that Siemens had to do something after the Stuxnet computer worm in 2010, which ruined Iranian nuclear centrifuges and set back their nuclear program – partly due to non-existent authentication in the used Siemens S7-400 PLCs.

While Siemens could redesign the communication protocol, they couldn’t just change the mentality on the shopfloor. Back then, industrial customers simply had no processes for managing individual PLC passwords per machine, and they hardly have now. Physical security is all that mattered for a long time.

As a consequence, Siemens was only able to add more and more complexity to the protocol, but not require their customers to use passwords. Looking into the protocol, I discovered a new 6-way handshake with proprietary challenge-response authentication, a custom signature scheme to validate message integrity, and a lot of additional obfuscation on top. Basically a prime example of the “roll your own crypto” and “security by obscurity” anti-patterns. Frankly, all of this helps to keep out the average attacker from messing around with your PLC. However, if TIA Portal is still able to connect to any such PLC without a password, the entire security system is ultimately in vain. There had to be a golden master key somewhere. And after 6 weeks of meticulous reverse-engineering, I figured out all the details and had a working PLC client.

Why am I telling you all this?
Well, if it takes a single person like me just 6 weeks in 2019 to break the security system of the latest Siemens PLCs, imagine what a dedicated team has been able to do over all these years. The door has been wide open all the time.
Consequently, a Siemens S7 should have never been part of a company network. A separation of company and shopfloor networks is mandatory here, either physical or with a properly secured firewall, managed switch, or router. Get that right before everything else!

The reality of password protection

As stated in my introduction, this is not the first vulnerability in the Siemens S7-1200 and S7-1500 series of PLCs. Previous security advisories like SSA-232418 often recommended enabling password protection for all S7 communication channels. This could have indeed been an effective way to keep the bad guys out, provided that the passwords were individual, long, random, and managed safely.

However, 90% of the Siemens PLCs we encounter in our daily business are not protected by a PLC password. I am not aware that the recommendations from Siemens security advisories made a noticeable difference here. Even more, there are no incentives for enabling password protection after a machine is already running:

• Machine manufacturers only act when asked by their customers, and when a customer is ready to pay for their service. They are not contracted to deliver periodic security updates. As a result, it’s natural for them to not change a running system – rather than proactively fixing an issue their customers didn’t even know about.

• Customers are in an even less advantageous position. Before everything else, they need to know about all places where modern S7 PLCs are used, what firmware and protection levels are set up, and whether any security updates are required. Afterwards, production needs to be stopped (at a loss), the TIA Portal project needs to be modified, and changes must be deployed to all affected devices (PLCs, but also HMIs, periphery, etc.). But often enough, customers already lack the required TIA Portal project file – or they have it, but any modification would violate the warranty.
  As a result, customers can only contact the machine manufacturer to set up password protection, adding significant costs on top of the costs of a production downtime.

Add this to the fact that insurance providers are increasingly offering policies to cover cybersecurity incidents and you understand why it often makes economic sense to do nothing.

By the way, the remaining 10% of PLCs that enabled password protection use a single short password for all machines of the same manufacturer. Don’t expect this little barrier to effectively increase the cybersecurity of your machine.

The latest vulnerability and its fix

If the previous section made you think about introducing passwords for your S7 devices and be done with it, I unfortunately have bad news for you. What’s new about the latest vulnerability (known as CVE-2022-38465 / SSA-568427 / SSB-898115) is the total failure of any existing protections. The Team82 research group at Claroty has not only extracted the private key of an S7-1500, but also discovered that it can be used to retrieve the password of any protected Siemens PLC – justifying the vulnerability’s outstanding severity score of 9.3. The door is wider open than ever before.

Therefore, it’s no longer sufficient to just set a password for your S7. Such a total breakdown of the existing protections can only be fixed through an entirely new security system. And this is what Siemens introduced with TIA Portal V17 and the accompanying PLC firmwares.

The new firmwares secure their communication using TLS 1.3 and individual certificates for each participant. In contrast to 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 as the primary means to secure communication over the web.
It remains to be verified what TLS implementation Siemens uses for its PLCs, what ciphers are supported, and how it’s actually used. But choosing an open standard over their own cryptosystem is already a big step in the right direction.

Sounds cool, huh? Now how do we deploy that fix to the millions of affected devices out there?
The sad truth is: This simply isn’t going to happen.

Unlike monthly updates for computer operating systems, there aren’t comparable established processes for rolling out security updates to PLCs. Just like setting a PLC password, applying the fix is a tedious manual process that requires a production downtime and a joint effort from both the machine manufacturer and the customer. In particular, to move a single machine to TLS-secured communication you need to:

• upgrade your engineering workstations to TIA Portal V17 (which by the way requires a new license),
• upgrade the firmwares of all PLCs, software versions of HMIs, plus other devices that communicate with the S7,
• upgrade all devices in the TIA project file,
• disable legacy communication,
• set up TLS certificates for each device, and finally
• deploy the modified project to all affected devices.

The incentives to act have already been low for just setting a password. Sadly, they aren’t any better for this critical vulnerability with an even more complex fix. This is why I don’t expect a massive roll-out of this update any time soon.

What effectively helps again is the separation of company and shopfloor networks. As I already stated above, either separate them physically or get yourself a properly secured firewall, managed switch, or router. This fix is possible without disrupting the ongoing production. It neither requires assistance from Siemens or the machine manufacturer, and guards you even from future unknown attacks on your S7 PLC.
Of course, firewalls, managed switches, and routers aren’t immune from security issues either. But in contrast to PLCs, these devices are more widespread, constantly tested for vulnerabilities, and have working processes for receiving security updates.

Outlook

We will only have these problems again and again if installing PLC security updates continues to be that difficult and the incentives to update remain low. While the move to standards-based TLS 1.3 communication shows that PLC security is permanently improving, this shouldn’t be considered the last update you ever need. The next vulnerability is only a matter of time.

This intricate situation can’t be fixed by a single company. It needs a joint effort by Siemens, machine manufacturers, and their customers. So see the following as a wish list and an open call to all participants in the industry:

• Customers need to request regular security updates from their machine manufacturers. This must become part of the requirement document when ordering a new machine.
  I’m realistic enough to understand that such updates can’t be installed anytime on production machines. But installing software updates should at least become part of the maintenance during planned machine downtimes.

• Machine manufacturers need to realize that they are no longer just shipping machines but interconnected computing devices. Such devices need regular security updates. Every machine manufacturer must offer a streamlined process to apply these updates.

• Finally, Siemens is the only participant who can make regular security updates a reality. Siemens must establish feasible processes for the end-user of a machine to quickly deploy security updates to all affected components. We have already seen that updates are simply not deployed if the process is too complex and thereby costly.
  Additionally, fixes for critical vulnerabilities should be backported to old TIA Portal releases. As of now, they only reach machine manufacturers who constantly pay for and upgrade all their engineering workstations to the latest TIA Portal feature release. Everyone else, who still uses TIA Portal earlier than V17, now ships PLCs with a known backdoor.

Just a few weeks ago, the EU has made 5 years of free software updates mandatory for smartphones. These updates reliably reach billions of devices not long after their release. There is no reason why our PLC-based production industry and the entire critical infrastructure should be worse off here.

At this moment, nobody can in good conscience put a PLC in a public network and rely on its own security features.

Acknowledgements

Four years into running our own ENLYZE S7 communication client and thousands of captured process variables later is a good time for some acknowledgements. This time, I’d first like to thank Team82 at Claroty for their continuous research into PLC security, their latest disclosure, and for successfully convincing Siemens of moving their S7 communication to TLS 1.3.

We are all building upon the amazing work of numerous people. The ENLYZE S7 communication client hasn’t been the first implementation of the modern S7 protocol and it certainly won’t be the last. I’d like to especially thank the following people, whose work has been immensely helpful during my research and development of our S7 client:

• Thomas Wiens for his invaluable 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 initial 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 disclosure of even more details of the S7 communication

About ENLYZE

The ENLYZE GmbH headquartered in Cologne, Germany is a vertically integrated Industry 4.0 Smart Factory solution provider. With its cloud platform tailored to the continuous manufacturing industry, it allows mid-sized companies to capture machine data from heterogeneous shopfloors, perform product-based analysis, and make results available to further systems. This enables ENLYZE customers to optimize production processes, digitize important process knowledge, and thereby significantly raise their OEE. With its full-service approach and in-house development of hardware and software, the ENLYZE platform can often be integrated 20x faster and at much lower cost than comparable platforms. Instead of requiring costly machine upgrades, the ENLYZE platform is securely connected to the existing data communication interfaces of your machine. For more information about ENLYZE, visit www.enlyze.com or write an e-mail to hello@enlyze.com.