Nope, S7ill Not Secure: Stealing Private Keys From S7 PLCs

Nope, S7ill Not Secure: Stealing Private Keys From S7 PLCs

Speakers: Alon Dankner, Security Researcher, Technion and No Code Security; Nadav Adir, Student, Technion University

Conference: Black Hat USA

YouTube: https://www.youtube.com/watch?v=9AO24tqksRw

Overview

This talk, presented by Alon Dankner and Nadav Adir from the Technion, delves into the continued security vulnerabilities of Siemens S7 Programmable Logic Controllers (PLCs), specifically the S7 1500 series, despite Siemens' adoption of TLS 1.3 for secure communication. The research, which marks the team's fourth appearance at Black Hat addressing Siemens PLC security, reveals a critical flaw: the ability to retrieve the private key directly from an S7 1500 PLC over the network. This capability stems from a specific protocol feature provided by Siemens, inadvertently undermining the very cryptographic protections it sought to implement.

The implications of this private key theft are profound for industrial control systems (ICS) and critical infrastructure. PLCs form the bedrock of cyber-physical systems, dictating the behavior of physical processes. Compromising their private keys allows attackers to establish stealthy Man-in-the-Middle (MITM) attacks, enabling them to decrypt and manipulate legitimate communications between engineering stations, Human-Machine Interfaces (HMIs), and the PLC itself. This research highlights that even with modern cryptographic standards like TLS 1.3, an insecure implementation or the presence of unintended features can render the entire system vulnerable, echoing the lessons learned from the Stuxnet worm nearly 15 years ago.

The presentation aims to comprehensively reconstruct the potential impact of such an attack, demonstrating that the move to TLS 1.3, while a step forward, has not fully secured the S7 protocol. The researchers evaluated whether the new protocol version truly prevents previous attack vectors or if it introduces new ones, concluding that a critical vulnerability persists. Their work serves as a stark reminder for ICS operators and vendors about the complexities of securing highly interconnected operational technology (OT) environments, especially as these systems increasingly integrate with external networks and cloud services.

Background

▶ Watch: Stuxnet legacy, TLS 1.3, private key retrieval from S7 PLCs. (0:00)

The journey to securing Siemens S7 PLCs has been a protracted one, marked by significant milestones and persistent challenges. Prior to 2010, the Siemens S7 protocol, which facilitates communication between engineering stations (like Siemens Step 7) and PLCs, operated largely unencrypted and without robust cryptographic protection. This era of lax security was abruptly brought to an end with the discovery of the Stuxnet worm in 2010. Stuxnet, widely regarded as the most infamous cyber-physical system attack, specifically targeted Siemens PLCs, exploiting zero-day vulnerabilities to manipulate industrial processes, particularly those involved in uranium enrichment. Its discovery sent shockwaves through the industrial control system (ICS) community, highlighting the severe consequences of cyberattacks on critical infrastructure.

In response to Stuxnet and the heightened awareness of ICS vulnerabilities, Siemens began integrating proprietary cryptographic protection into their S7 protocol. While an improvement, this proprietary solution was not without its weaknesses. In 2019, the same research team from the Technion, led by Alon Dankner, published a seminal work at Black Hat USA titled "Rogue 7". This research exposed critical flaws in Siemens' proprietary security measures, specifically exploiting a lack of client authentication and the use of hardcoded group keys shared across multiple PLCs. The "Rogue 7" attack demonstrated how an adversary could impersonate a legitimate engineering station – a rogue client – and gain unauthorized control over PLCs, effectively undermining the integrity of the industrial process.

The "Rogue 7" findings were instrumental in pushing Siemens towards adopting a more standardized and robust cryptographic solution: TLS 1.3. The transition to TLS 1.3 was intended to address the vulnerabilities exposed by previous research, providing strong encryption, authenticated communication, and integrity protection for the S7 protocol. TLS 1.3 is the latest version of the Transport Layer Security protocol, offering enhanced security features like zero round-trip time (0-RTT) resumption and stronger cryptographic algorithms, designed to mitigate many common attack vectors.

However, as PLCs continue to evolve, they are increasingly connected to external networks to leverage benefits such as cloud-based machine learning models and digital twins. This increased connectivity, while offering operational advantages, simultaneously expands the attack surface, creating new challenges for traditional security models and architectures. The current research, "Nope, S7ill Not Secure," serves as a critical follow-up to the "Rogue 7" work, aiming to assess whether the adoption of TLS 1.3 truly enhances the security posture of Siemens S7 PLCs or if new vulnerabilities have emerged in its implementation or interaction with existing protocol features. The core question is whether the latest security measures adequately protect these vital components that bridge the cyber and physical worlds, dictating the behavior of industrial processes.

