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: