nayem-m/drupalgeddon2-cliReescritura en CLI del PoC de Drupalgeddon2 (CVE-2018-7600), para pruebas/educación autorizadas.
Una reescritura en línea de comandos del proof-of-concept de Drupalgeddon2 (CVE-2018-7600), construida como ejercicio de estudio mientras trabajaba en el módulo Attacking Common Applications de Hack The Box Academy.
[!WARNING] Solo para pruebas de seguridad autorizadas y educación. Ejecutar esto contra sistemas que no posees o para los que no tienes permiso explícito por escrito es ilegal en la mayoría de las jurisdicciones. Consulta Uso legal y responsable.
[!NOTE] Implementación escrita con asistencia de IA. Consulta Una nota sobre la autoría.
Drupal es una de las "aplicaciones comunes" cubiertas en el módulo Attacking Common Applications de HTB Academy, y CVE-2018-7600 ("Drupalgeddon2") es el ejemplo canónico de RCE no autenticado para dicho módulo. En lugar de copiar y pegar un script de un solo uso y seguir adelante, quería entender realmente la inyección de Form API que hace funcionar el fallo, así que reconstruí el PoC público desde cero como ejercicio de aprendizaje.
El original ampliamente referenciado, a2u/CVE-2018-7600 de Vitalii Rudnykh, es excelente para demostrar el fallo, pero requiere editar el payload in situ en cada ejecución. En un flujo de trabajo de laboratorio/CTF —re-ejecutando contra distintos objetivos, queriendo un punto de apoyo repetible— eso se vuelve tedioso. Esta versión lo convierte en una herramienta CLI adecuada:
cmd= predecible abierta detrás de tiEstá deliberadamente limitado a una vulnerabilidad conocida y parcheada hace tiempo (divulgada en 2018). El objetivo era comprender la técnica y producir una implementación de referencia limpia y documentada — no una capacidad ofensiva novedosa.
El código de este repositorio fue escrito con asistencia de IA (Claude de Anthropic) mientras trabajaba en el módulo de HTB. Yo establecí los objetivos de diseño y los requisitos — ergonomía CLI, despliegue automático del web shell, modo interactivo, nombre del shell y parámetro aleatorizados — y revisé y probé el resultado. Lo divulgo porque es lo honesto, y porque el valor aquí está en la comprensión y en las decisiones de ingeniería, más que en la autoría de cada línea.
--cmd, o entrar en un pseudo-shell interactivo con --shell.CVE-2018-7600 afecta a:
Esta implementación apunta al vector de Form API de Drupal 8 (el endpoint AJAX user/register). Drupal 7 es explotable a través de un endpoint/payload diferente y no se maneja aquí.
Las versiones parcheadas (7.58 / 8.5.1 y posteriores) no están afectadas.
requestspip install requests
# comando de una sola vez
python3 drupalgeddon2.py -u http://target/ -c id
# pseudo-shell interactivo
python3 drupalgeddon2.py -u http://target/ --shell
# solo plantar el shell, no ejecutar nada
python3 drupalgeddon2.py -u http://target/ --deploy-only
# enrutar a través de Burp, ignorar el certificado autofirmado del proxy
python3 drupalgeddon2.py -u http://target/ -c id --proxy http://127.0.0.1:8080 -k
| Flag | Descripción |
|---|---|
-u, --url | (obligatorio) URL base del objetivo, p. ej. http://target/ |
-c, --cmd | Comando único a ejecutar en el objetivo |
--shell | Entrar en un pseudo-shell interactivo |
--deploy-only | Solo plantar el web shell, no ejecutar nada |
--shell-name | Nombre de archivo para el shell plantado (por defecto: .php aleatorio) |
--param | Nombre del parámetro GET para el shell (por defecto: md5 aleatorio) |
--proxy | URL del proxy, p. ej. http://127.0.0.1:8080 |
-k, --insecure | Deshabilitar la verificación TLS (para certificados de proxy autofirmados) |
--timeout | Tiempo de espera por petición en segundos (por defecto: 15) |
CVE-2018-7600 es un fallo de saneamiento de entradas en la Form API de Drupal. Drupal representa los formularios como arrays renderizables anidados, y las claves de array que comienzan con # se tratan como propiedades de render especiales, no como datos de usuario. El parche (SA-CORE-2018-002) añadió saneamiento para eliminar esas claves con prefijo # de las entradas proporcionadas por el usuario.
Antes del parche, un atacante no autenticado podía inyectar propiedades de render en un elemento de formulario que es procesado por el manejador AJAX de Drupal. Enviar propiedades como:
#post_render — una lista de callables que Drupal invoca después del renderizado, y#markup — el argumento que se les pasacontra el elemento mail del formulario de registro de usuario hace que Drupal llame a una función PHP arbitraria (aquí, exec) con entradas controladas por el atacante durante el paso de renderizado — es decir, ejecución remota de código, sin necesidad de autenticación.
Este PoC utiliza esa primitiva para codificar en base64 un shell PHP de una línea localmente, hacer que el servidor lo decodifique a un archivo en la webroot, y luego interactuar con ese archivo mediante peticiones GET normales.
Si estás en el lado defensor de esto:
Remediación
Ideas de detección
#post_render, #markup, #type, #lazy_builder, etc. Los envíos de formularios legítimos no las contienen.…/user/register?element_parents=…&_wrapper_format=drupal_ajax que lleven parámetros sospechosos..php recién creado en la webroot.system($_GET[...])).Esta herramienta se publica con fines educativos y para pruebas de seguridad autorizadas — tus propios entornos de laboratorio, objetivos HTB/CTF, o sistemas que tengas permiso explícito por escrito para evaluar. El acceso no autorizado a sistemas informáticos es un delito según leyes como la UK Computer Misuse Act 1990, la US Computer Fraud and Abuse Act y sus equivalentes en otros lugares. Eres el único responsable del uso que hagas de ella. El autor no acepta ninguna responsabilidad por mal uso o por cualquier daño causado.
MIT