Pentesting Moodle III - Hardening Moodle

Buenas compañeros,

Este post es la tercera 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.

Mientras que en la segunda parte Pentesting Moodle II - Desde dentro se tomo 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 con un nivel intermedio de privilegios).

En este caso, se basa en la parte más "defensiva" que se tiene que tener en cuenta si uno es administrador de Moodle y desea securizar su plataforma en la medida de lo posible para hacer más complicado la actividad a los "malos".

¡Vamos a ello!

El Hardening o securización es el proceso de asegurar un sistema mediante la reducción de posibles vulnerabilidades en el mismo. Para conseguir ese objetivo, se elimina software obsoleto, servicios, usuarios, actualizaciones, políticas de backup,… Innecesarios en el sistema así como cerrando puertos en el exterior en la medida de lo posible.

Es imprescindible revisar las políticas de seguridad del sitio web pues uno de los principales “agujeros” de los servidores web reside en la instalación por defecto, que es objetivo de los atacantes.

La gran mayoría de exploits se basan en explotar las vulnerabilidades que se detectan en frameworks, plataformas, versiones desactualizadas de programas,…que acompañan en las instalaciones por defecto.

Del mismo modo existen herramientas especializadas en explotar vulnerabilidades asociadas a la instalación por defecto, en este caso Moodle, como por ejemplo el fuzzing Flunym0us.

Por ello, es necesario revisar y modificar en caso necesario dichas políticas para mantener el sitio web lo más protegido posible.

En esta parte se toma el rol de administrador principal. Una vez autenticado, en administración del sitio en la pestaña de seguridad se tienen las siguientes ventanas:

-Políticas del sitio

En este apartado se enumeran el estado de las políticas de seguridad del sitio indicando su descripción y su configuración por defecto.

Como se observa, POR DEFECTO:

 - No se fuerza a los usuarios a loguearse en la aplicación para poder ver contenidos.

 - Opcionalmente, se permite recordar nombre de usuario.

 - No se bloquea la cuenta de usuario tras N intentos consecutivos fallidos de inicio de sesión.

 - Ejecución del script cron.php habilitado mediante vía web. En este caso, es imprescindible habilitar   la opción de ejecutarlo solamente por comandos desde el terminal del servidor, o al menos      establecer una contraseña para su ejecución vía web, pero existe el peligro de sufrir ataques de fuerza   bruta.

-Notificaciones

Analizando su configuración por defecto, se afirma que son correctas y cumplen el criterio de confidencialidad, por lo que no requieren ser modificadas.

-Bloqueador de IP

Posibilita bloquear direcciones IP que soliciten conexiones al servidor. Además permite añadir listas blancas de direcciones IP permitidas, así como la adición de blacklist de direcciones IP maliciosas.


Esta opción es muy útil contra blacklists conocidas y publicadas que pueden ser botnets.

-Seguridad HTTP

Se basa en la configuración HTTP. Posibilita introducir mejoras de seguridad como pueden ser: habilitar cifrado mediante el protocolo SSL/TLS a HTTP pasando a emplear HTTPS o el uso de flags para las cookies, como secure o HTTPOnly.

Para securizar las comunicaciones con el servidor es imprescindible habilitar HTTPS y adicionalmente emplear cookies con flags seguros, por lo que se requiere modificar la configuración por defecto de seguridad HTTP.

Adicionalmente para incrementar el nivel de seguridad del sitio, Moodle permite el uso de CAPTCHA en el proceso de autenticación y registro, así como la incorporación del antivirus Clam AV. En la configuración por defecto no se encuentran habilitados.

Para su habilitación se requieren del registro del sitio web en Moodle.org, así como la inclusión de claves para el CAPTCHA.

Configuración correcta de Moodle

De las opciones de seguridad anteriormente descritas y analizadas, requieren especial atención la configuración correcta algunas políticas del sitio y la seguridad HTTP.

A continuación se muestra una configuración correcta de las políticas mal configuradas que presenta la configuración por defecto que en el apartado anterior se han citado:


Habilitar “Forzar a los usuarios a autenticarse”: De esta manera ya no se permite el acceso a invitados (usuarios sin autenticar: null sesión).

Habilitar “Umbral de bloqueo de cuenta”: Entre 3 y 5 fallos consecutivos permitidos. Para esta configuración hay que aunar la usabilidad y la seguridad (los dos ámbitos tan peleados siempre) puesto que si se bloquean las cuentas de usuario durante un espacio temporal demasiado grande se puede generar una denegación de servicio (DoS) a nivel de usuarios.

Siendo el nuevo resultado del estado de la cuenta para un atacante que emplea fuerza bruta: el bloqueo.

Configurar ejecución de cron: Dos alternativas de mayor a menor seguridad.

-Sólo mediante comandos: Sólo desde el terminal del servidor o conexión SSH se permite la ejecución del script de mantenimiento cron.php. De las dos opciones, ésta es la alternativa más segura.

Siendo el resultado al acceder vía web:

