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

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

Guía Kevgir Parte (II)

Buenas tardes hackers, continuamos con la segunda parte y última de la PoC. En la anterior vimos de manera general los servicios disponibles en el servidor y la explotación del FTP y Tomcat.

NFS 2049
El NFS, es un servicio para poder compartir carpetas en la red. Mediante una llamada de procedimiento remoto RPC, se muestran los programas en equipos remotos con el comando rpcinfo. Si ejecutamos showmount, muestra la información de montaje en el servidor NFS. Montamos con mount el backup, previa creación de la carpeta en /tmp/nfs en la maquina victima y copiamos el .zip a nuestra maquina kali linux. 
De esta forma, mediante el servicio NFS, obtenemos un backup con información posiblemente muy útil. 

El archivo .zip se encuentra protegido con contraseña. Por tanto mediante un ataque por diccionario obtendremos dicha pass. Descomprimimos el archivo.

Usando grep, haremos una búsqueda recursiva de la password, en la carpeta html

JOOMLA 8081

Es un sistema de gestión de contenidos (CMS). Permite crear sitios dinámicos e interactivos. 
Con la consola de Metasploit, usando un auxiliar identificaremos la versión.

Haciendo uso de robots.txt, nos lista una serie de directorios de Joomla.

Hacemos nikto, para realizar un escaneo en busca de vulnerabilidades web

Como pueden observar, nikto es una potente herramienta que nos arroja información bastante útil para nuestra fase de pentesting.

Vista esta vulnerabilidad, ya podemos ir navegando en los distintos directorios! 
Pero antes de nada pasaremos un escaner para analizar las vulnerabilidades del CMS con joomscan.

Existen 19 vulnerabilidades encontradas. Explotaremos una de ellas Joomla Remote Admin Password Change Vulnerability.
Escribimos la URL que nos indica y en el campo token escribimos el siguiente carácter '. Una vez nos de la posibilidad de cambiar la contraseña, ya podremos acceder al panel de administración de Joomla. 

A partir de este momento, tenemos la posibilidad de modificar absolutamente todo del sitio web como administradores que somos. 
Desde la configuración global, podemos modificar por el ejemplo el nombre del sitio.

Configuración del sistema

En configuración del servidor, modificamos el media setting para permitir archivos PHP.

También nos arroja información de la existencia de una BBDD MySQL.

En Media Manager, creamos una carpeta para subir un script escrito en PHP, con el fin de ganar un shell

La subimos y el resultado es negativo, Possible IE XSS Attack found
Habrá que probar suerte con otro servicio, y "gaining access" con el mismo script PHP.


REDIS 6379
Redis es un motor de base de datos en memoria, basado en el almacenamiento en tablas de hashes (clave/valor) pero que opcionalmente puede ser usada como una base de datos persistente. Más información aquí

A través de Telnet, comprobamos si Redis tiene algún tipo de autenticación.

Bingo! No existe ningún tipo de seguridad.
Verificamos más información del sistema mediante el siguiente comando.

Mediante un auxiliar de Metasploit, podemos obtener más información del sistema

Usando otro auxiliar, podemos aprovechar la funcionalidad expuesta por Redis para lograr subir archivos. Quizás sea posible subir la shell escrita en PHP, anterior y así "gaining access". 

 

Mediante este método se ha podido subir la shell. A continuación lo único que habrá que hacer es interactuar con la URL y probar si nos devuelve el resultado tras la ejecución de los comandos.

El resultado es simplemente una shell de usuario en el navegador.



Jenkins 9000

Simplemente usando un auxiliar y un exploit en Metasploit, obtenemos el usuario y contraseña del login, y una sesión meterpreter. 

Ejecutamos el auxiliar

Login succesful admin:hello ;)

Ahora ejecutamos el siguiente exploit.

Con esto tendríamos una de las muchas shell conseguidas en esta PoC, con la diferencia que obtenemos en esta una sesión meterpreter. Una vez llegado a este punto podemos eejcutar una serie de opciones disponibles en meterpreter además de la shell de usuario obtenida.

Con esto, ya quedaría terminada esta pequeña guia sobre esta maquina vulnerable. No es complicada la explotación de este servidor, y sirve de práctica para nuevos iniciados en este mundo del pentesting para así seguir desarrollando vuestras habilidades como hackers.
Más adelante, se irán desarrollando más guías sobre nuevos retos que vayan surgiendo, para que sirva de ayuda para aquellos que quieran hacerla. 

Un saludo, naivenom.