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