-Ejecución de cron mediante acceso remoto con contraseña: No es la opción más recomendable debido a la criticidad del script. Sin embargo, es mejor opción a la establecida por la configuración por defecto. La seguridad del acceso al script radica en la fortaleza de la contraseña, por lo que no se debe elegir contraseñas típicas como admin, sino contraseñas complejas y robustas.

Siendo el resultado la acceder vía web:

Introduciendo una posible contraseña:

El hecho de establecer una contraseña incrementa la seguridad, sin embargo, como se ha podido observar en las opciones de configuración no se permite algún tipo de bloqueo (por ejemplo a nivel de IP) para prevenir ataques de fuerza bruta.

Adición de mecanismos de securización externos

En busca de mejorar la seguridad de la plataforma Moodle, se incorporan plugins como mecanismos de seguridad, ahora bien al ser extensiones externas hay que asegurarse que estén actualizadas y no contengan vulnerabilidades conocidas, pues sino en lugar de incrementar la securización del sitio, se estará abriendo una vía de ataque.

Como mecanismos de autenticación y gestión de cuentas de usuario se ha empleado el plugin Latch desarrollado por Eleven Paths.

Latch se basa en un factor de autenticación, controla cuándo es posible acceder a los servicios digitales a un usuario. Permite implementar un “pestillo” de seguridad, tal que se puede bloquear temporalmente funcionalidades del servicio como el mecanismo de inicio de sesión.

En este caso, Latch se emplea para controlar cuándo un usuario (administrador, profesor y alumno) pueden acceder a los servicios de la plataforma online Moodle, es decir, en el proceso de autenticación de tal manera que se añade un segundo factor de autenticación.

Para más información sobre descarga e instalación os dejo el vídeo tutorial de ElevanPaths: 

https://www.youtube.com/watch?v=EvxmAJ4SB3o 

Auditoría de securización

Tan importante es conocer las vulnerabilidades de un sistema como llevar a cabo una configuración importante de la configuración por defecto que presenta la mayoría de aplicaciones una vez son instaladas.

En este proyecto Moodle se encuentra implementado sobre el sistema operativo Linux. Como mecanismo de Hardening se emplea Lynis, que consiste en una herramienta muy completa encarga de realizar auditorías de sistemas Linux.


Para más información, os recomiendo revisar la entrada que se hizo en el blog anteriormente Lynis: Auditando la seguridad de tu Linux

Finalmente, os recomiendo la lectura de las recomendaciones de seguridad del equipo de Moodle (citar que las vulnerabilidades que esta plataforma tiene debido a la mala configuración por defecto ni las citan...)

https://docs.moodle.org/all/es/Recomendaciones_de_Seguridad 
https://docs.moodle.org/all/es/Seguridad

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

DoS con Slowloris.pl

Buenas hackers en esta PoC, os muestro esta genial herramienta que permite realizar un ataque de denegación de servicio a un servidor Linux. Esto genera que ese servicio sea inaccesible a los usuarios legítimos. En este caso mantiene conexiones abiertas el máximo tiempo posible a base del envío de peticiones http a una tasa de datos muy baja.. Para esta prueba de concepto se realizará en un entorno virtualizado controlado, usando una máquina atacante Kali Linux y un servidor Ubuntu como víctima.

Slowloris.pl esta escrita en perl y disponible en Github

Requirimientos y los pasos a seguir

How use Slowloris

Requirements:
# sudo apt-get update  
# sudo apt-get install perl
# sudo apt-get install libwww-mechanize-shell-perl
# sudo apt-get install perl-mechanize


1)Download slowloris.pl
2)Open Terminal
2)# cd /thePathToYourSlowloris.plFile
3)# ./slowloris.pl
4)# perl slowloris.pl -dns (Victim URL or IP) -options



Done


Laera Loris"

Documento de ayuda

TITLE
    Slowloris

VERSION
    Version 0.7 Beta

DATE
    06/17/2009

AUTHOR
    RSnake <h@ckers.org> with threading from John Kinsella

ABSTRACT
    Slowloris both helps identify the timeout windows of a HTTP server or
    Proxy server, can bypass httpready protection and ultimately performs a
    fairly low bandwidth denial of service. It has the added benefit of
    allowing the server to come back at any time (once the program is killed),
    and not spamming the logs excessively. It also keeps the load nice and low
    on the target server, so other vital processes don't die unexpectedly, or
    cause alarm to anyone who is logged into the server for other reasons.

AFFECTS
    Apache 1.x, Apache 2.x, dhttpd, GoAhead WebServer, others...?

NOT AFFECTED
    IIS6.0, IIS7.0, lighttpd, nginx, Cherokee, Squid, others...?

