Kentico Xperience <= 13.0.172 Staging Sync Server Digest Password Authentication Bypass

Bypass de autenticação no Staging Sync Server do Kentico Xperience 13, explorável via manipulação do campo de username em SOAP digest authentication (WS-Security/WSE3), que permite a um atacante não autenticado acionar tarefas de sincronização e controlar objetos administrativos da CMS. O CVSS 9.8 é justificado apenas se o Staging Service estiver habilitado com autenticação usuário/senha — configuração não padrão, mas segundo a watchTowr comum em bases reais de clientes.

O componente vulnerável é o webservice CMS.Synchronization.WSE3.SyncServer, exposto em /CMSPages/Staging/SyncServer.asmx, que usa Microsoft.Web.Services3.dll — implementação obsoleta (WSE 3.0, descontinuada por volta de 2012) de WS-Security para .NET, anterior ao WCF. A autenticação do serviço é feita via SOAP header wsse:Security com digest de senha (UsernameToken com PasswordDigest), calculado a partir de nonce, timestamp e hash SHA1 da senha combinada ao username.

A falha (CWE-288, Authentication Bypass Using an Alternate Path or Channel, segundo a CISA) está no tratamento de usernames vazios no digest SHA1: a lógica de validação do servidor aceita um digest computado sobre um username vazio como válido, permitindo forjar um token de autenticação sem conhecer a senha real do Staging Service. O atacante controla integralmente o conteúdo do SOAP header de autenticação e o payload de ProcessSynchronizationTaskData enviado ao endpoint.

O comportamento exato variou entre hotfixes, segundo a pesquisa da watchTowr (WT-2025-0011, o achado documentado no PoC público referenciado por esta CVE): antes do Hotfix 173, o bypass funcionava com qualquer username informado no digest; entre Hotfix 173 e 177, passou a exigir um username válido de Staging Service (o padrão é 'admin'), mas o bypass da senha continuava possível. O Hotfix 178 corrigiu definitivamente o problema.

Vale notar uma divergência entre a descrição oficial da CVE ('this issue affects Xperience through 13.0.172') e a pesquisa primária que a fundamenta: o hotfix imediatamente após 13.0.172 (173) resolveu apenas parte do problema, e a exploração com username correto permaneceu viável até o Hotfix 177, sendo o Hotfix 178 o que efetivamente elimina o bypass de digest de senha.

Pré-requisito essencial, e frequentemente omitido em leituras rápidas da CVE: o Staging (Sync) Service precisa estar habilitado — desabilitado por padrão em instalações novas — e configurado para autenticação por usuário/senha. A alternativa de autenticação via certificado X.509, segundo a watchTowr, não é afetada. Sem essa configuração ativa, o endpoint SOAP nem responde de forma explorável.

Com o pré-requisito satisfeito, o ataque é pré-autenticado e feito via rede: uma única requisição HTTP POST ao endpoint SyncServer.asmx, com um SOAP header WS-Security contendo um UsernameToken cujo digest é calculado sobre um username vazio (ou, em hotfixes posteriores a 173, sobre o username válido do serviço — 'admin' por padrão — mas ainda sem a senha real). O servidor aceita a autenticação como válida e processa o corpo da requisição (ProcessSynchronizationTaskData), que carrega dados de sincronização de staging.

O impacto final é controle sobre objetos administrativos do CMS via o mecanismo de sincronização de staging — na prática, criação/modificação de páginas e objetos que o Staging Service normalmente sincroniza entre ambientes. A própria pesquisa da watchTowr descreve isso como parte de uma cadeia que, combinada com outras falhas encontradas na mesma investigação (incluindo uma RCE pós-autenticação), pode levar a execução remota de código pré-autenticação em instalações totalmente atualizadas na época do teste. A CVE está no catálogo KEV da CISA (adicionada em 20/10/2025, prazo de correção 10/11/2025), confirmando exploração ativa; há template Nuclei e PoC pública, o que reduz a barreira de exploração para qualquer atacante com acesso de rede ao endpoint.

A correção definitiva do bypass de digest de senha, segundo a pesquisa que fundamenta a CVE, está no Hotfix 13.0.178 do Kentico Xperience 13 — não no Hotfix 173, apesar do texto da CVE citar '13.0.172' como limite. Ambientes em qualquer hotfix anterior ao 178 devem ser tratados como vulneráveis, mesmo que já tenham aplicado hotfixes posteriores ao 173. Hotfixes são cumulativos, então aplicar o 178 (ou mais recente disponível) resolve o problema sem exigir reinstalação completa.

Se a atualização não for viável de imediato, o controle compensatório real é desabilitar o Staging Sync Service (estado padrão de fábrica) ou, caso seja necessário mantê-lo ativo, migrar a autenticação de usuário/senha para autenticação por certificado X.509 — que, segundo a pesquisa, não é afetada por essa classe de falha. Restringir acesso de rede ao endpoint /CMSPages/Staging/SyncServer.asmx (firewall, segmentação, allowlist de IPs dos servidores de staging legítimos) reduz a superfície de exposição mas não elimina o risco caso a rede interna já esteja comprometida.

Não existe mitigação eficaz baseada apenas em rotacionar a senha do Staging Service: a falha está na lógica de validação do digest com username vazio/malformado, não na força da credencial em si — trocar a senha sem aplicar o hotfix não impede o bypass.

Não há assinatura de detecção publicada e validada por fonte oficial. Dado o mecanismo, requisições POST para /CMSPages/Staging/SyncServer.asmx com SOAPAction referenciando ProcessSynchronizationTaskData, originadas de IPs que não correspondem aos servidores de staging legítimos configurados, ou contendo cabeçalhos WS-Security (wsse:Security/UsernameToken) com valores de username vazios ou anômalos, são candidatos razoáveis a indicador de tentativa de exploração. Na ausência de logging detalhado desse endpoint SOAP legado (WSE3), muitos ambientes não terão visibilidade retroativa suficiente para confirmar tentativas passadas — vale tratar isso como lacuna de detecção real, não apenas teórica.