From Padding Oracle to Shell: Unauthenticated RCE in Telerik UI for ASP.NET

From Padding Oracle to Shell: Unauthenticated RCE in Telerik UI for ASP.NET

Speakers: Marcio Almeida, Security Researcher, Temple Security

Conference: BSides Canberra

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

Overview

In this compelling talk at BSides Canberra, Marcio Almeida from Temple Security unveils a sophisticated attack chain that leads to unauthenticated Remote Code Execution (RCE) in Telerik UI for ASP.NET. The research began during a client engagement focused on Telerik applications, where Almeida discovered the framework's reliance on AES-CBC encryption. This discovery prompted an investigation into whether a previously patched deserialization vulnerability from 2019, which exploited static encryption keys, could be revived through a padding oracle attack. The presentation meticulously details how a combination of cryptographic flaws, novel bypass techniques, and an unpatched deserialization gadget allows an attacker to achieve full control over affected Telerik applications.

Almeida's work demonstrates a masterful understanding of cryptographic primitives and their practical exploitation. He not only identifies two distinct padding oracles within the Telerik framework but also devises an ingenious method to overcome the challenge of a static Initialization Vector (IV) using a JSON injection trick with "sacrificial blocks." This innovation enables the injection of arbitrary JSON payloads, ultimately leading to the loading and execution of malicious code. The talk culminates in a demonstration of both persistent and memory-only web shells, highlighting the severe impact of these vulnerabilities and the advanced post-exploitation capabilities they afford.

The findings underscore the persistent danger of insecure cryptographic implementations and deserialization vulnerabilities, even in widely used commercial UI frameworks. The talk is a critical resource for defenders and red teamers alike, offering deep technical insights into advanced exploitation techniques and providing actionable recommendations for securing ASP.NET applications that utilize Telerik UI. This research ultimately led to the disclosure of 12 CVEs, prompting Telerik to adopt authenticated encryption (AES-GCM) as a fundamental fix.

Background

▶ Watch: Introduction and Telerik RCE vulnerability overview (0:00)

The journey into Telerik UI's vulnerabilities began with an observation: the framework utilized AES-CBC (Advanced Encryption Standard in Cipher Block Chaining mode) for encrypting client-side states and configurations. This immediately raised a red flag, as CBC mode, by default, does not provide message authentication code (MAC) or authenticated encryption (AE). This lack of integrity protection means that ciphertext can be manipulated without detection before decryption, a crucial prerequisite for padding oracle attacks.

Almeida quickly referenced the infamous 2019 Telerik vulnerability (CVE-2019-18935), which involved deserialization of configuration payloads encrypted with static keys. While that specific vulnerability was patched, the underlying use of AES-CBC suggested a potential avenue to revive similar issues through a padding oracle.

To understand the attack, a foundational understanding of block ciphers, padding, and CBC decryption is essential. Block ciphers operate on fixed-size blocks of data. When a message's length doesn't align with the block size, padding is added. The talk focuses on PKCS#7 padding, a common scheme where the number of bytes needed to complete the block is used as the byte value for the padding itself (e.g., 090909090909090909 for nine missing bytes). During decryption, the application checks the last byte, determines the expected padding length, and then verifies if all padding bytes match this value. If they do, the padding is considered valid; otherwise, it's a bad padding error. A unique scenario arises when a message perfectly fills all blocks, in which case PKCS#7 dictates adding an entire new block of padding.

AES-CBC decryption involves an Initialization Vector (IV) for the first block and the previous ciphertext block for subsequent blocks. Each ciphertext block is first decrypted with the secret key to produce an intermediate block, which is then XORed with the IV or the previous ciphertext block to yield the plaintext. The XOR operation is critical, possessing three key properties:

1. Associative: A XOR B = C implies A XOR C = B and B XOR C = A.
2. Identity: A XOR 0 = A.
3. Self-inverse: A XOR A = 0.

These properties allow an attacker to manipulate ciphertext blocks to infer information about the plaintext or to forge new plaintext.

