Breaking OPC UA: How to Bypass Authentication with Cryptographic Oracles

TLDR: Industrial control systems often rely on the OPC UA protocol, assuming its built-in security features make VPNs unnecessary. Research presented at DEF CON 2025 reveals that improper implementation of RSA-based cryptography, specifically the use of the deprecated PKCS#1 v1.5 padding scheme, allows attackers to perform signing and padding oracle attacks. These flaws enable full authentication bypass on vulnerable PLC and SCADA implementations, turning a supposed security feature into a critical entry point.

Industrial control systems are notoriously difficult to secure, and the industry has long leaned on the "security through obscurity" model. When that fails, vendors point to protocols like OPC UA, claiming that because it supports encryption and authentication, you can safely expose these services to broader networks. This is a dangerous assumption. The research presented by Tom Tervoort at DEF CON 2025 proves that if you rely on the protocol's built-in cryptographic features without rigorous implementation, you are essentially handing the keys to the kingdom to anyone with a network connection.

The Cryptographic House of Cards

The core of the problem lies in how OPC UA handles its secure channel and session handshakes. The protocol allows for various security policies, many of which rely on RSA for key exchange and signing. While modern standards have moved toward more robust padding schemes, many industrial implementations are still stuck in 1998, using the PKCS#1 v1.5 padding scheme.

This is not just a theoretical concern. The research identified that the way these implementations handle RSA decryption and signing creates a classic oracle. By observing how a server responds to malformed or specifically crafted messages, an attacker can determine whether the padding is correct. This is the hallmark of a Bleichenbacher-style padding oracle attack.

The attack flow is deceptively simple. When a client initiates a connection, it sends a challenge that the server must sign. If the server is using a vulnerable implementation, an attacker can act as a "signing oracle." By intercepting the server's request and relaying it to another instance or manipulating the session, the attacker can force the server to sign arbitrary data. Once you can force the server to sign your challenge, you have effectively bypassed the machine-level authentication.

Exploiting the Oracle

The most effective way to weaponize this is through a timing-based side channel. Because RSA decryption is computationally expensive, the time it takes for a server to process a message varies significantly depending on whether the padding is valid or invalid.

# Simplified logic for a timing-based padding oracle
def check_padding(payload):
    start_time = time.time()
    response = send_to_server(payload)
    duration = time.time() - start_time
    
    if duration > threshold:
        return True # Valid padding detected
    return False

In a real-world engagement, you don't need to be a cryptographer to pull this off. The PoC tool released by the researcher automates the process of sending thousands of messages to the target. By measuring the response latency, the tool can narrow down the exact value of the decrypted message.

What makes this particularly nasty is that it works even when the server doesn't explicitly return an error message. You are not looking for a "padding error" string in the response; you are looking for a microsecond difference in processing time. On a local network or a stable connection, this is trivial to measure. Once the tool recovers the necessary nonces or session keys, the authentication is effectively nullified.

Real-World Impact on ICS

If you are performing a penetration test on a facility using CODESYS or Siemens WinCC environments, you should be looking for these OPC UA endpoints. These systems are often the bridge between the IT and OT networks. If you can bypass authentication on an OPC UA server, you are not just looking at a data leak; you are looking at the ability to read and write tags directly to PLCs. You could potentially stop a production line, alter sensor readings, or manipulate physical processes.

The impact is amplified by the fact that many of these devices are configured with default settings that prioritize interoperability over security. If the server supports the HTTPS variant of OPC UA, the attack becomes even easier, as the TLS layer provides a convenient transport for the oracle.

Defensive Hardening

Defending against this is straightforward but requires discipline. First, stop using legacy security policies. If your configuration allows for Basic128Rsa15, disable it immediately. It is deprecated for a reason. Second, implement strict network segmentation. There is no reason for an OPC UA endpoint to be reachable from an untrusted network. Use IP allow-listing to ensure that only authorized engineering workstations can communicate with the server.

Finally, check your vendor documentation for security advisories related to CVE-2024-42513 and CVE-2025-1468. Many vendors have released patches that either disable the vulnerable padding schemes or introduce constant-time processing to mitigate the timing side channel.

Do not assume that because a protocol has a "secure" mode, it is secure by default. Cryptographic protocol design is notoriously difficult, and as this research demonstrates, even widely used industrial standards can harbor vulnerabilities that have been known to the security community for over two decades. If you are testing these systems, treat every cryptographic handshake as a potential oracle until proven otherwise.