No VPN Needed? Cryptographic Attacks Against the OPC UA Protocol

No VPN Needed? Cryptographic Attacks Against the OPC UA Protocol

Speakers: Tom Tervoort

Conference: DEF CON 33 (Las Vegas, August 2025)

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

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Tom%20Tervoort%20-%20No%20VPN%20Needed%20Cryptographic%20Attacks%20Against%20the%20OPC%20UA%20Protocol.pdf

Overview

OPC UA (Unified Architecture) is the dominant open-standard protocol for industrial automation, connecting PLCs, SCADA systems, and remote monitoring endpoints in facilities ranging from gas pipelines to wind farms. Vendors and integrators have long promoted OPC UA's built-in cryptographic features as a reason to skip traditional VPN overhead — if the protocol encrypts and authenticates traffic natively, why bolt on another layer?

Tom Tervoort's DEF CON 33 presentation systematically dismantles that argument. Working as a security consultant and pentester at Bureau Veritas Cybersecurity, Tervoort applied his background in offensive cryptography — the same approach that uncovered the Zerologon vulnerability (CVE-2020-1472) in Active Directory — to the OPC UA protocol stack. He found two distinct, practically exploitable cryptographic vulnerabilities. Both derive from flawed protocol design rather than merely outdated algorithm choices, meaning that swapping cipher suites alone cannot fix them.