Key Findings

▶ Watch: Introducing Avengers analogy for system roles (Nick Fury, Iron Man). (2:35)

The central and most critical finding of this research is the discovery of a method to retrieve the private key from a Siemens S7 1500 PLC over the network. This unprecedented capability fundamentally undermines the security assurances provided by TLS 1.3, effectively rendering the protocol's encryption and authentication mechanisms vulnerable to compromise. The researchers explicitly state that this attack leverages a "protocol feature provided by Siemens," indicating that the vulnerability is not a flaw in the TLS 1.3 standard itself, but rather in its specific implementation or integration within the Siemens S7 protocol stack.

The ability to extract the PLC's private key is the lynchpin for a series of subsequent attacks, which the researchers metaphorically refer to as "six Infinity Stones." While the talk outline details four main attack steps, these collectively demonstrate a comprehensive compromise:

1. Attack against Key Initialization: This step likely targets the process by which the PLC generates, stores, or receives its cryptographic keys. A weakness here could allow an attacker to either gain access to the key before it's securely established or manipulate the key generation process.
2. Retrieval of the PLC Private Key over the Network: This is the core exploit. By leveraging the identified Siemens protocol feature, an attacker can remotely extract the PLC's unique private key. This key is essential for establishing secure TLS connections and authenticating the PLC's identity.
3. Stealth Man-in-the-Middle (MITM) Attack: With the PLC's private key in hand, an attacker can decrypt legitimate communications between the PLC and authorized clients (such as the TIA Portal engineering station or WinCC HMI). More critically, the attacker can also impersonate the PLC to these clients, as well as impersonate the clients to the PLC. This allows for silent interception, modification, and injection of control commands and data, making the attacker virtually undetectable within the secure channel.

The research's overarching conclusion is that despite Siemens' proactive step to integrate TLS 1.3, the latest version of the S7 protocol is still not secure against sophisticated attacks. The findings demonstrate that the new protocol version not only fails to prevent all previous attack types but also introduces, or at least leaves open, pathways for new and highly impactful vulnerabilities. The ability to perform a stealth MITM attack by stealing the private key represents a complete compromise of the communication channel, allowing an adversary to manipulate physical processes with impunity, reminiscent of the Stuxnet threat, but now within a supposedly "secure" TLS 1.3 environment. This highlights the critical importance of secure-by-design principles and thorough security evaluations of industrial protocols, even when leveraging industry-standard cryptographic primitives.

Technical Deep Dive

▶ Watch: S7 protocol security evolution: from unencrypted to TLS 1.3. (4:00)

The technical core of the "Nope, S7ill Not Secure" research revolves around the interplay between the Siemens S7 protocol, its adoption of TLS 1.3, and a critical vulnerability that allows for the extraction of a PLC's private key. To understand the severity of this finding, it's essential to first grasp the roles of these components.

The Siemens S7 protocol is the proprietary communication standard used by Siemens PLCs for interaction with supervisory software. This includes the TIA Portal, which bundles the WinCC HMI (Human-Machine Interface) for operator monitoring and Step 7 for engineering and programming tasks. The PLC, acting as a server, responds to requests from client software, such as loading new control programs or reading process variables. Historically, the S7 protocol began without any encryption, leading to vulnerabilities that Stuxnet exploited. Subsequent efforts introduced proprietary cryptographic protections, which were later found to be inadequate by the "Rogue 7" research, pushing Siemens to adopt standard TLS 1.3.

TLS 1.3 (Transport Layer Security version 1.3) is designed to provide secure communication over a computer network. It aims to establish a secure channel between a client (e.g., TIA Portal) and a server (the S7 1500 PLC) through a handshake process involving:

1. Key Exchange: Using algorithms like Diffie-Hellman Ephemeral (DHE) or Elliptic Curve Diffie-Hellman Ephemeral (ECDHE), the client and server agree on a shared secret key without ever transmitting it directly. This ensures perfect forward secrecy (PFS), meaning even if the server's long-term private key is compromised later, past session keys remain secure.
2. Authentication: The server authenticates its identity to the client using its digital certificate, which contains its public key and is signed by a trusted Certificate Authority (CA). The client verifies this certificate. In many TLS implementations, client authentication is optional but crucial for mutual trust.
3. Encryption and Integrity: Once the secure channel is established, all subsequent application data (S7 protocol commands and responses) are encrypted using symmetric ciphers (e.g., AES-GCM) and protected with Message Authentication Codes (MACs) to ensure confidentiality and integrity.