The core of a padding oracle attack lies in exploiting the application's distinct response to valid versus invalid padding. By systematically modifying bytes in the ciphertext and observing the application's error messages (e.g., "bad padding" vs. a different error for valid padding but malformed plaintext), an attacker can iteratively deduce the plaintext byte by byte. Once the intermediate bytes of a block are recovered, these can be XORed with the original ciphertext to reveal the plaintext. Crucially, by XORing desired plaintext with the intermediate bytes, an attacker can also forge custom ciphertext that decrypts to their chosen plaintext. This fundamental understanding forms the bedrock upon which the more complex Telerik exploitation chain is built.

Key Findings

▶ Watch: Identifying two distinct padding oracles in Telerik UI (24:00)

Almeida's research yielded several critical findings that collectively enabled unauthenticated RCE in Telerik UI for ASP.NET:

1. Discovery of Two Distinct Padding Oracles: Two specific entry points within the Telerik RadAsyncUpload control were identified as vulnerable to padding oracle attacks:

• Configuration Handler Oracle: When processing requests to the WebResource.axd handler related to RadAsyncUpload, the application attempts to decrypt a serialized configuration. An InvalidOperationException is thrown if the decrypted JSON is malformed but the padding is valid, contrasting with a CryptographicException for invalid padding.
• Client State Oracle: Similarly, when a page containing RadAsyncUpload loads and processes its client state, the same distinction between CryptographicException (bad padding) and InvalidOperationException (valid padding, bad JSON) can be observed. These distinct error messages provide the necessary oracle signal.

1. Bypassing the Static IV Limitation: Telerik's use of a static IV posed a significant challenge. In CBC mode, the IV is XORed only with the first intermediate block. If the IV is static and not controlled by the attacker, forging a custom plaintext for the first block becomes impossible without knowing the encryption key. Almeida's ingenious solution involved a JSON injection trick combined with sacrificial blocks. By identifying a sufficiently long string field within the Telerik JSON payload (e.g., allowedFileExtensions), the attacker could strategically align their custom payload such that the uncontrolled, garbage plaintext from the first block landed inside a JSON string. By adding additional "sacrificial" blocks, the attacker could effectively push this garbage further into the string, ensuring that the critical JSON structure (quotes, key-value pairs) remained intact and controllable by the attacker's forged ciphertext. This allowed arbitrary JSON content to be injected despite the static IV.

1. Rediscovery of an Unpatched Deserialization Gadget: The research uncovered an active, unpatched deserialization vulnerability within the RadAsyncUpload's metadata processing. While the 2019 vulnerability (CVE-2019-18935) focused on a specific deserialization entry point, Almeida identified another instance where the type.gettype method was used to deserialize an object based on a type name provided within the JSON metadata. This allowed an attacker to specify any arbitrary .NET type and control its properties through reflection, effectively bypassing the previous patch and creating a new unauthenticated deserialization gadget.

1. Exploitation Chain for RCE: The identified vulnerabilities were chained together to achieve unauthenticated RCE:

