No VPN Needed? Cryptographic Attacks Against the OPC UA Protocol

No VPN Needed? Cryptographic Attacks Against the OPC UA Protocol

Speaker: Tom Tervoort — Pentester and Security Specialist, Bureau Veritas Cybersecurity

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

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

Reading Time: ~9 minutes

Type: Briefing

TL;DR

Tom Tervoort of Bureau Veritas Cybersecurity found two cryptographic vulnerabilities in the OPC UA industrial protocol that allow an attacker to bypass device authentication without knowing any private key. Five of seven tested implementations were vulnerable in their default configurations, including products from Siemens (WinCC) and Codesys, prompting patches with high CVSS scores.

Introduction

OPC UA (OPC Unified Architecture) is the dominant open standard for communication in industrial automation — used across ICS/SCADA systems, PLCs, and industrial IoT to connect everything from wind turbines to factory floor controllers. Unlike most OT protocols, OPC UA was designed with built-in security: transport encryption, certificate-based device authentication, and user authentication. This reputation has led many OPC UA deployments to expose servers directly across trust boundaries — including across the public internet — without an additional VPN layer.

Tom Tervoort, a pentester at Bureau Veritas Cybersecurity, decided to examine whether that reputation was deserved. What he found was a cross-site-request-forgery-style vulnerability in the session handshake that enables a relay attack to impersonate any trusted client, and a Bleichenbacher-style padding oracle attack against the legacy RSA cipher suite that can bypass authentication in 15 to 120 minutes of automated attack time. Five of seven tested implementations were vulnerable in their default secure configurations.

How OPC UA Cryptography Works

▶ Watch: Protocol Overview (02:00)

OPC UA's security operates across two layers:

Secure channel layer: Establishes transport encryption and device authentication (client and server certificates). The handshake works as follows: the client generates a random nonce, signs it with its own private key, encrypts it with the server's public key, and sends it. The server responds symmetrically. Both nonces feed into a key derivation function to produce session keys for subsequent AES-CBC + HMAC-encrypted messages.

Session layer: Handles user authentication and authorization (password or certificate), typically used when a human operator interacts via an HMI. Both layers are optional and configurable independently.

The protocol supports several "security policies" — cipher suite bundles. All widely implemented variants use RSA for the initial handshake and AES for bulk encryption. Tervoort's attacks target two specific weaknesses in how the handshake is constructed.

Vulnerability 1: The Session Relay Attack

▶ Watch: Relay Attack Mechanics (08:01)

The first vulnerability is a design flaw in the session layer handshake. When the client and server exchange signed challenges to prove their identities, the signing format is identical in both directions — neither message includes context metadata indicating whether it originated from a client or a server. This creates a reflection/relay opportunity in deployments where a single OPC UA node acts as both a client and a server (common in industrial automation topologies).

The attack: an adversary connects to Server A, presenting Server B's certificate as their identity. Server A issues a challenge; the adversary relays it to Server B, posing as Server A in a client role. Server B signs the challenge (legitimately, from its perspective), and the adversary uses that signature to complete authentication on Server A — without ever possessing Server B's private key.

The attack works even more simply in a single-server case, because many implementations trust their own certificate by default. The attacker can mount the relay against the same server, reflecting a signed challenge back in the opposite direction.

The catch: this relay attack only works against OPC UA over HTTPS (a variant where the TCP secure channel handshake is skipped because TLS handles transport security). Without the secure channel, the session layer is the only authentication layer — and that is exactly what the relay bypasses. Tervoort implemented the attack as a tool and confirmed it works. However, OPC UA over HTTPS sees limited real-world adoption; most deployments use the native TCP variant.

Vulnerability 2: Bleichenbacher's Attack on OPC UA over TCP

▶ Watch: Bleichenbacher Attack Explanation (12:01)

To attack the more common TCP variant of OPC UA, Tervoort turned to a well-documented but persistently underappreciated vulnerability: Bleichenbacher's 1998 PKCS#1 v1.5 padding oracle attack, sometimes called the "million message attack." The OPC UA specification supports a legacy cipher suite using RSA with PKCS#1 v1.5 padding — which Bleichenbacher definitively broke a quarter century ago.

The OPC Foundation deprecated this cipher suite and recommends implementors disable it by default. However, Tervoort found that:

• Several implementations leave it enabled by default, either intentionally to maintain backward compatibility or because administrators never changed the default.
• Several implementations that nominally disable it still attempt to decrypt inbound messages using the vulnerable scheme before checking whether the cipher is allowed — meaning a single incoming packet triggers the oracle even on "disabled" servers.
• If even one server in a deployment supports the vulnerable cipher, it can be used as a decryption oracle to attack other servers that have disabled it, because the Bleichenbacher attack targets an RSA private key, not a session-specific secret.

The classical Bleichenbacher attack requires distinguishing whether RSA decryption produced valid PKCS#1 v1.5 padding (i.e., whether the decrypted plaintext starts with 0x00 0x02). Tervoort tried the error-message oracle approach but found that most implementations return identical error messages regardless of padding validity.