The researchers specifically targeted the Siemens S7 1500 PLC, a modern and widely deployed industrial controller. Their core discovery is that a "protocol feature provided by Siemens" allows an attacker to remotely retrieve the PLC's private key. While the transcript does not elaborate on the specific nature of this "protocol feature," its existence implies a fundamental flaw in the PLC's key management, key storage, or the S7 protocol's interaction with the TLS layer.

Possible scenarios for such a "protocol feature" could include:

• Debug or Maintenance Interfaces: Many embedded systems, including PLCs, include diagnostic or maintenance interfaces that might allow privileged access to internal components, including cryptographic material. If these interfaces are accessible over the network and lack sufficient authentication or authorization controls, they could be exploited.
• Key Export Functionality: The PLC might have a legitimate, intended function to export its private key for backup, migration, or provisioning purposes. If this function is not adequately secured (e.g., weak authentication, lack of strong cryptographic protection for the exported key, or an oversight allowing remote activation), it becomes an attack vector.
• Vulnerable Key Generation or Storage: Flaws in the PLC's firmware could lead to private keys being stored in an unprotected memory region, or generated with insufficient entropy, making them recoverable. The "attack against key initialization" mentioned in the talk outline points towards weaknesses in the lifecycle of key management.

The successful retrieval of the PLC's private key has devastating consequences for the security of TLS 1.3. While TLS 1.3 uses ephemeral keys for session encryption (PFS), the server's long-term private key is still critical for authentication. If an attacker possesses the PLC's private key, they can:

1. Impersonate the PLC: The attacker can generate a valid TLS certificate for the PLC, signed by the legitimate CA (if they also have the CA key, or if the PLC's private key is used to sign its own certificate). More simply, they can use the actual private key to perform the server's side of the TLS handshake, effectively convincing clients (TIA Portal, WinCC) that they are communicating with the genuine PLC.
2. Establish a Stealth Man-in-the-Middle (MITM) attack: By impersonating both the PLC to the client and the client to the PLC, the attacker can silently intercept, decrypt, read, modify, and re-encrypt all communications. This allows them to inject malicious commands, alter process variables, or exfiltrate sensitive operational data without detection. Even with PFS, the ability to authenticate as the PLC allows the MITM to establish new, legitimate-looking TLS sessions with both ends, effectively bypassing the protection for future communications.

The fact that this vulnerability exists in the latest S7 1500 PLCs, which are supposed to be secured by TLS 1.3, underscores a critical lesson: the strength of cryptographic protocols is only as good as their implementation and the overall security posture of the system they protect. A single, poorly secured "protocol feature" can negate the benefits of state-of-the-art encryption.

Demo / Proof of Concept

▶ Watch: Research goal: TLS 1.3 security and six "Infinity Stone" attacks. (4:54)

While the transcript does not provide a step-by-step walkthrough of the demonstration, it clearly indicates that a Proof of Concept (PoC) was developed and presented. The core of this demonstration would have focused on two critical stages: first, the successful retrieval of the private key from a Siemens S7 1500 PLC, and second, leveraging this key to execute a stealth Man-in-the-Middle (MITM) attack.

The researchers stated that their attack "relies on our ability to retrieve the private key from an S7 1500 PLC using a protocol feature provided by Siemens." This strongly suggests a practical demonstration where a compromised or rogue client, acting as the attacker (Thanos in their Avengers analogy), would initiate a specific sequence of commands or interactions with the target PLC. This interaction would exploit the identified "protocol feature" to exfiltrate the PLC's private key over the network. The success of this stage would likely be demonstrated by displaying the extracted key material.

Following the key retrieval, the PoC would then proceed to showcase the stealth MITM attack. With the PLC's private key, the attacker can establish a position between the legitimate TIA Portal (engineering station) or WinCC (HMI) client and the S7 1500 PLC. The attacker would intercept the TLS handshake from the client, use the stolen private key to impersonate the PLC, and then initiate a separate, legitimate-looking TLS handshake with the actual PLC, impersonating the client. All subsequent communications would flow through the attacker, who could then decrypt, inspect, modify, and re-encrypt the S7 protocol messages in real-time. The demonstration would likely show the attacker altering PLC variables, changing control logic, or manipulating operational data, all while the legitimate client and PLC believe they are communicating securely and directly. This would visually underscore the "stealth" nature of the attack, as neither the operator (Captain America) nor the engineer (Iron Man) would detect the compromise through standard monitoring.

Defensive Implications

▶ Watch: Detailed outline of the attack path, including private key retrieval. (5:40)

The findings presented in "Nope, S7ill Not Secure" carry significant defensive implications for organizations operating Siemens S7 PLCs, particularly the S7 1500 series, and more broadly for anyone managing industrial control systems. The ability to steal private keys and launch stealthy Man-in-the-Middle (MITM) attacks fundamentally undermines the trust in secure communication channels and demands a multi-layered defensive strategy.

1. Patching and Firmware Updates: The most immediate action is to apply any available security patches or firmware updates released by Siemens that address this specific vulnerability (if publicly disclosed). Organizations must maintain an aggressive patching cadence for all OT devices, prioritizing critical vulnerabilities that affect core security primitives like key management.
2. Network Segmentation and Access Control: While TLS 1.3 aims to secure communication, network segmentation remains a critical defense. PLCs and other OT devices should be isolated from enterprise IT networks and the internet as much as possible. Strict firewall rules should limit communication to only necessary ports and protocols, and only from authorized source IP addresses. Restricting network access to the "protocol feature" used for key retrieval is paramount.
3. Secure Key Management Practices: The vulnerability highlights the importance of robust key management throughout the lifecycle of cryptographic keys on PLCs. This includes:

• Secure Key Generation: Ensuring keys are generated with sufficient entropy and within a trusted execution environment.
• Secure Storage: Protecting private keys in hardware security modules (HSMs) or other tamper-resistant secure elements, rather than in accessible memory.
• Controlled Export/Import: If key export functionality exists, it must be protected by strong multi-factor authentication, physical presence verification, and encrypted transfers. Ideally, such features should be disabled in production environments.
• Regular Key Rotation: Implementing a policy for regular rotation of PLC private keys to limit the impact of a potential compromise.

1. Anomaly Detection and Behavioral Monitoring: Since MITM attacks can be stealthy, relying solely on cryptographic checks is insufficient. Implementing deep packet inspection and behavioral analytics within the OT network can help detect unusual communication patterns, unexpected command sequences, or deviations in process variables that might indicate a compromise, even if the communication channel itself appears encrypted.
2. Mutual Authentication (Client and Server): While TLS 1.3 provides server authentication, robust security in OT environments often requires mutual authentication, where both the client (e.g., TIA Portal) and the server (PLC) authenticate each other. This prevents a rogue engineering station from connecting to a legitimate PLC and vice-versa, even if one side's key is compromised. Organizations should configure and enforce client certificate authentication where supported.
3. Supply Chain Security and Vendor Trust: This research underscores the need for continuous scrutiny of vendor-provided "protocol features" and implementations of security standards. Organizations should engage with vendors to understand the security posture of their products, inquire about internal security audits, and advocate for transparent vulnerability disclosure and rapid patching.
4. Incident Response Planning: Given the potential for devastating impact, organizations must have well-defined incident response plans specifically tailored for ICS environments, including procedures for detecting, containing, eradicating, and recovering from PLC compromises.

By addressing these defensive implications, organizations can build a more resilient and secure operational technology environment, mitigating the risks posed by sophisticated attacks that target the foundational security of industrial controllers.

Key Takeaways

• TLS 1.3 is not a silver bullet: Despite adopting the latest TLS standard, Siemens S7 PLCs (specifically S7 1500) remain vulnerable due to implementation flaws.
• Private key theft is possible: A Siemens-provided protocol feature allows remote retrieval of the PLC's private key, fundamentally compromising its security.
• Stealthy MITM attacks are enabled: With the private key, attackers can perform undetectable Man-in-the-Middle attacks, decrypting, modifying, and injecting malicious commands.
• Legacy issues persist in new contexts: The research highlights how past vulnerabilities (like those leading to Stuxnet and "Rogue 7") continue to influence the security landscape, even with modern cryptographic updates.
• Comprehensive security requires more than just encryption: Secure implementation, robust key management, network segmentation, and behavioral monitoring are crucial alongside strong cryptographic protocols.
• Vendor protocol features require scrutiny: Special attention must be paid to proprietary protocol features which can inadvertently create backdoors or vulnerabilities if not securely designed and implemented.

About the Speaker(s)

The research was presented by Alon Dankner and Nadav Adir. Alon Dankner is identified as a Security Researcher at the Technion and at No Code Security. This is his fourth time presenting research on Siemens PLCs at the Black Hat conference, indicating a deep and sustained focus on industrial control system security. His previous work, "Rogue 7," was instrumental in prompting Siemens to adopt TLS 1.3 for its S7 protocol. Nadav Adir is a software engineering student from the Technion University who worked on this project during his final year of studies, showcasing the valuable contribution of student research to critical security discoveries. The team also includes Professor Eli Biam, Dr. Sara Bitan, Ron Freudental, and Or Keret, all from the Faculty of Computer Science at the Technion.