I recently joined watchTowr, and it is, therefore, time - time for my first watchTowr Labs blogpost

Kentico's Xperience CMS stood out as promising, fulfilling several key criteria: This meets the criteria of something we'd define as “interesting,”

Recently joining the watchTowr Labs team, I wanted to maintain the trail of destruction left by the team and so had to get my teeth into things quickly. Two primary goals were clear:

* Continue the legacy of high-quality research into interesting and impactful vulnerabilities.

* Contribute to the broader security community with our findings.

Kentico’s Xperience CMS stood out as promising, fulfilling several key criteria:

* It’s a widely used solution, powering a large portion of the web.

* The Kentico security team has always been responsive and engaged in disclosing vulnerabilities.

* It presented several interesting technical challenges that we enjoyed exploring.

This meets the criteria of something we’d define as “interesting,” so we began. A few hours later, (sigh), we stumbled into our first Authentication Bypass vulnerability. Throughout this research, we identified the following vulnerabilities:

* WT-2025-0006: Authentication Bypass in Kentico Xperience CMS Staging API

* WT-2025-0007: Post-Auth Remote Code Execution in Kentico Xperience CMS Staging API

* WT-2025-0011: Another Authentication Bypass in Kentico Xperience CMS Staging API

As we walk through this analysis, we’ll take you on our journey that allowed us to build exploit chains to achieve Remote Code Execution against (at the time) fully patched Kentico Xperience CMS deployments.

Time to dive in… (and until next time..)

Vulnerable Configuration

Before we even start deep diving into the vulnerabilities, we want to be clear that the vulnerabilities highlighted in this blogpost do not affect every Kentico CMS installation (but do appear to affect common configurations).

For the vulnerabilities we’re about to discuss, two requirements need to be fulfilled:

* The Staging Service must be enabled.

* The authentication type must be set to User name and password.

However, based on our dataset and exposure across the watchTowr client base, we can confidently say that the above requirements appear to be a common configuration - please do not write these weaknesses off as requiring edge cases. Reassuringly, this seriousness and severity was reflected in the vendors response - the Kentico security team treated all vulnerabilities seriously, and we’ll discuss this further later.

Our research, initially, was performed our initial research on Kentico Xperience 13.0.172. We also found a second Authentication Bypass, while reviewing Kentico Xperience 13.0.173. Although we never reviewed version 12 of Kentico Xperience (or below), we have high-confidence data that version 12 is also vulnerable to both WT-2025-0006 Authentication Bypass and WT-2025-0011 Authentication Bypass.

To get your system into a vulnerable position while you follow this post along at home, a Kentico administrative user can enable the Staging Service within the CMS settings functionality, while selecting the User name and password authentication type, as presented in the next screenshot:

With this configuration complete, the next step is to investigate how this authentication is being performed. Let's dive into the technical details!

WT-2025-0006: Authentication Bypass

When we review new solutions, as we’ve described before a basic aim is to understand the exposed attack surface of the solution and quickly get a feel for how it has been architected. In case of web applications, you may want to look for some REST- or SOAP-based APIs. Interestingly, Kentico’s Experience CMS does not expose a significant number of webservices and endpoints, presenting a relatively small attack surface.

However, a service called CMS.Synchronization.WSE3.SyncServer immediately caught our attention. It exposes a single endpoint, and was interesting for two reasons:

* It’s used for synchronization tasks between several Kentico instances.

* It’s part of the internal Kentico API, not something that is designed to be used by third-party services or applications.

Sounds like fun! Let's try to send a simple HTTP request targeting this web method and just see what happens through the power of FAFO:

We’re presented with the following error message:

In the screenshot above presenting the definition of WebService, you may have noticed a mysterious Policy attribute. Its full class name is Microsoft.Web.Services3.PolicyAttribute, and it's implemented in Microsoft.Web.Services3.dll. We've never heard of this DLL before, and so found ourselves scratching our heads a little here.

A quick Google search revealed that this is part of obsolete (probably since 2012) Web Services Enhancement 3.0 for Microsoft .NET. This is likely superseded by .NET WCF, but it'