Amplifying the Timing Side Channel

▶ Watch: Timing Oracle Implementation (20:02)

Tervoort's solution exploits an architectural quirk in OPC UA's message format. OPC UA uses RSA in a block-cipher-ECB-like structure: because messages exceed a single RSA block size, the protocol splits the message into blocks and encrypts each block individually. This is not how RSA should be used, but it creates an opportunity.

To amplify the timing signal, Tervoort constructs a test message that repeats a single guess ciphertext 100 times. If the padding is invalid, the server decrypts the first block, detects bad padding, and returns an error quickly. If the padding is valid, the server decrypts all 100 blocks before processing — producing a dramatically longer response time.

The resulting timing differences are on the order of tens of seconds — so large that the attack requires no sophisticated statistical machinery. Tervoort used a simple threshold: short response time = invalid padding, long response time = valid padding. With this signal, he implemented the standard Bleichenbacher algorithm, using timing as the oracle instead of error messages.

Attack performance in testing:

• Fastest implementation (C-based): ~15 minutes to complete authentication bypass
• Typical implementations: 30 minutes to 1 hour
• Worst case: ~2 hours
• Attack leaves minimal log traces; in most implementations it was "practically invisible"

Scope and Disclosures

▶ Watch: Disclosure Results (28:02)

Tervoort tested seven OPC UA implementations. Two were not vulnerable to either attack. Five were vulnerable, and four of those five were vulnerable in their default configuration — meaning a deployment that followed vendor defaults for certificate-based authentication would be exposed.

Affected vendors receiving patches include:

• Siemens — multiple products including WinCC server, with high CVSS scores
• Codesys — patches issued

The OPC Foundation coordinated disclosure centrally, responding within one hour of Tervoort's initial report and convening a call with Foundation members the same day. This coordinated approach covered the many implementers under the OPC Foundation umbrella simultaneously.

Tervoort noted that a number of CVEs were issued, and that the same underlying CVE can receive different CVSS scores depending on which vendor product it is mapped to.

Fixes varied by vendor:

• Some disabled the HTTPS variant entirely
• Some implemented workarounds to prevent the padding oracle from firing
• Some updated documentation to explicitly warn against the vulnerable RSA cipher suite
• Some changed default configurations

Should OPC UA Still Be Exposed Without a VPN?

▶ Watch: Conclusions and Threat Model Discussion (34:03)

Tervoort stopped short of recommending that all OPC UA deployments retreat behind VPNs, noting that the appropriate answer depends on threat model and operational capacity.

His recommendations:

• For internet-exposed OPC UA servers, use IP allowlisting as a minimum defense. Even a severe pre-auth authentication bypass is dramatically less dangerous if only trusted IPs can reach the server.
• For organizations that can patch rapidly, the combination of IP allowlisting and timely patching likely provides adequate protection.
• For organizations with long patching cycles — common in OT environments — a VPN overlay provides higher certainty.

The broader lesson from the Q&A exchange: OT environments often cannot follow the rapid patching cadence that makes OPC UA's security model viable. Network segmentation and minimal exposure remain the practical backstop when software controls cannot be maintained.

Notable Quotes

"Bleichenbacher's attack still works in practice. It was possible against TLS for a long time. It was possible against JSON web tokens. People just keep implementing PKCS1 padding."

— Tom Tervoort ▶ 32:03

"The attack was practically invisible. You didn't see anything about it on the other end."

— Tom Tervoort ▶ 26:02

"Four out of five vulnerable implementations were vulnerable in their default configuration — meaning if you used the default secure configuration with client authentication, you would be vulnerable."

— Tom Tervoort ▶ 26:02

"Designing cryptographic protocols is hard. You may be using secure building blocks — AES, HMAC, RSA — but putting them together in the right way is very tricky."

— Tom Tervoort ▶ 32:03

Key Takeaways

• OPC UA's certificate authentication can be bypassed without the private key. Both the relay attack (over HTTPS) and the Bleichenbacher timing attack (over TCP) allow an unauthenticated attacker to impersonate a trusted client.
• Bleichenbacher is still practical in 2025. The attack completes in 15 minutes to 2 hours with no specialized infrastructure — just repeated connections and a timing threshold.
• Check your vendor advisories. Five of seven tested implementations were vulnerable; Siemens and Codesys issued patches. If you use certificate-based OPC UA authentication, verify your vendor has mitigated the issue.
• Disabling the legacy RSA cipher suite and HTTPS variant is a starting point but may not be sufficient depending on your vendor's implementation — some fire the oracle before checking whether the cipher is enabled.
• Internet-exposed OPC UA requires IP allowlisting at minimum, regardless of whether protocol-level authentication is considered secure. The protocol's history of subtle implementation flaws makes defense-in-depth essential.

Slides

No slides PDF was listed for this briefing. Tervoort's attack tool targeting OPC UA over HTTPS was implemented and demonstrated. The Bleichenbacher timing oracle tool is referenced but availability was not specified during the talk.