Cómo explotar DRUPAL-SA-CORE-2012-003

2

He leído los avisos de seguridad y entiendo que "permitiría a un atacante reinstalar un sitio de Drupal existente con una base de datos externa. servidor y luego ejecutar código PHP personalizado ". Según Drupal, "la reinstalación solo puede tener éxito si el archivo settings.php del sitio o los directorios del sitio son de escritura o de propiedad del usuario del servidor web".

Traté de buscar una mejor explicación en Google sobre cómo un atacante explotaría el archivo install.php pero no pudo encontrar ninguna. Entiendo que hay un parche y algunas soluciones rápidas como las siguientes;

<Files install.php>
  Order allow,deny
  ErrorDocument 403 "Access denied."
</Files>

Pero lo que quiero saber, ¿cuál es el proceso para explotar DRUPAL-SA-CORE-2012-003?

(Desearía que un ejemplo operativo pudiera ejecutarse en mi sitio de prueba)

    
pregunta Digital fire 18.10.2012 - 17:19
fuente

3 respuestas

4

He comprobado el código real y he reproducido el exploit. Además de todas las condiciones mencionadas, se debe llamar a install.php cuando la base de datos actual que está configurada en settings.php no está disponible.

Para aprovechar la vulnerabilidad, el atacante debe realizar de alguna manera una Denegación de Servicio para el servidor de la base de datos. Por ejemplo, puede enviar múltiples solicitudes simultáneas al sitio. Estos se conectarían a la base de datos, posiblemente alcanzando los límites de la base de datos (por ejemplo, MySQL ' max_user_connections ' ). Dentro de esa ventana de tiempo limitada, el atacante debe iniciar el nuevo proceso de instalación (que sobrescribiría settings.php con los detalles de la base de datos elegidos por el atacante).

    
respondido por el Krzysztof Kotowicz 19.10.2012 - 22:59
fuente
2

Es bastante simple, de verdad. Si install.php es accesible y settings.php se puede escribir en el demonio HTTP (por ejemplo, Apache), un atacante puede simplemente ir a install.php y reinstalar Drupal a través del método de instalación normal. Esto sobrescribe settings.php y le da al atacante acceso completo a su instalación.

No lo he comprobado, pero también puede eliminar y volver a crear todas las tablas de la base de datos, lo que puede ser bueno o malo dependiendo de cómo se vea. Es bueno en el sentido de que el atacante perdería las credenciales en la tabla de usuarios, y malo en el sentido de que eliminaría todos sus datos.

    
respondido por el Polynomial 18.10.2012 - 17:37
fuente
2

Hay varios problemas con el instalador:

  • El instalador puede reutilizarse cuando la base de datos está inactiva (no cuando está arriba, como en Polinomios)
  • El instalador puede reutilizarse en ciertas configuraciones multisitio
  • El instalador puede reutilizarse cuando la base de datos está obligada a cometer errores cuando las solicitudes se ejecutan para ejecutar las tareas de la base de datos.

Consulte también enlace

    
respondido por el Heine 26.10.2012 - 07:53
fuente

Lea otras preguntas en las etiquetas