Pentesting Moodle II - Desde dentro

Buenas compañeros,

Este post es la segunda parte de la entrada Pentesting Moodle relacionado con la investigación que hice en mi trabajo de fin de grado. En la primera parte Pentesting con Moodle I - Desde fuera el pentesting se basó en un enfoque de caja negra, es decir, sin tener ningún tipo de conocimiento emulando el rol de un posible atacante.

En este caso, se va a enfocar el rol de caja blanca o caja negra con acceso a la parte privada de la aplicación web con mínimos privilegios, es decir, se está emulando el rol de un alumno o de un profesor (una cuenta cuenta con un nivel intermedio de privilegios).

Vamos al lío!

Enumeración de usuarios

Nuevamente dentro de la aplicación es posible realizar una enumeración de usuarios. Entrando en el perfil del usuario que se tiene en la url se pueda observar un id= X

De esta manera, se puede deducir que el usuario actual tiene el id = 4, por lo tanto, si se va variando a el valor del id, se podría ir accediendo a los perfiles públicos de los diferentes usuarios que estén en la plataforma registrados.

Tras realizar un par de posibles enumeraciones se observan los siguientes resultados:

Usuario registrado pero no se tiene acceso (controles de autorización)  Esto es debido a dos motivos: alumno registrado en un curso diferente del actual o por ser un usuario con privilegios (administrador o profesor de otros cursos).

Usuario no registrado: ID no asociado a ningún usuario.

Usuario con permisos accesible: Se está accediendo al perfil de un profesor que está matriculado en nuestro curso, de ahí que se pueda visualizar su perfil así como conocer el id que tiene asociado en la plataforma que es una información útil para posibles intentos de intrusión.

Además Moodle está permitiendo la visualización de un listado de los usuarios matriculados en un curso (tanto profesor/es como alumnos) con datos interesantes como los correos electrónicos para posibles campañas de phishing.

Esta información puede ser utilizada para atacar la aplicación web, por ejemplo, a través de un ataque de fuerza bruta o un ataque de usuarios/contraseñas predeterminadas.

Con la información recolectada se podría crear un diccionario personalizado con la combinación de nombre y apellidos, o a través de partes del nombre de la aplicación o cualquier otro dato significante a través de la información obtenida en su perfil, una vez que se sabe que está registrado en la aplicación.

Incorrecta configuración de seguridad

Esta vulnerabilidad es bastante peculiar...Los que habéis tenido que hacer algún examen a través de Moodle seguro que os hubiera gustado poder parar el contador del examen o incluso suprimirlo...pues resulta que es posible...

Adquiriendo el rol de alumno que se dispone a realizar un test que tiene un tiempo de duración limitada.

Sabiendo que el contador de tiempo se encuentra implementado con JavaScript, se realiza como prueba de concepto la deshabilitación de JavaScript empleando el complemento de Firefox Mozilla, NoScript. De tal manera, que se obtiene como resultado saltarse la duración por tiempo limitado para la realización del test.

Mientras que deshabilitando JavaScript desaparece el contador del tiempo para finalizar el test. El aspecto para la realización del test es el siguiente:

Cross Site Scripting (XSS) almacenado

Verificando la posibilidad de XSS almacenado en los test correspondiente al módulo quiz. Adquiriendo el rol de profesor (con permisos de edición) quien tiene la capacidad de poder editar un curso para añadir foros, exámenes, noticias,…se verifica que es vulnerable a XSS.

Citar que los compañeros de @FluProject, desarrollaron una herramienta llamado Flunym0us  para enumerar plugins de Moodle.

Como prueba de concepto se introduce código JavaScript tanto en el contenido de la pregunta como en la retroalimentación de la pregunta. Esto es posible pues permite el uso de HTML en el contenido tanto de la pregunta del test como en la retroalimentación del mismo.

<𝑠𝑐𝑟𝑖𝑝𝑡>𝑎𝑙𝑒𝑟𝑡(‘𝑉𝑢𝑙𝑛𝑒𝑟𝑎𝑏𝑙𝑒 𝑋𝑆𝑆’)</𝑠𝑐𝑟𝑖𝑝𝑡>

De tal manera que nada más iniciar el examen cuando se muestra la primera pregunta aparece el alert:

Análogamente tomando el rol de profesor, añadiendo el recurso “Página” es posible explotar la vulnerabilidad XSS en la descripción y/o contenido de la página al posibilitar introducir código HTML.

 De esta manera se inyecta código JavaScript y al no existir mecanismos de protección anti-XSS en este recurso se posibilita explotar la vulnerabilidad. Inyectando el código:

<𝑠𝑐𝑟𝑖𝑝𝑡 𝑡𝑦𝑝𝑒 =”𝑡𝑒𝑥𝑡/𝑗𝑎𝑣𝑎𝑠𝑐𝑟𝑖𝑝𝑡”>𝑎𝑙𝑒𝑟𝑡(𝑑𝑜𝑐𝑢𝑚𝑒𝑛𝑡.𝑐𝑜𝑜𝑘𝑖𝑒)</𝑠𝑐𝑟𝑖𝑝𝑡>

Se consigue visualizar la cookie del usuario que accede al recurso como se muestra en la siguiente figura:

En las diferentes entradas del blog, se han desarrollando pruebas de concepto de los riegos de un XSS y como explotarlos: phishing manual explotando xss y automatizando  vulnerabilidades xss con beEF

Exposición de información sensible

Existe una exposición de información debido a un incorrecto control de autorización desde el exterior, esto es, un usuario sin estar logueado en la plataforma podría acceder a información sensible desde el exterior a través de rutas predecibles o fáciles de descubrir empleando herramientas como dirbuster.

Acceso README.txt:

Como ya se detalló en el post anterior, el acceso al fichero README.txt desvela información sensible como la ruta para ejecutar el script cron.php

Listing herramientas del panel de administrador:

Se puede acceder al listado de directorios de las herramientas disponibles por el administrador:

Acceso documento explicativo de cookies:

A su vez, es posible acceder a través de la URL a un fichero que explica las cookies que soportan y su uso:

Errores y excepciones no controladas:

Numerosos errores y excepciones no controladas que facilitan el conocimiento de información como son los parámetros que esperan recibir.

Citar que las pruebas que se han mostrador se han realizado 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.


Espero que os haya gustado :) ¡Para cualquier cosa, usad el apartado de comentarios!

La mejor defensa es un buen ataque.

NaxHack5