• The padding oracle and JSON injection technique were first used to decrypt the existing configuration and forge the allowedFileExtensions property to accept .dll files.
• The attacker then uploaded a specially crafted mixed-mode DLL (containing both native DLLMain and managed C# code) to the server's temporary upload directory.
• Finally, the padding oracle and JSON injection were used again to forge the metadata, changing the asyncPayloadTypeName to System.Configuration.Install.AssemblyInstaller, pointing it to the path of the uploaded malicious DLL. When the server processed this, the AssemblyInstaller loaded the DLL, triggering its DLLMain and executing arbitrary code.

1. Advanced Web Shell Payloads: To demonstrate RCE, Almeida developed two novel web shell payloads:

• Persistent Disk-Based Web Shell: This payload used GetCommandLine to locate the web root directory from the application pool's configuration and then wrote an encrypted web shell to disk. While effective, it depended on write permissions in the web root, which isn't always available.
• Memory-Only Web Shell: This highly stealthy payload injected an IHttpModule directly into the ASP.NET request pipeline in memory. It bypassed loader locks by starting a separate thread, then used reflection to navigate AppDomains and inject the module. This module would intercept requests, execute commands from a special HTTP header, and replace the response, leaving no disk artifacts after an application pool recycle.

1. Timing Oracle in Patched Versions: Telerik's attempt to patch the initial padding oracle (version 4.2.1) by unifying error messages within a single try-catch block was found to be insufficient. The speaker discovered that a timing oracle still existed. Even with unified exceptions, valid padding that led to a JSON deserialization attempt still took measurably longer to process than invalid padding that failed earlier. This subtle timing difference was enough to rebuild the padding oracle, proving that merely unifying error messages is not a robust defense against such attacks.

1. Comprehensive Fix: AES-GCM: The ultimate and effective fix implemented by Telerik (version 7.0.8) was to migrate from AES-CBC to AES-GCM (Galois/Counter Mode). As an authenticated encryption mode, AES-GCM inherently provides both confidentiality and integrity. Any tampering with the ciphertext, including padding oracle attempts, results in an immediate and uniform authentication tag failure, thereby eliminating any measurable timing differences or distinct error messages.

These findings collectively highlight a complex interplay of cryptographic weaknesses and deserialization flaws, demonstrating the advanced techniques required to both identify and exploit them, even in enterprise-grade software.

Technical Deep Dive

▶ Watch: Developing an in-memory web shell for stealthy RCE (48:00)

The technical foundation of this attack rests on understanding Telerik's architecture, the intricacies of CBC padding oracles, and the novel bypasses developed by Almeida.

Telerik UI for ASP.NET applications typically rely on a single DLL, Telerik.Web.UI.dll, which simplifies reverse engineering. Requests to WebResource.axd are crucial, as this handler maps specific keys (e.g., aiu for RadAsyncUpload) to internal controllers. The RadAsyncUpload control, central to this attack, operates on a client-server model. The client-side component generates an object, encrypts its internal states (client states or configurations), and passes them to the browser. When the user interacts with the control (e.g., uploading a file), this encrypted state is sent back to the server. The server then decrypts this information and trusts its content, even if it has been tampered with. This trust, coupled with the lack of integrity in AES-CBC, is the root cause of the vulnerability.

Identifying the Padding Oracles

Almeida identified two main padding oracle entry points:

1. getConfiguration (Handler-based): The RadAsyncUpload handler processes an incoming payload, splitting it into two parts: a configuration and an assembly type. The configuration part is encrypted. The Decrypt function is called, followed by JSON deserialization. If decryption fails (e.g., bad padding), a CryptographicException is thrown. If decryption succeeds but the resulting plaintext JSON is malformed, an InvalidOperationException is thrown. This distinction in exception types provides the oracle.
2. Client State (Page-based): When a page loads a RadAsyncUpload control, it decrypts metadata from its client state. The same Decrypt function and subsequent JSON deserialization logic are invoked. Consequently, the same CryptographicException vs. InvalidOperationException distinction provides a second padding oracle.

The Static IV Challenge and JSON Injection Bypass

A critical hurdle was the use of a static Initialization Vector (IV). In CBC mode, the IV is XORed with the intermediate block of the first ciphertext block to produce the first plaintext block. If the IV is static and unknown to the attacker, they cannot control the plaintext of the first block. This means any attempt to forge custom plaintext for the initial part of the payload would result in unpredictable, potentially invalid, characters.

Almeida's innovative bypass, inspired by JSON parameter pollution, involved using JSON injection with sacrificial blocks. The core idea is to find a long string field within the Telerik JSON structure, such as allowedFileExtensions. The attacker then crafts their payload such that the uncontrolled, "garbage" plaintext resulting from the static IV's effect on the first block falls within a JSON string value. By adding an extra "sacrificial" block before the attacker-controlled JSON, the attacker can effectively "push" the garbage further into the string, allowing the attacker to begin their controlled JSON at a predictable, exploitable point (e.g., closing a quote, injecting a new key-value pair). This allows the attacker to inject arbitrary JSON, despite not controlling the first plaintext block. For example, to inject ".dll" into allowedFileExtensions, the attacker decrypts up to that point, then crafts a payload that closes the existing string, injects ,"allowedFileExtensions":[".dll"], and then re-opens a string to consume the remaining uncontrolled plaintext.

Deserialization Gadget and RCE

The next step was to find a deserialization gadget that could be triggered by the injected JSON. The RadAsyncUpload control's metadata deserialization was the target. The JSON structure includes a type field, which is processed by Type.GetType(). While the 2019 vulnerability focused on a different entry point, Telerik had not patched this specific deserialization. This meant an attacker could specify any .NET type, and its properties would be populated via reflection.

The chosen gadget was System.Configuration.Install.AssemblyInstaller. This class is designed to install assemblies, and its Install method can be triggered by deserialization. By setting the AssemblyInstaller.Assembly property to a path on disk, the AssemblyInstaller will attempt to load that assembly.

The RCE chain proceeds as follows:

1. Initial Payload Forgery: Using the padding oracle and JSON injection, the allowedFileExtensions property in the RadAsyncUpload configuration is modified to include .dll. The tempTargetFolder is also recovered to know where uploaded files will land.
2. DLL Upload: A specially crafted mixed-mode DLL is uploaded. Mixed-mode DLLs are unique as they contain both native C++ code (with a DllMain entry point) and managed .NET code. When Windows loads any native DLL, it automatically executes its DllMain function. This provides an immediate code execution primitive upon loading.
3. Second Payload Forgery: A second padding oracle attack is performed to forge the RadAsyncUpload metadata. The asyncPayloadTypeName is set to System.Configuration.Install.AssemblyInstaller, and its Assembly property is set to the full path of the uploaded malicious DLL.
4. RCE Trigger: When the server processes this forged metadata, it attempts to deserialize AssemblyInstaller. This triggers the loading of the specified DLL, which in turn executes the malicious code within its DllMain.

Advanced Web Shells

To maintain control post-exploitation, Almeida developed two types of web shells:

1. Persistent Disk-Based Web Shell: This payload aims for persistence. Upon execution, it uses the Windows API GetCommandLine() to retrieve the command line arguments of the w3wp.exe process (the IIS worker process). These arguments often contain the path to the applicationHost.config file, which can be parsed to find the physical path of the web root. The payload then writes an encrypted web shell (e.g., an .aspx file) to this directory. Subsequent requests to this web shell would decrypt and execute commands. This method, however, is limited by server write permissions in the web root.

1. Memory-Only Web Shell: This payload is designed for stealth and avoids disk artifacts.

• Loader Lock Bypass: When a DLL is loaded, the .NET runtime imposes a "loader lock," preventing certain operations. The payload bypasses this by spawning a new, unattached thread. This allows the main loading thread to complete and release the loader lock.
• AppDomain Navigation and Injection: The new thread, after a short delay, re-attaches itself and uses reflection to navigate the AppDomains within the w3wp.exe process. It locates the HttpApplicationFactory's free list, which contains instances of HttpApplication.
• IHttpModule Injection: Using reflection, the payload gains access to the request pipeline and dynamically injects a custom IHttpModule. This module is configured to intercept incoming HTTP requests. If a specific header (e.g., X-Cmd) is present, the module executes the command provided in the header and replaces the HTTP response with the command's output. If the header is absent, the request proceeds normally. This method leaves no persistent disk artifacts, as the injected module resides only in memory and vanishes upon application pool recycle.

Guardrails and Timing Oracle in Telerik 4.2.1

Telerik's version 4.2.1 introduced two guardrails:

1. CSRF Token: A CSRF token was added to the encrypted configuration. However, Almeida found this was the fifth field in the JSON structure. Since his JSON injection technique only modified the suffix of the payload (e.g., allowedFileExtensions), the CSRF token was simply carried along unchanged, making it ineffective as a mitigation. A simple page refresh could provide a fresh, valid token for the attack.
2. Page GUID: A page GUID was appended to uploaded filenames. This was easily bypassed as the GUID was present and predictable on the page itself.

Crucially, Telerik 4.2.1 also attempted to patch the padding oracle by wrapping both decryption and JSON deserialization errors in a single try-catch block, returning a unified error message. However, this only converted the padding oracle into a timing oracle. Valid padding, even if leading to malformed JSON, still caused the application to execute the JSON deserialization logic, which took measurably longer than an immediate CryptographicException from invalid padding. This subtle time difference was sufficient for Almeida and his colleague (who elaborated on this in a subsequent talk) to rebuild the padding oracle.

The Ultimate Fix: AES-GCM

The final, comprehensive fix released in Telerik UI version 7.0.8 involved migrating all affected cryptographic operations from AES-CBC to AES-GCM. AES-GCM is an authenticated encryption with associated data (AEAD) mode. It provides both confidentiality (encryption) and integrity (authentication) in a single operation. Any attempt to tamper with the ciphertext or its associated data will cause the authentication tag verification to fail, resulting in an immediate and uniform error without revealing any information about padding validity or timing differences. This effectively eliminates all padding and timing oracle attacks.

Demo / Proof of Concept

▶ Watch: Full exploit demonstration against Telerik POC application (60:00)

Marcio Almeida presented a reenactment of the exploit chain, acknowledging that a live demonstration of the full attack would take approximately one hour due to the iterative nature and volume of requests involved. The demonstration showcased the end-to-end process from unauthenticated access to remote code execution.

The exploit requires several parameters:

• target: The URL of the WebResource.axd handler.
• page: The URL of an ASP.NET page hosting the RadAsyncUpload control.
• oracle_mode: Specifies whether to target the handler or the postback mechanism (for version 4.2.1 and later, postback mode is used).
• dll_path: The local path to the malicious mixed-mode DLL payload.

The exploit proceeds through several automated phases:

1. Information Gathering: The tool first navigates to the specified page to fetch encrypted configuration blobs and the page's GUI ID. It extracts necessary information for subsequent steps, such as the initial encrypted RadAsyncUpload configuration.

1. Decrypting Configuration and Forging allowedFileExtensions:

• The exploit initiates a padding oracle attack against the encrypted configuration. It iteratively decrypts the configuration block by block, byte by byte, until it recovers the allowedFileExtensions field and the tempTargetFolder path. The demonstration showed retry messages, indicating the exploit's self-healing capability to re-attempt failed byte decryptions, which is crucial for slow padding oracle attacks.
• Once allowedFileExtensions is located, the exploit uses the JSON injection technique with sacrificial blocks to forge a new configuration where allowedFileExtensions includes .dll.

1. CSRF and Page GUID Refresh: To bypass the CSRF token and ensure a fresh page GUID for the uploaded file, the exploit performs a page refresh. It then updates its internal state with the new, valid CSRF token and GUI ID.

1. Malicious DLL Upload: The forged configuration is then used to upload the attacker's custom mixed-mode DLL. The DLL is uploaded to the tempTargetFolder recovered earlier, and its filename is constructed using the fresh page GUI ID. The server's response includes encrypted metadata for the newly uploaded file.

1. Decrypting Metadata and Forging AssemblyInstaller Payload:

• The exploit then decrypts the metadata of the uploaded file, recovering its full server-side path.
• A second padding oracle attack is performed to forge a new metadata payload. This payload changes the asyncPayloadTypeName to System.Configuration.Install.AssemblyInstaller and sets its Assembly property to the full server-side path of the just-uploaded DLL.

1. RCE Trigger and Web Shell Activation:

• This forged AssemblyInstaller payload is submitted to the server. The server attempts to process it, leading to a 500 Internal Server Error (a type-casting error) as it tries to instantiate the AssemblyInstaller as an AsyncUpload type. However, by this point, the AssemblyInstaller has already loaded the malicious DLL, executing its DllMain and planting the memory-only web shell.
• Finally, the exploit sends a request to the server with a special HTTP header (e.g., X-Cmd) containing a command like whoami. The memory-only web shell intercepts this, executes the command, and returns the output in the HTTP response.

The entire attack chain, as demonstrated, involved approximately 130,000 requests and, in a lab environment, ran at a rate of roughly 30 requests per second, taking around 1 hour to complete end-to-end. The exploit was successfully verified against Telerik UI for ASP.NET versions 2.2.5, 4.2.1, and 5.1.9, demonstrating its broad applicability across different release cycles.

Defensive Implications

▶ Watch: Disclosure process, fixes (AES-GCM), and acknowledgments (70:00)

The detailed technical article highlights several critical defensive implications for organizations using Telerik UI for ASP.NET or any application handling encrypted client-side data:

1. Adopt Authenticated Encryption: The most crucial takeaway is the mandatory use of authenticated encryption (AEAD), such as AES-GCM, for any data that is both encrypted and needs integrity protection. AES-CBC, without an accompanying MAC, is fundamentally vulnerable to padding oracles and should be replaced. Telerik's move to AES-GCM in version 7.0.8 is the appropriate fix.
2. Avoid Custom Cryptographic Implementations: Whenever possible, rely on well-vetted and standard cryptographic libraries or framework features that correctly implement authenticated encryption. Custom encryption schemes are notoriously difficult to implement securely and often introduce subtle flaws that lead to vulnerabilities like padding oracles.
3. Implement Strict Deserialization White-listing: Deserialization of arbitrary types remains a high-risk operation. Applications should employ strict white-listing of acceptable types for deserialization. If possible, consider alternative, safer data formats like JSON (without type information), Protocol Buffers, or MessagePack, which inherently limit deserialization risks.
4. Regularly Update Third-Party Components: Keep all third-party libraries and UI frameworks, including Telerik UI, updated to their latest secure versions. The research demonstrates that even seemingly patched vulnerabilities can resurface or be bypassed in new ways.
5. Monitor for Cryptographic Anomalies: Implement logging and monitoring for cryptographic exceptions, unusual error messages, or suspicious timing differences in application responses. While a robust fix like AES-GCM prevents these, such monitoring can be an early indicator of attempted attacks against older or custom cryptographic implementations.
6. Restrict Web Application Write Permissions: Ensure that web application processes (e.g., IIS worker processes) operate with the principle of least privilege. Specifically, restrict write access to the web root directory and other critical system paths. This mitigates the impact of exploits that attempt to plant persistent web shells on disk.
7. Implement Egress Filtering: Employ strong network egress filtering to prevent outbound connections from web servers. This significantly hinders reverse shell payloads, making it harder for attackers to establish command and control channels even if RCE is achieved.
8. Understand Application Trust Boundaries: Re-evaluate application trust boundaries. If client-side data is encrypted and sent to the server, the server should never implicitly trust its content solely because it's encrypted, especially if the encryption scheme lacks integrity. Always validate and sanitize decrypted data as if it were unencrypted user input.

Key Takeaways

• Padding oracles can revive patched vulnerabilities: The talk vividly demonstrates how a padding oracle can bypass previous deserialization patches, highlighting the need for comprehensive security fixes rather than point solutions.
• Static IVs are not a silver bullet: Even with a static IV, clever JSON injection techniques utilizing "sacrificial blocks" can enable arbitrary data forgery and RCE.
• Unified error messages are insufficient: Merely unifying error messages in try-catch blocks does not prevent padding oracles if timing differences exist, leading to subtle timing oracles.
• Authenticated Encryption is critical: AES-GCM or similar AEAD modes are essential for both confidentiality and integrity, providing the only robust defense against padding oracle attacks by invalidating any ciphertext tampering.
• Deserialization of arbitrary types is dangerous: The AssemblyInstaller gadget highlights the ongoing risk of allowing deserialization of arbitrary types, which can lead to RCE.
• Memory-only implants enhance stealth: Advanced post-exploitation techniques, such as injecting IHttpModule into the request pipeline, allow for stealthy, memory-resident web shells without leaving disk artifacts.

About the Speaker(s)

Marcio Almeida is a security researcher at Temple Security. He is actively involved in identifying and exploiting vulnerabilities in widely used applications and frameworks. His work often focuses on cryptographic weaknesses and deserialization flaws, as evidenced by his detailed research on Telerik UI for ASP.NET. Almeida is a returning speaker at BSides Canberra, sharing his findings and contributing to the broader cybersecurity community's understanding of complex attack vectors.