Full Report
Sitecore is a CMS written in .NET. They pwned this in 2019 but wanted to see if any new bugs had been added or if they missed anything big years ago. To start with, they do a large amount of recon to look at the functionality without authentication. Additionally, they looked into the Web.config to see how the routing was working. The Sitecore APIs had a standard MVC setup, where the executed route was api/sitecore/{controller}/{action}. While digging around into what they could instantiate with only a few restrictions; it ensures that the object is .NET type and implements the IController interface. A super large attack surface! The class Sitecore.Mvc.DeviceSimulator.Controllers.SimulatorController had the action Preview with the parameter previewPath. This was calling Server.execute under the hood with the parameter that we control. This allows for arbitrary redirects within the application itself without fancy 302s. Damn, that creates a pretty neat authorization bypass! Server.Execute had no restrictions on where it could redirect to. All it had to be was something within the webroot. This function does not rerun the HTTP pipeline (including auth), allowing for bypasses of the IIS setup. Using this, they were able to leak the Web.config file by reading backups. Sitecore's dependency Telerik UI had a known CVE for deserialization that requires knowledge of the Telerik encryption keys. However, since we have this from the backup, we can exploit a deserialization bug to get RCE. While auditing the code base for more things, the path /sitecore/shell/Invoke.aspx caught their eye for obvious reasons. This allows for the arbitrary instantiation of a class and execute any method, with restrictions. In particular, no static items were allowed, a user had to be authenticated and it could only take string parameters. They decided to look for sinks for RCE gadgets. Eventually, they came to DeserializeObject() within the Telerik UI. They followed this back up to find a method that sets this value within a class! Now, they can send in a deserialization method once again to get code execution. They wanted this to be unauthenticated though. A third similar deserialization issue exists as well. Anonymous users couldn't hit the shell endpoint. The endpoint did allow for ANY user to hit the endpoint. If the user wasn't authenticated, the page was still ran but the execution still happened. Within EXM mailing list, the user is set to the Renderer User. They used the Server.execute issue from before to hit this code to trigger the second deserialization attack mentioned above. Neat! I had no idea about the internal redirects causing so many problems. It is super interesting seeing the subtle flaws that can be built with .NET applications. Good read!
Analysis Summary
# Vulnerability: Multiple Vulnerabilities in Sitecore Leading to RCE and Auth Bypass via API and Internal Redirects
## CVE Details
- CVE ID: Pending (Specific IDs were not assigned at the time of writing, pending release via SC2023-001-568150)
- CVSS Score: Not specified in the provided text.
- CWE: Multiple (Improper Access Control, Insecure Deserialization, Open Redirect/Server Side Request Forgery related to redirects)
## Affected Systems
- Products: Sitecore CMS
- Versions: Sitecore version 9.3 specifically audited (and likely other versions with similar functionality).
- Configurations: Affects endpoints leveraging the standard MVC API routing (`api/sitecore/{controller}/{action}`) and internal application handlers.
## Vulnerability Description
The research uncovered several critical flaws stemming from permissive controller instantiation in the Sitecore API pipeline and the dangerous use of `Server.Execute`.
1. **Arbitrary Redirect / Authorization Bypass (via `SimulatorController.Preview`):** The controller `Sitecore.Mvc.DeviceSimulator.Controllers.SimulatorController` exposes an action named `Preview` that accepts a user-controlled `previewPath` parameter. This parameter is passed directly to `Server.Execute` internally. Since `Server.Execute` does not re-run the full HTTP pipeline (including IIS authorization checks), controlling the path allows for **internal application redirects bypassencing standard authorization checks**. This allowed for local file reading (e.g., leaking `Web.config` and backup files).
2. **Remote Code Execution (RCE) via Deserialization (Telerik UI):** Leaked information, such as the `Web.config` or environment secrets, may provide the necessary **Telerik encryption keys**. With these keys, a known deserialization vulnerability within the Sitecore dependency, Telerik UI, can be exploited to achieve RCE.
3. **RCE via Reflected Deserialization (`/sitecore/shell/Invoke.aspx`):** The endpoint `/sitecore/shell/Invoke.aspx` allows for arbitrary class instantiation and method execution, though it normally requires authentication and string-only parameters. Researchers found a gadget path leading to `DeserializeObject()` within the Telerik UI components. Crucially, this endpoint could be hit **unauthenticated** if the request originated from an internal context (e.g., the "Renderer User" context within EXM mailing lists). This path was chained with the initial `Server.Execute` vulnerability to trigger the deserialization gadget unauthenticated.
## Exploitation
- Status: PoC available (implied by detailed methodology and successful exploitation described).
- Complexity: Medium to High (Requires chaining multiple flaws, though the initial bypass is low complexity once the endpoint is known).
- Attack Vector: Network (for initial access/redirect), Internal network context required for the final unauthenticated RCE chain.
## Impact
- Confidentiality: High (Leaking configuration files including secrets, leading to full RCE).
- Integrity: High (Full system compromise via RCE).
- Availability: High (System compromise leading to service disruption).
## Remediation
### Patches
- The issues are addressed in Sitecore Security Bulletin SC2023-001-568150. Customers should consult the official advisory for patched versions.
### Workarounds
- Restrict access to the `/sitecore/shell/Invoke.aspx` endpoint if possible.
- Review code paths utilizing `Server.Execute` or similar internal request dispatching mechanisms to ensure user-controlled input is strictly validated or denied from sensitive internal functions.
- Prevent unauthenticated users or low-privileged internal users (like the EXM Renderer User) from accessing endpoints that might lead to shell execution.
## Detection
- **Indicators of Compromise (IOCs):**
- Unusually large requests against `/api/sitecore/{controller}/{action}` containing unusual controller names that are not standard Sitecore exposed controllers.
- Requests to `.../api/sitecore/DummyController/DummyAction` (for testing API pipeline entry).
- Access attempts or unusual traffic directed towards configurations or internal paths usually protected by IIS, potentially originating from paths that shouldn't trigger Auth checks (e.g., via `Server.Execute`).
- Serialization payload signatures targeting Telerik deserialization endpoints within internal application logs.
- Access to `/sitecore/shell/Invoke.aspx` under the context of the "Renderer User" or other non-administrative accounts.
- **Detection Methods and Tools:** Monitoring web application logs for suspicious `Server.Execute` usage originating from untrusted parameters. Application security monitoring tools should watch for execution paths associated with the `Sitecore.Initialize.dll` or related Telerik components processing arbitrary input.
## References
- Vendor Advisory: hxxps://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1002925
- Research Paper: Bypass IIS Authorisation with this One Weird Trick - Three RCEs and Two Auth Bypasses in Sitecore 9.3 (Assetnote Blog)