CVE-2017-11357

Falha de Insecure Direct Object Reference (IDOR) no handler RadAsyncUpload do Telerik UI for ASP.NET AJAX, que permite a um atacante não autenticado manipular o caminho de destino de arquivos enviados e, combinada com chaves de criptografia previsíveis, realizar upload arbitrário de arquivos e executar código remotamente. É pré-requisito prático conhecer a versão exata do Telerik em uso, mas isso é trivialmente descobrível via resposta HTTP do próprio componente — por isso o CVSS 9.8 é realista e a falha está no catálogo KEV da CISA com exploração confirmada, inclusive por campanhas de cryptomining (Blue Mockingbird).

RadAsyncUpload é o handler de upload assíncrono do Telerik UI for ASP.NET AJAX, exposto via Telerik.Web.UI.WebResource.axd?type=rau. O componente recebe do cliente, dentro do campo rauPostData, valores como TargetFolder e TempTargetFolder que definem onde o arquivo enviado será salvo no servidor. O problema (CWE-20, validação de entrada insuficiente) é que esses valores, embora criptografados, são gerados e interpretados sem restringir adequadamente o objeto/caminho que o usuário pode referenciar — daí o rótulo IDOR: o servidor confia no valor fornecido pelo cliente para decidir onde gravar o arquivo, sem revalidar que o destino está dentro dos limites esperados.

Essa falha está intimamente ligada à CVE-2017-11317, na qual as chaves de criptografia (AES key e IV) usadas para proteger esses campos eram valores hardcoded, iguais em toda instalação do produto até certa versão. Na prática, um atacante que conhece a versão do Telerik em uso consegue criptografar seus próprios valores de TargetFolder/TempTargetFolder usando a mesma chave que o servidor espera, efetivamente falsificando os parâmetros que deveriam ser opacos e não manipuláveis. A combinação das duas falhas é o que torna o IDOR explorável remotamente sem qualquer segredo do lado do servidor.

O atacante controla o conteúdo do arquivo enviado, seu nome, tipo de conteúdo e — via a manipulação do TargetFolder — o diretório de destino dentro dos limites da aplicação web. Isso permite depositar arquivos executáveis (por exemplo, .aspx) em diretórios acessíveis via HTTP, ou seja, upload de webshell seguido de execução arbitrária de código no contexto do processo IIS/ASP.NET.

O vetor é de rede, sem autenticação: o atacante envia requisições HTTP multipart diretamente ao endpoint Telerik.Web.UI.WebResource.axd?type=rau. O pré-requisito real não é acesso privilegiado, mas sim: (1) identificar a versão exata do Telerik.Web.UI em uso no alvo, geralmente exposta em comentários HTML, headers ou strings JavaScript da página; e (2) que essa versão esteja no intervalo vulnerável às chaves de criptografia hardcoded (CVE-2017-11317), pois sem elas o atacante não consegue forjar os campos TargetFolder/TempTargetFolder aceitos pelo servidor.

A correção definitiva do fornecedor é atualizar para R2 2017 SP2 (2017.2.711) ou posterior, release que introduziu tanto o fix do IDOR quanto, pela primeira vez, a capacidade de desabilitar completamente o handler via a chave Telerik.Web.DisableAsyncUploadHandler=true em appSettings no web.config — útil como controle compensatório se RadAsyncUpload não for usado pela aplicação. Para quem está em versões entre Q1 2011 (2011.1.315) e R2 2017 SP1 (2017.2.621) e não pode atualizar imediatamente, o Telerik distribuiu patches específicos por versão (baixados diretamente da conta do cliente após 15/08/2017, não disponíveis via NuGet); cinco versões antigas específicas (Q1 2011 SP2 2011.1.519, Q2 2011 SP1 2011.2.915, Q3 2011 SP1 2011.3.1305, Q1 2012 SP1 2012.1.411, Q2 2012 SP2 2012.2.912) não receberam patch por inviabilidade técnica e exigem upgrade de versão maior.

O fornecedor alerta que essas correções de 2017 (para CVE-2017-11357, CVE-2017-11317 e CVE-2014-2217) NÃO previnem a vulnerabilidade de deserialização subsequente CVE-2019-18935, que reutiliza o mesmo componente. Quem quer eliminar toda a família de riscos conhecida em RadAsyncUpload deve migrar para R1 2020 (2020.1.114) ou posterior — tratar apenas o patch de 2017 como suficiente é o mito a evitar.

Configurações genéricas de rede/web.config para tentar bloquear o acesso ao handler foram testadas e descartadas pelo próprio fornecedor como insuficientes (nota de 23/10/2019, que removeu essa orientação da KB por não ser 'suficientemente segura'). Ou seja, filtragem superficial via configuração de rede não substitui o patch ou o upgrade de versão.

Procurar requisições POST multipart para Telerik.Web.UI.WebResource.axd?type=rau contendo o campo rauPostData, especialmente vindas de IPs externos não associados a usuários legítimos da aplicação, ou volumes anômalos dessas requisições em curto intervalo (característico de tentativas de força bruta na descoberta da chave/versão). Verificar diretórios temporários de upload da aplicação por arquivos com extensões executáveis (.aspx, .ashx) ou nomes atípicos gravados fora do fluxo normal de upload — a falha corrigida passou a gravar temporários com extensão .tmp, então arquivos temporários sem essa extensão em versões patcheadas são um sinal de anomalia. Não há assinatura de rede única e confiável, pois o payload é criptografado antes do envio; a detecção depende mais de monitorar o endpoint e o resultado (arquivos gravados) do que o conteúdo da requisição em si.