Pentesting Moodle - Parte I Desde fuera

Buenas compañeros,

Este post inicia una serie de entradas sobre Moodle, sobre el que hice mi trabajo de fin de carrera y quería mostraros un par de detalles que saqué en su día.

En esta primera entrada os voy a mostrar un par de vulnerabilidades web que posee esta plataforma. Para comenzar Moodle es un CMS, que es un gestor de contenidos multimedia que facilita la gestión de contenido dinámico en un servidor web. La verdad es que como todos los demás CMS como Drupal, Wordpress o Joomla, se han publicado numerosas vulnerabilidades durante su desarrollo (https://www.cvedetails.com/product/3590/Moodle-Moodle.html?vendor_id=2105)

Moodle es muy empleado en universidades,centros de estudio y academias, pues se basa en una plataforma web online para la gestión de contenido que facilita la interacción entre profesor y alumnos.

En primer lugar, citar que las pruebas que se van a mostrar se realizarán en entornos controlados y virtuales, por lo que la finalidad de esta entrada es con fines educativas y formativos, no nos hacemos responsables de uso para otro fin.

Las vulnerabilidades que se van a mostrar se corresponden con Moodle 2.6.3 que a pesar de estar desactualizado ( el día que hice la auditoría la última version estable era la 2.7.3), todavía se encuentra muy empleado hoy en día.

Para realizar las pruebas en un entorno seguro os invito a que os instaléis Moodle en un SSOO Linux manualmente (así jugáis!) apoyándoos en la documentación de Moodle (https://docs.moodle.org/26/en/Step-by-step_Installation_Guide_for_Ubuntu) aunque también podéis emplear el gestor AMPPS (http://www.ampps.com/downloads)  que lo tiene preinstalado y con tan sólo clicar en instalar lo tenéis corriendo...para gustos los colores!

Adquiriendo un enfoque de caja negra, es decir, sin ningún conocimiento del sitio web.

Denegación de servicio (DoS)

Accediendo al típico README.txt que se suele encontrar accesible desde el exterior, se puede observar que muestra rutas interesantes como la existencia de un script llamado cron.php, basado en realizar tareas de limpieza y mantenimiento.

Por lo tanto, como podéis deducir había que probar a entrar a esa ruta a ver si estaba accesible desde el exterior por supuesto... Y efectivamente estaba accesible, pudiendo observar que se ejecuta dicho script y llama la atención que en función de cómo esté de cargado ( número de cursos, alumnos de alto, material subido en la aplicación) el servidor tarda más o menos consumiendo una cantidad de RAM considerable.

Esto me hice pensar como uno de los "malos", ¿ Y si creó un script para realizar N peticiones cada X segundos a la url de tal manera que se ejecute el script constantemente y no paré de consumir memoria RAM?

Antes de lanzar el script, entré dos o tres veces de manera consecutiva y par mi sorpresa...efectivamente "petó" el servidor web quedándose sin memoria y dejar de estar accesible provocando un ataque de denegación de servicio.

Aunque ya se verá más adelante en detalle, adelanto que esta vulnerabilidad se puede corregir en la configuración de Moodle pudiendo evitar el acceso vía web a la url y así evitar la ejecución del script, sin embargo, por defecto no viene seleccionado.

Cabe destacar que esta vulnerabilidad fue reportad en su día al equipo de seguridad de Moodle, teniendo como respuesta:

"Web CLI cron has been disabled by default since 2.9,"

Por lo tanto, le comenté que las versiones anteriores, seguían con esta vulnerabilidad debido a la configuración por defecto...sin embargo, citan:

"There is not a huge risk and cron is designed to be run very frequently anyway "

 Lo cual como se ha mostrado anteriormente parece que no es así...

Enumeración de usuarios

Esta vulnerabilidad se basa en identificar posibles nombres de usuarios registrados en la aplicación interaccionando con la lógica de la misma. Esta vulnerabilidad suele encontrarse en un gran números de aplicaciones web.

El proceso de reseteo de contraseña ofrece dos posibilidades para reestablecer la contraseña, ya sea introduciendo el nombre de usuario o bien mediante la dirección de correo con la que se registró el usuario.

Examinando la funcionalidad de la opción de resetear la contraseña mediante nombre de usuario, la aplicación devuelve dos tipos de mensajes en función de si existe una cuenta que emplee el nombre de usuario introducido.

Como prueba de concepto se introducen nombre de típicos de usuarios estándar recién creados: admin, administrador, profesor, profe, alumno,…

A continuación empleando diccionarios del ámbito de cualquier plataforma learning se detecta que el mensaje varía facilitando una enumeración de cuentas válidas en la aplicación a través de sus nombres de usuarios.

Por lo tanto, en función de la existencia del nombre de usuario en la aplicación devuelve las siguientes respuestas:

Usuario no existente:

Usuario existente:

De esta manera, se puede conseguir una enumeración de usuarios válido en el sistema. Además si se tiene algún pdf o recurso ofimático accesible desde el exterior, se podrían extraer los metadatos y si hay suerte obtener usuarios, tal que se podría probar la existencia de los mismos.

Como se ha indicado anteriormente, el contenido de esta entrada es para fines educativos y formativos, ¡no seáis malos!

Ante cualquier cosa, comentad en el apartado de comentarios y estaré encantado de responder.

Saludos.

NaxHack5

La mejor defensa es un buen ataque