CVE-2017-11317

Falha na criptografia usada pelo controle RadAsyncUpload do Telerik UI for ASP.NET AJAX: o parâmetro que define a pasta de destino do upload é protegido por uma chave AES fixa embutida no assembly Telerik.Web.UI.dll, igual em todas as instalações que não definiram uma chave customizada. Um atacante remoto e não autenticado que conheça essa chave pode forjar o parâmetro criptografado, escolher onde e com que nome o arquivo é gravado no servidor e enviar um arquivo executável (ex. .aspx), abrindo caminho para RCE. É pré-condição de praticamente todo pentest interno/externo em stacks ASP.NET legadas com Telerik e está no catálogo KEV da CISA por exploração confirmada em campo.

O componente RadAsyncUpload recebe, via multipart/form-data no endpoint Telerik.Web.UI.WebResource.axd?type=rau, um bloco JSON (rauPostData) com campos como TargetFolder, TempTargetFolder e a string de versão do assembly. Esse JSON é criptografado com AES em modo CBC usando uma chave e um IV fixos, hardcoded no Telerik.Web.UI.dll, a menos que o desenvolvedor tenha explicitamente configurado uma chave de criptografia customizada (prática que praticamente nenhuma implantação padrão fazia antes de a vulnerabilidade se tornar pública). CISA classifica a falha como CWE-326 (Inadequate Encryption Strength / uso de criptografia fraca), porque a robustez do algoritmo AES é irrelevante quando a chave é conhecida e compartilhada por todas as instalações.

Como a chave é previsível, qualquer parte que interage com o servidor pode gerar seu próprio blob criptografado válido, incluindo valores arbitrários para TargetFolder/TempTargetFolder — isso permite direcionar o upload para caminhos fora do diretório temporário esperado. A versão do assembly em uso é detectável a partir do próprio HTML da página (comentário de versão) ou de outros metadados expostos pelo controle, o que permite ao atacante ajustar o formato exato do payload (a partir de R1 2017 o protocolo passa a exigir um HMAC adicional sobre o JSON, mas esse HMAC também usa uma chave estática conhecida).

A CVE-2017-11317 é frequentemente explorada em conjunto com a CVE-2017-11357 (Insecure Direct Object Reference no mesmo mecanismo, presente nas versões R1 2017 até R2 2017 SP1) — o mesmo exploit público (RAU_crypto.py) cobre as duas CVEs porque ambas decorrem da mesma criptografia fraca/hardcoded aplicada a versões diferentes do controle.

O vetor é uma requisição HTTP POST não autenticada ao endpoint do RadAsyncUpload (Telerik.Web.UI.WebResource.axd?type=rau), presente em qualquer aplicação ASP.NET Web Forms que use o controle Telerik UI e não o tenha desabilitado. O único pré-requisito real é que a aplicação não tenha configurado uma chave de criptografia customizada para o RadAsyncUpload — configuração que a documentação do fornecedor recomenda como mitigação, mas que raramente era aplicada por padrão nas versões afetadas. Não é necessária autenticação, interação do usuário, nem configuração de rede especial: é isso que justifica o vetor de rede AV:N/PR:N/UI:N do CVSS.

Na prática, ferramentas públicas (o script RAU_crypto.py, distribuído como PoC no Exploit-DB e incorporado a módulo do Metasploit) automatizam a etapa de detectar a versão do Telerik.Web.UI em uso, montar o JSON de configuração do upload com a chave AES fixa conhecida, e enviar um arquivo cujo conteúdo e extensão são controlados pelo atacante para um caminho acessível via web. Uma vez que o arquivo malicioso (tipicamente um .aspx com código de execução de comandos) seja gravado num diretório servido pela aplicação, basta acessá-lo via HTTP para obter execução de código no contexto do processo do IIS/ASP.NET.

Há exploração ativa confirmada — a CVE está no catálogo KEV da CISA desde abril de 2022 — e a combinação de baixa complexidade de ataque, ausência de autenticação e disponibilidade de PoC/exploit Metasploit desde 2018 tornou essa falha um dos vetores mais usados contra servidores IIS expostos rodando Telerik antigo, incluindo campanhas de webshell e comprometimento de servidores corporativos.

O fornecedor não trata isso como um único patch pontual, mas como uma cadeia de correções por faixa de versão. Para instalações entre Q1 2011 (2011.1.315) e R3 2016 SP2 (2016.3.1027), é preciso aplicar um patch manual do assembly Telerik.Web.UI.dll (baixado da conta Telerik do cliente) e desabilitar o handler nativo do RadAsyncUpload, ou migrar para R2 2017 SP2 (2017.2.711) ou posterior. Para instalações entre R1 2017 (2017.1.118) e R2 2017 SP1 (2017.2.621) — que também carregam a IDOR relacionada CVE-2017-11357 — as mesmas duas opções se aplicam: aplicar o patch e desabilitar o handler, ou atualizar para R2 2017 SP2+. A partir de R2 2017 SP2 (2017.2.711) o fornecedor removeu as chaves padrão e adicionou a capacidade de desabilitar completamente o RadAsyncUpload; ainda assim é necessário configurar manualmente chaves de criptografia customizadas seguindo o artigo de segurança do RadAsyncUpload, porque a ausência de chave padrão não elimina a necessidade de definir uma própria.

Custo real do paliativo: cinco versões específicas (2011.1.519, 2011.2.915, 2011.3.1305, 2012.1.411, 2012.2.912) não têm patch disponível por inviabilidade técnica — nessas, a única saída é upgrade completo. Desabilitar o RadAsyncUpload quando ele não é usado pela aplicação é a mitigação de menor custo, mas exige validar que nenhuma funcionalidade dependa dele.

O próprio fornecedor alerta que os patches de 2017 para CVE-2014-2217/CVE-2017-11317 não protegem contra CVE-2019-18935 (deserialização via JavaScriptSerializer, explorada por campanhas como Blue Mockingbird) — corrigir apenas esta CVE dá falsa sensação de segurança. A recomendação atual do fornecedor é atualizar para R1 2020 (2020.1.114) ou posterior, que é a única linha que mitiga o conjunto completo de vulnerabilidades conhecidas do RadAsyncUpload. Apenas trocar a extensão de arquivos aceitos ou aplicar filtro de upload no WAF sem tratar a chave de criptografia hardcoded não resolve o problema de fundo.

Procurar por requisições POST para o endpoint Telerik.Web.UI.WebResource.axd?type=rau (ou variações com axd/ashx equivalentes) vindas de IPs externos sem sessão autenticada prévia, especialmente contendo o campo rauPostData com blobs base64 longos e múltiplos parâmetros multipart (file, fileName, contentType, metadata) — esse padrão de requisição é característico do RAU_crypto.py e de módulos Metasploit derivados dele. Vale também correlacionar com a criação de arquivos com extensão executável (.aspx, .ashx) em diretórios de upload temporário da aplicação, fora do padrão .tmp esperado nas versões corrigidas, e acessos subsequentes a esses arquivos via GET — indício de webshell implantado.

Não há assinatura única confiável, porque a exploração usa tráfego HTTP legítimo do próprio recurso da aplicação; ambientes sem WAF ou logging de payload de upload dificilmente detectam a tentativa antes da gravação do arquivo malicioso no disco.