CVE-2019-18935

Falha de deserialização insegura no handler RadAsyncUpload do Telerik UI for ASP.NET AJAX (até 2019.3.1023), que permite RCE completo no processo do IIS. A exploração exige que o atacante conheça a chave de criptografia usada para proteger o parâmetro rauPostData — algo trivial se a instalação nunca trocou a chave padrão (CVE-2017-11317) ou se a chave puder ser extraída por outro meio (ex.: leitura do web.config). Está no catálogo KEV da CISA com exploração confirmada em ambientes reais, incluindo uma agência federal dos EUA.

O handler AsyncUploadHandler (acessível em /Telerik.Web.UI.WebResource.axd?type=rau) recebe o parâmetro rauPostData, composto por duas partes separadas por '&': um JSON de configuração e o nome do tipo (assembly qualified type name) para o qual esse JSON deve ser deserializado. Esse par é passado para SerializationService.Deserialize(string, Type), que instancia um JavaScriptSerializer parametrizado com o tipo informado na própria requisição — CWE-502, deserialização insegura com tipo controlado pelo atacante. Markus Wulftange (Code White) identificou que, ao contrário do que se pensava desde 2017, o rauPostData não serve só para configurar upload: ele permite escolher livremente a classe .NET a ser deserializada.

Durante a deserialização, o JavaScriptSerializer chama os setters do tipo especificado. O gadget usado na exploração pública é System.Configuration.Install.AssemblyInstaller, cujo setter carrega uma DLL a partir de um caminho arbitrário. Se essa DLL for uma mixed-mode assembly, o carregamento executa seu DllMain() automaticamente, resultando em execução de código arbitrário no contexto do worker process (w3wp.exe).

O obstáculo prático é que todo o rauPostData é criptografado. Até a R2 2017 SP1 (2017.2.621), essa criptografia usava uma chave fixa no código: PrivateKeyForEncryptionOfRadAsyncUploadConfiguration (CVE-2017-11317). Sem trocar essa chave, qualquer atacante pode forjar e descriptografar o parâmetro. A vulnerabilidade correlata CVE-2017-11357 (IDOR no nome do arquivo gravado) e outros vetores de leak (ex.: exposição do web.config, oráculo criptográfico de CVE-2017-9248) também permitem obter a chave em instalações que já corrigiram o hard-code mas mantêm outra falha aberta.

Para que o RCE funcione de forma prática, o atacante também precisa saber a versão exata do assembly Telerik.Web.UI (usada no nome do tipo) e ter permissão de escrita em algum diretório acessível ao processo do IIS — normalmente uma pasta temporária como C:\Windows\Temp, já que a conta padrão do App Pool raramente tem escrita no document root.

O vetor é HTTP não autenticado: requisições POST para Telerik.Web.UI.WebResource.axd?type=rau. Pré-requisito central — e frequentemente ignorado na leitura do CVSS 9.8 — é conhecer a chave de criptografia do rauPostData. Na prática isso quase sempre significa uma instalação que nunca alterou a chave padrão vulnerável a CVE-2017-11317, ou que expôs a chave por outro meio (leak de configuração, IDOR de CVE-2017-11357). Sem a chave, não há como forjar um rauPostData válido e a cadeia inteira não se sustenta.

Com a chave em mãos, o exploit público (RAU_crypto, exploit noperator/CVE-2019-18935) segue duas etapas: primeiro, faz upload de uma DLL mixed-mode para um diretório gravável no servidor (normalmente pasta temp); depois, envia um rauPostData forjado especificando System.Configuration.Install.AssemblyInstaller como tipo e apontando para o caminho da DLL enviada. A deserialização carrega a DLL e executa seu DllMain(), dando shell no contexto do w3wp.exe. Ferramentas públicas também permitem brute-force da versão exata do Telerik.Web.UI necessária para montar o nome de tipo correto, reduzindo drasticamente o espaço de busca.

Há exploração ativa confirmada: a CVE está no catálogo KEV da CISA, existe módulo Metasploit, múltiplos PoCs públicos (RAU_crypto, CVE-2019-18935 por noperator) e um caso documentado de comprometimento de agência federal dos EUA via essa falha, segundo reportagem da BleepingComputer. A Bishop Fox relata ter explorado instâncias expostas na internet durante engajamentos de segurança.

A correção definitiva é atualizar para 2020.1.114 ou versão posterior, onde o fornecedor introduziu uma configuração padrão que bloqueia a exploração. Na versão intermediária 2019.3.1023 existe uma configuração não padrão que pode ser habilitada manualmente para impedir a exploração, mas ela não é ativada por padrão — quem está nessa versão precisa aplicar a configuração explicitamente, não apenas confiar no número da versão.

Para quem não pode atualizar imediatamente, o controle compensatório real é garantir que a chave de criptografia do RadAsyncUpload (Telerik.Web.UI.DialogParametersEncryptionKey / configuração equivalente do RadAsyncUpload) nunca esteja no valor padrão hard-coded associado a CVE-2017-11317, e que nenhum outro vetor (IDOR de CVE-2017-11357, exposição de web.config, oráculo de CVE-2017-9248) permita recuperá-la. Isso reduz a superfície mas não é substituto do patch: se a chave for descoberta por qualquer meio, a cadeia de exploração volta a funcionar em versões não corrigidas. Restringir ou bloquear acesso externo ao endpoint Telerik.Web.UI.WebResource.axd?type=rau via controle de rede/WAF é mitigação adicional, não solução — a falha está na lógica de deserialização, não apenas no transporte.

O que NÃO funciona: apenas corrigir CVE-2017-11317/CVE-2017-11357 sem atualizar para 2020.1.114 (ou aplicar a configuração de 2019.3.1023) deixa a superfície de deserialização aberta caso a chave seja obtida por qualquer outro meio — a proteção real contra CVE-2019-18935 em si só veio com essas versões/configurações específicas.

Procurar por requisições POST repetidas a Telerik.Web.UI.WebResource.axd?type=rau, especialmente sequências de tentativas variando o parâmetro de versão do assembly (padrão de brute-force de versão usado por ferramentas públicas) e por respostas com latência anômala (indicativo de payloads de teste com Sleep() usados para validar a deserialização antes do ataque real). No sistema de arquivos, verificar a criação inesperada de arquivos .dll em diretórios temporários graváveis pelo processo do IIS (ex.: C:\Windows\Temp) seguida de erros de runtime do ASP.NET no log de aplicação, coincidindo com essas requisições. Não há assinatura única e confiável no nível de rede além do endpoint e do padrão de payload — como o rauPostData é criptografado, o conteúdo malicioso não é legível em texto claro nos logs sem a chave, o que limita a detecção baseada só em payload.