CVE-2020-13671

Falha no núcleo do Drupal (CWE-434, Unrestricted Upload of File) faz com que nomes de arquivos enviados com extensões duplas — como arquivo.php.txt — não sejam sanitizados corretamente pelo mecanismo de "munging" (inserção de underscore antes da extensão perigosa). Dependendo da configuração do servidor web, isso pode fazer o arquivo ser servido com MIME type errado ou executado como PHP. Exige um usuário autenticado com permissão de upload, então não é uma falha pré-autenticação — mas está no catálogo KEV da CISA, confirmando exploração real.

O Drupal core tenta neutralizar uploads perigosos inserindo um underscore antes de extensões consideradas executáveis (ex: .php, .pl, .cgi), transformando arquivo.php.txt em arquivo.php_.txt. O SA-CORE-2020-012 documenta que essa lista de extensões perigosas estava incompleta e que a lógica de munging falhava para nomes com múltiplas extensões em certas combinações, permitindo que o arquivo final passasse pela sanitização sem o underscore protetor. O advisory do próprio Drupal lista explicitamente as extensões que devem ser tratadas como perigosas mesmo seguidas de outra extensão: phar, php, pl, py, cgi, asp, js, html, htm, phtml — deixando claro que a lista anterior no core não cobria todos esses casos.

O atacante controla o nome do arquivo enviado através de qualquer campo de upload do site (campo de arquivo em conteúdo, comentário, formulário, etc.) para o qual tenha permissão. O impacto final depende inteiramente da configuração de hospedagem: em servidores Apache (ou outros) configurados para executar arquivos com base em qualquer extensão reconhecida na cadeia do nome — não apenas a última — um arquivo como imagem.php.jpg pode ser interpretado e executado como PHP, mesmo que a extensão final pareça inofensiva. Em configurações que não fazem esse tipo de handling multi-extensão, o resultado prático se limita a servir o arquivo com Content-Type incorreto, o que ainda abre espaço para XSS refletido/armazenado se o navegador ou proxy tentar renderizar o conteúdo como HTML.

O vetor CVSS (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflete essa combinação: rede, baixa complexidade, mas privilégio baixo obrigatório (PR:L) — ou seja, é preciso estar autenticado com permissão de upload no site, não é uma falha anônima.

Para explorar, o atacante precisa de uma conta autenticada com permissão de enviar arquivos em algum ponto do site — um campo de upload de conteúdo, um formulário de comentário com anexo, um módulo de webform, etc. Não há vetor pré-autenticação documentado pelo fornecedor. O atacante nomeia o arquivo com uma extensão dupla que escapa da lista de munging vigente na versão vulnerável (por exemplo, combinando uma extensão executável com uma extensão "segura" sem underscore entre elas) e o envia através do fluxo normal de upload do site.

O resultado depende da pilha de hospedagem: em ambientes onde o servidor web (tipicamente Apache com handlers configurados para múltiplas extensões, via mod_mime ou similar) decide executar o arquivo com base em qualquer extensão reconhecida na cadeia do nome, o arquivo enviado é processado como script PHP, dando execução de código no contexto do servidor web. Em ambientes sem esse comportamento, o impacto se reduz a servir o arquivo com Content-Type incorreto, o que pode viabilizar XSS armazenado se o conteúdo for renderizado como HTML pelo navegador.

O advisory classifica o risco como AC:Basic/A:User — ou seja, a complexidade de ataque é considerada básica pelo próprio Drupal, mas ainda exige uma conta de usuário com privilégio de upload. A presença no catálogo KEV da CISA (adicionada em 18/01/2022, com prazo de correção em 18/07/2022) confirma exploração ativa documentada, embora a CISA não detalhe campanhas específicas nem associação com ransomware.

A correção definitiva é atualizar para as versões corrigidas: Drupal 7.74, 8.8.11, 8.9.9 ou 9.0.8, dependendo do branch em uso. O próprio advisory recomenda adicionalmente auditar todos os arquivos já enviados ao site em busca de extensões maliciosas — procurando especificamente arquivos com mais de uma extensão (padrão nome.ext1.ext2) sem underscore entre elas, prestando atenção a phar, php, pl, py, cgi, asp, js, html, htm e phtml precedendo qualquer outra extensão.

Quem não pode atualizar imediatamente deve revisar a configuração do servidor web para impedir a execução de scripts com base em extensões intermediárias do nome do arquivo (evitar handlers que processam qualquer extensão reconhecida na cadeia, não apenas a última), e restringir ao mínimo quais papéis de usuário têm permissão de upload de arquivos no site — já que a falha exige essa permissão como pré-requisito. Branches do Drupal 8 anteriores a 8.8 são end-of-life e não recebem correção de segurança; sites nessas versões precisam migrar de branch, não apenas aplicar patch.

Não funciona como mitigação apenas bloquear extensões no campo de upload do formulário sem revisar a configuração de execução do servidor — o problema central é a interpretação do nome do arquivo pelo servidor web, não somente a validação no lado do Drupal.

Auditar o diretório de arquivos enviados por usuários buscando nomes com mais de uma extensão sem underscore separador, com atenção especial a arquivos cuja extensão intermediária seja phar, php, pl, py, cgi, asp, js, html, htm ou phtml seguida de outra extensão (padrão nome.php.txt, nome.phtml.jpg etc.) — essa é a assinatura textual recomendada pelo próprio advisory do Drupal. Em logs de servidor web, procurar requisições a esses arquivos que resultaram em execução de script (código de status e tempo de resposta atípicos para um recurso estático) ou em Content-Type divergente do esperado para a extensão final. Não há assinatura de rede confiável para o tráfego de exploração em si, já que o upload passa pelo fluxo normal e legítimo de formulário do site.