drupalgeddon2-cli

Uma reescrita de linha de comandos da prova de conceito do Drupalgeddon2 (CVE-2018-7600), criada como exercício de estudo durante o módulo Attacking Common Applications da Hack The Box Academy.

[!WARNING] Apenas para testes de segurança autorizados e fins educativos. Executar isto contra sistemas que não possui ou para os quais não tem permissão escrita explícita para testar é ilegal na maioria das jurisdições. Consulte Uso legal e responsável.

[!NOTE] Implementação escrita com assistência de IA. Consulte Nota sobre a autoria.

Contexto — por que criei isto

O Drupal é uma das "aplicações comuns" abordadas no módulo Attacking Common Applications da HTB Academy, e o CVE-2018-7600 ("Drupalgeddon2") é o exemplo canónico de RCE não autenticada para esse contexto. Em vez de copiar e colar um script descartável e seguir em frente, quis perceber de facto a injeção na Form API que torna a falha possível — por isso reconstruí o PoC público do zero como exercício de aprendizagem.

O original amplamente referenciado, a2u/CVE-2018-7600 de Vitalii Rudnykh, é ótimo para demonstrar a falha, mas pressupõe que edite o payload no próprio código em cada execução. Num fluxo de trabalho de laboratório/CTF — reexecutando contra alvos diferentes, querendo um ponto de apoio repetível — isso torna-se tedioso. Esta versão transforma-o numa verdadeira ferramenta CLI:

• o alvo e o comando são passados como argumentos; sem editar o código-fonte em cada execução
• implanta automaticamente uma pequena web shell PHP (o próprio servidor vulnerável escreve o ficheiro), dando um ponto de apoio estável e reutilizável
• pode executar um único comando, entrar numa pseudo-shell interativa ou apenas implantar a shell e ir embora
• o nome do ficheiro da shell e o parâmetro de comando são aleatorizados em cada execução, para que uma repetição não colida e não deixe uma porta cmd= previsível aberta atrás de si

Está deliberadamente limitada a uma vulnerabilidade conhecida e corrigida há muito tempo (divulgada em 2018). O objetivo era compreender a técnica e produzir uma implementação de referência limpa e documentada — não uma capacidade ofensiva nova.

Nota sobre a autoria

O código neste repositório foi escrito com assistência de IA (Claude da Anthropic) enquanto percorria o módulo da HTB. Defini os objetivos e requisitos de design — ergonomia da CLI, auto-implantação da web shell, modo interativo, nome da shell e parâmetro aleatorizados — e revi e testei o resultado. Divulgo isto porque é o que é honesto fazer, e porque o valor aqui está na compreensão e nas decisões de engenharia, e não na autoria de cada linha.

O que faz

1. Utiliza a injeção na Form API do CVE-2018-7600 para colocar uma pequena web shell PHP no alvo. O próprio servidor vulnerável descodifica e escreve o ficheiro, o que contorna problemas de aspas/escape no comando injetado.
2. Permite-lhe executar comandos através dessa shell com --cmd, ou entrar numa pseudo-shell interativa com --shell.
3. Verifica que a shell foi realmente implantada e executa (devolve um token aleatório e verifica-o) antes de reportar sucesso.

Versões afetadas

O CVE-2018-7600 afeta:

• Drupal 7.x anterior a 7.58
• Drupal 8.x anterior a 8.5.1 (também 8.3.x < 8.3.9 e 8.4.x < 8.4.6)

Esta implementação tem como alvo o vetor da Form API do Drupal 8 (o endpoint AJAX user/register). O Drupal 7 é explorável através de um endpoint/payload diferente e não é tratado aqui.

As versões corrigidas (7.58 / 8.5.1 e posteriores) não são afetadas.

Requisitos

• Python 3.7+
• requests

pip install requests

Utilização

# comando único
python3 drupalgeddon2.py -u http://target/ -c id

# pseudo-shell interativa
python3 drupalgeddon2.py -u http://target/ --shell

# apenas implantar a shell, não executar nada
python3 drupalgeddon2.py -u http://target/ --deploy-only

# encaminhar pelo Burp, ignorar o certificado autoassinado do proxy
python3 drupalgeddon2.py -u http://target/ -c id --proxy http://127.0.0.1:8080 -k

Como funciona

O CVE-2018-7600 é uma falha de sanitização de entrada na Form API do Drupal. O Drupal representa formulários como arrays renderizáveis aninhados, e as chaves de array que começam com # são tratadas como propriedades de renderização especiais, e não como dados de utilizador. O patch (SA-CORE-2018-002) adicionou sanitização para remover estas chaves prefixadas com # da entrada fornecida pelo utilizador.

Antes do patch, um atacante não autenticado podia injetar propriedades de renderização num elemento de formulário processado pelo handler AJAX do Drupal. Submeter propriedades como:

• #post_render — uma lista de callables que o Drupal invoca após a renderização, e
• #markup — o argumento passado a essas callables

contra o elemento mail do formulário de registo de utilizador faz com que o Drupal chame uma função PHP arbitrária (aqui, exec) com entrada controlada pelo atacante durante o passo de renderização — ou seja, execução remota de código, sem autenticação necessária.

Este PoC usa essa primitiva para codificar em base64 uma shell PHP de uma linha localmente, fazer com que o servidor a descodifique para um ficheiro na raiz web e depois interagir com esse ficheiro através de pedidos GET normais.

Deteção e remediação

Se está do lado da defesa:

Remediação

• Atualize para Drupal 7.58 / 8.5.1 ou posterior (aplique o SA-CORE-2018-002). Esta é a única correção real.
• Se a atualização imediata for impossível, a Equipa de Segurança do Drupal publicou um patch de mitigação na altura da divulgação — mas atualizar é fortemente preferível.

Ideias de deteção

• Inspecione os corpos de pedidos POST para endpoints de formulários/AJAX à procura de chaves de array de renderização: #post_render, #markup, #type, #lazy_builder, etc. Submissões legítimas de formulários não contêm estas chaves.
• Sinalize pedidos para …/user/register?element_parents=…&_wrapper_format=drupal_ajax que contenham parâmetros suspeitos.
• Correlacione um POST para um endpoint de formulário AJAX com um GET subsequente para um ficheiro .php recém-criado na raiz web.
• Esteja atento a criação inesperada de ficheiros na raiz web do Drupal e a ficheiros PHP curtos com um único parâmetro (system($_GET[...]) shells).
• Estes comportamentos são fáceis de codificar como assinaturas Suricata/Snort ou regras Sigma sobre os logs do servidor web.

Créditos

• PoC original e técnica central: Vitalii Rudnykh — a2u/CVE-2018-7600
• Divulgação da vulnerabilidade: Equipa de Segurança do Drupal — SA-CORE-2018-002
• Análises aprofundadas da técnica que informaram esta reescrita: os artigos de investigação da Check Point e da Ambionics sobre o Drupalgeddon2
• Esta reescrita CLI: eu, com assistência de IA (consulte Nota sobre a autoria)

Uso legal e responsável

Esta ferramenta é publicada para educação e para testes de segurança autorizados — os seus próprios ambientes de laboratório, alvos de HTB/CTF, ou sistemas para os quais tem permissão escrita explícita para avaliar. O acesso não autorizado a sistemas informáticos é crime ao abrigo de leis como o Computer Misuse Act 1990 do Reino Unido, o Computer Fraud and Abuse Act dos EUA e equivalentes noutros países. É o único responsável pela forma como a utiliza. O autor não aceita qualquer responsabilidade por uso indevido ou por danos causados.

Licença

MIT