The talk is a masterclass in applied cryptographic attack research: taking textbook primitives (RSA PKCS#1 v1.5, CBC-mode padding, timing oracles), identifying how they surface in an underexamined industrial protocol, and building a working PoC to confirm exploitability across multiple vendor implementations.

Background

▶ Watch: Background: OPC UA security modes and the false sense of security (2:14)

What Is OPC UA?

OPC UA is a client/server protocol designed for industrial control and automation. Unlike its predecessors — many of which are proprietary or based on aging serial-era designs — OPC UA is formally standardized, interoperable across vendors, and ships with built-in security mechanisms:

• Client/server authentication via X.509 certificates
• User authentication via passwords, JWTs, or client certificates
• Transport integrity and confidentiality negotiated via security policies (cipher suites)

OPC UA's security architecture spans two protocol layers:

1. Secure Channel Layer — performs an RSA-based key exchange; both client and server authenticate their machine identities using X.509 certificates; negotiates a symmetric session key for subsequent messages.
2. Session Layer — handles user authentication; uses challenge-response signing with the same certificates negotiated in the channel phase.

The security policies available are analogous to TLS cipher suites:

| Security Policy | Encryption | Signing |

|---|---|---|

| None | — | — |

| Basic128Rsa15 | RSA PKCS#1 v1.5 | SHA1 + RSA PKCS#1 v1.5 |

| Basic256 | RSA-OAEP-SHA1 | SHA1 + RSA PKCS#1 v1.5 |

| Basic256Sha256 | RSA-OAEP-SHA1 | SHA256 + RSA PKCS#1 v1.5 |

| Aes128_Sha256_RsaOaep | RSA-OAEP-SHA1 | SHA256 + RSA PKCS#1 v1.5 |

| Aes256_Sha256_RsaPss | RSA-OAEP-SHA256 | SHA256 + RSA-PSS |

The protocol also supports an OPC UA over HTTPS transport mode, where TLS replaces the secure channel layer. That variant, as it turns out, creates its own distinct attack surface.

Key Findings

▶ Watch: Attack 1: signing oracle enables relay attack between OPC UA servers (10:58)

Tervoort identified two separate attack chains:

Attack 1 — Signing Oracle Authentication Bypass: The session layer's challenge-response protocol is redundant with the already-established secure channel layer. This redundancy creates an opportunity for a relay (man-in-the-middle) or reflection attack: an attacker can trick one party into signing the other party's challenge, bypassing the authentication check entirely without ever knowing the target's private key. The OPC UA over HTTPS variant is particularly vulnerable because it does not perform the secure channel handshake at all — there is no channel-layer authentication to fall back on — making authentication bypass via the signing oracle a direct attack path.

Attack 2 — Padding Oracle Authentication Bypass: The Basic128Rsa15 security policy uses RSA PKCS#1 v1.5 encryption, which is vulnerable to Bleichenbacher's 1998 padding oracle attack. By sending specially crafted ciphertexts and observing whether decryptions produce validly formatted PKCS#1 padding, an attacker can iteratively narrow down the value of the encrypted plaintext. In OPC UA, the attack can be driven through either an error-based oracle (different error responses for padding vs. signature failures) or a timing oracle (measuring how long the server spends decrypting before failing). Because RSA signing and RSA decryption use the same private key operation, a successful Bleichenbacher attack can also forge valid signatures.

CVEs assigned: CVE-2024-42512, CVE-2024-42513, CVE-2025-1468.

Technical Deep Dive

▶ Watch: Attack surface: industrial machine-to-machine OPC UA in SCADA environments (15:43)

Secure Channel Handshake

The channel handshake involves the client encrypting a message with the server's RSA public key (the nonce used for key derivation) and signing it with its own private key. The server decrypts, verifies the signature, then reciprocates. Both sides plug their exchanged nonces into a KDF to derive the symmetric AES+HMAC session key.

Session Handshake and the Signing Oracle

Once the secure channel is established (all subsequent messages encrypted), the session layer executes a challenge-response:

1. Client sends its challenge to the server.
2. Server signs the client's challenge with the same private key used in the channel phase, sends back its own challenge.
3. Client signs the server's challenge.

Tervoort observed that this is largely redundant — the channel phase already authenticates both parties cryptographically. More critically, the structure enables a relay attack: intercept a CreateSessionResponse from a legitimate server, and the challenge signature it contains can be replayed against a client connecting to a different server. The even cleaner variant is a reflection attack, where a single TCP connection is used to have the target sign its own challenge.

For OPC UA over HTTPS, no secure channel handshake is performed; TLS handles transport security but does not require TLS client certificates. This means the session layer's challenge-response is the only authentication mechanism — and the signing oracle attack bypasses it directly.

Bleichenbacher's Padding Oracle (1998 → 2025)

The PKCS#1 v1.5 padding scheme used in Basic128Rsa15 requires decrypted ciphertext to match the format 0x00 0x02 [nonzero bytes] 0x00 [message]. If padding is invalid, the server returns an error. If padding is valid but the resulting message is malformed, a different error (or different timing) results. This differential is the oracle.

By iterating over approximately 1,000,000 queries — each crafting a ciphertext that multiplies the unknown value by a carefully chosen factor — an attacker recovers the exact plaintext message, including the nonce used to derive the session key. Alternatively, the same oracle allows forging arbitrary RSA signatures.

The timing side-channel amplifier: Tervoort's elegant twist on the timing oracle exploits OPC UA's "ECB-mode" RSA decryption behavior (the protocol decrypts each fixed-size block of the message independently). By repeating a ciphertext block 100 times, valid PKCS#1 padding causes the server to perform 100 RSA decryptions before failing on the bad message content, while invalid padding causes it to fail after just one decryption. The timing difference is dramatically amplified — turning a subtle nanosecond-level side channel into something measurable over a network.

Basic128Rsa15 — Still in the Wild

Although the Basic128Rsa15 policy is deprecated in recent OPC UA specifications, several implementations still enable it by default. More insidiously, some implementations begin decrypting a PKCS#1 v1.5 ciphertext before checking whether the policy is even enabled — leaking oracle information even when Basic128Rsa15 is nominally disabled. A working configuration change does not necessarily stop the oracle from being exercised at the decryption layer.

Demo / PoC

▶ Watch: Attack 2: Bleichenbacher padding oracle attack against RSA key exchange (20:16)

Tervoort demonstrated live exploitation at DEF CON, using a tool he developed and released publicly:

Tool: https://github.com/SecuraBV/opcattack

The tool implements:

• Detection of signing oracle conditions across OPC UA over TCP and OPC UA over HTTPS
• Error-based padding oracle enumeration
• Timing-based padding oracle with amplification using repeated ciphertext blocks
• Automated false positive elimination

Tested Implementations

| Software | Version | HTTPS Attack | Error-based Oracle | Timing-based Oracle |

|---|---|---|---|---|

| dataFEED edgeConnector 2 | 2024.01 | ✗ | ✗ | ✗ |

| Ignition | 8.1.38 | ✗ | ✓ | ✓ |

| KEPServerEX | 6.15.154.0 | ✗ | ✗ | ✓* |

| open62541 | 1.4 | ✗ | ✗ | ✓ |

| Prosys OPC UA Simulation Server | 5.4.6-180 | ✓ | ✓ | ✓ |

| UA-.NETStandard Reference Server | 1.4.372-preview | ✓ | ✓ | ✓ |

| Unified Automation C++ Demo Server | 1.8.2.624 | ✗ | ✗ | ✗ |

\* Only in non-default configuration. Additional confirmations received from CODESYS and various Siemens products.

Defensive Implications

▶ Watch: Results: all attacks verified in lab against real OPC UA implementations (33:43)

The OPC Foundation was notified, coordinated with vendors, and responded rapidly. Fixes range from software updates to disabling specific policy options to configuration advisories.

Defenders should take the following steps:

1. Disable Basic128Rsa15 wherever possible. Even if configured as disabled, check whether the underlying implementation still processes PKCS#1 v1.5 ciphertexts. Confirm with vendor documentation and update to patched versions.
2. Disable OPC UA over HTTPS unless absolutely necessary, or ensure the endpoint is protected behind a separate authentication layer. Without a client certificate requirement at the TLS layer, HTTPS transport leaves only the session challenge-response for machine authentication — which the signing oracle can bypass.
3. Prefer RSA-PSS (Aes256_Sha256_RsaPss) over RSA PKCS#1 v1.5 for all signing operations. PSS is probabilistic and not susceptible to signature forgery via padding oracles.
4. Do not expose OPC UA endpoints directly to the internet. Tervoort's conclusion is nuanced: the built-in security features are not a complete substitute for network segmentation. A VPN or firewall still provides meaningful defense-in-depth, particularly given the large number of unpatched deployments in the field.
5. Review network logs for high volumes of failed session handshakes, which may indicate active oracle enumeration. A padding oracle attack requires roughly a million queries — that volume is detectable.
6. Non-certificate-based user authentication (password, JWT) is not directly affected by these vulnerabilities, since the attacks target the machine authentication layer.

Key Takeaways

• OPC UA's built-in cryptography contains protocol-level design flaws, not merely weak algorithm choices. Rolling cipher suites alone does not resolve the vulnerabilities.
• The signing oracle attack (Attack 1) is a logic flaw in the session handshake that creates relay and reflection attack opportunities; it is particularly severe in OPC UA over HTTPS deployments where no channel-layer authentication exists.
• The Bleichenbacher padding oracle (Attack 2) — first published in 1998 — is still practically exploitable in multiple widely-used industrial products in 2025. The timing oracle amplification technique makes this attack feasible over a network without any special hardware.
• The PoC tool (opcattack) is publicly available and can be used by defenders to audit their own OPC UA deployments.
• Industrial operators who have removed VPN infrastructure in favor of OPC UA's native security features should re-evaluate that decision until vendor patches are applied and configurations are verified.

About the Speaker

Tom Tervoort is a pentester and security consultant at Bureau Veritas Cybersecurity, based in the Netherlands. His specialization sits at the intersection of offensive cryptographic research and practical penetration testing — specifically identifying exploitable cryptographic vulnerabilities through real-world protocol analysis. He is best known for discovering Zerologon (CVE-2020-1472), a critical privilege escalation vulnerability in the Netlogon protocol used by Active Directory, which led to an emergency Microsoft patch and CISA advisory. His subsequent research has focused on industrial protocol security, resulting in the OPC UA vulnerabilities disclosed at DEF CON 33. He has previously presented at Black Hat and other major security conferences.