DESCRIPTION
    Slowloris is designed so that a single machine (probably a Linux/UNIX
    machine since Windows appears to limit how many sockets you can have open
    at any given time) can easily tie up a typical web server or proxy server
    by locking up all of it's threads as they patiently wait for more data.
    Some servers may have a smaller tolerance for timeouts than others, but
    Slowloris can compensate for that by customizing the timeouts. There is an
    added function to help you get started with finding the right sized
    timeouts as well.

    As a side note, Slowloris does not consume a lot of resources so modern
    operating systems don't have a need to start shutting down sockets when
    they come under attack, which actually in turn makes Slowloris better than
    a typical flooder in certain circumstances. Think of Slowloris as the HTTP
    equivalent of a SYN flood.

  Testing
    If the timeouts are completely unknown, Slowloris comes with a mode to
    help you get started in your testing:

   Testing Example:
    ./slowloris.pl -dns www.example.com -port 80 -test

    This won't give you a perfect number, but it should give you a pretty good
    guess as to where to shoot for. If you really must know the exact number,
    you may want to mess with the @times array (although I wouldn't suggest
    that unless you know what you're doing).
 

 HTTP DoS
    Once you find a timeout window, you can tune Slowloris to use certain
    timeout windows. For instance, if you know that the server has a timeout
    of 3000 seconds, but the the connection is fairly latent you may want to
    make the timeout window 2000 seconds and increase the TCP timeout to 5
    seconds. The following example uses 500 sockets. Most average Apache
    servers, for instance, tend to fall down between 400-600 sockets with a
    default configuration. Some are less than 300. The smaller the timeout the
    faster you will consume all the available resources as other sockets that
    are in use become available - this would be solved by threading, but
    that's for a future revision. The closer you can get to the exact number
    of sockets, the better, because that will reduce the amount of tries (and
    associated bandwidth) that Slowloris will make to be successful. Slowloris
    has no way to identify if it's successful or not though.

   HTTP DoS Example:
    ./slowloris.pl -dns www.example.com -port 80 -timeout 2000 -num 500 -tcpto
    5

  HTTPReady Bypass
    HTTPReady only follows certain rules so with a switch Slowloris can bypass
    HTTPReady by sending the attack as a POST verses a GET or HEAD request
    with the -httpready switch.

   HTTPReady Bypass Example
    ./slowloris.pl -dns www.example.com -port 80 -timeout 2000 -num 500 -tcpto
    5 -httpready
 

  Stealth Host DoS
    If you know the server has multiple webservers running on it in virtual
    hosts, you can send the attack to a seperate virtual host using the -shost
    variable. This way the logs that are created will go to a different
    virtual host log file, but only if they are kept separately.

   Stealth Host DoS Example:
    ./slowloris.pl -dns www.example.com -port 80 -timeout 30 -num 500 -tcpto 1
    -shost www.virtualhost.com

  HTTPS DoS
    Slowloris does support SSL/TLS on an experimental basis with the -https
    switch. The usefulness of this particular option has not been thoroughly
    tested, and in fact has not proved to be particularly effective in the
    very few tests I performed during the early phases of development. Your
    mileage may vary.

   HTTPS DoS Example:
    ./slowloris.pl -dns www.example.com -port 443 -timeout 30 -num 500 -https

  HTTP Cache
    Slowloris does support cache avoidance on an experimental basis with the
    -cache switch. Some caching servers may look at the request path part of
    the header, but by sending different requests each time you can abuse more
    resources. The usefulness of this particular option has not been
    thoroughly tested. Your mileage may vary.

   HTTP Cache Example:
    ./slowloris.pl -dns www.example.com -port 80 -timeout 30 -num 500 -cache

Issues
    Slowloris is known to not work on several servers found in the NOT
    AFFECTED section above and through Netscalar devices, in it's current
    incarnation. They may be ways around this, but not in this version at this
    time. Most likely most anti-DDoS and load balancers won't be thwarted by
    Slowloris, unless Slowloris is extremely distrubted, although only
    Netscalar has been tested.

    Slowloris isn't completely quiet either, because it can't be. Firstly, it
    does send out quite a few packets (although far far less than a typical
    GET request flooder). So it's not invisible if the traffic to the site is
    typically fairly low. On higher traffic sites it will unlikely that it is
    noticed in the log files - although you may have trouble taking down a
    larger site with just one machine, depending on their architecture.

    For some reason Slowloris works way better if run from a *Nix box than
    from Windows. I would guess that it's probably to do with the fact that
    Windows limits the amount of open sockets you can have at once to a fairly
    small number. If you find that you can't open any more ports than ~130 or
    so on any server you test - you're probably running into this "feature" of
    modern operating systems. Either way, this program seems to work best if
    run from FreeBSD.

    Once you stop the DoS all the sockets will naturally close with a flurry
    of RST and FIN packets, at which time the web server or proxy server will
    write to it's logs with a lot of 400 (Bad Request) errors. So while the
    sockets remain open, you won't be in the logs, but once the sockets close
    you'll have quite a few entries all lined up next to one another. You will
    probably be easy to find if anyone is looking at their logs at that point
    - although the DoS will be over by that point too.

What is a slow loris?
    What exactly is a slow loris? It's an extremely cute but endangered mammal
    that happens to also be poisonous. Check this out:

    http://www.youtube.com/watch?v=rLdQ3UhLoD4

Proof of concept 

Un saludo Naivenom