lunes, noviembre 19, 2018

Joomla! in Paranoid Mode

Hace ya un par de años de que se convirtiera en realidad la idea inicial que tuvieron Chema Alonso y Pablo González de utilizar los triggers a nivel de tabla en la base de datos que utiliza WordPress para fortificar la plataforma. Aquella idea se convirtió en lo que se conoce como WordPress in Paranoid Mode, y hoy es utilizado por muchos administradores de WordPress que quieren tener listo su plataforma contra la oleada continua de ataques que sufre.

Figura 1: Joomla! in Paranoid Mode

Basado en la misma idea, yo realicé mi Proyecto de Fin de Grado como punto final de los estudios de Ingeniero en Tecnologías de Telecomunicación por la Universidad de Castilla La Mancha. Pero en lugar de aplicar esos conceptos a la fortificación de un WordPress, lo hice para una plataforma Joomla!, por lo que el proyecto se llama "Joomla! in Paranoid Mode".


Figura 2: Primera presentación de My WordPress in Paranoid Mode

Este proyecto responde a la necesidad de proveer una capa más de seguridad a los millones de sitios web desarrollados mediante el CMS Joomla!, aprovechando el uso de los triggers de la base de datos sobre la que se soporta la plataforma. Su funcionamiento es sencillo, ya que sobre la base de datos MySQL, crearemos una serie de triggers que se ejecutaran cuando se produzca una acción sobre las tablas seleccionadas, para consultar el estado de Latch, el gran protagonista en este proyecto. En función del estado, se podrá - o no - acceder a insertar, modificar o eliminar registros de la BBDD de dicho CMS.


Figura 3: Cómo poner Latch a las cuentas de usuario de Joomla!

El alcance de este desarrollo va mucho más allá que proteger nuestro sistema Joomla! a nivel de usuario con el plugin de Latch para Joomla! disponible en GitHub que permite poner un 2nd Factor Authorization, y que se explica en la Guía de Instalación de Latch para Joomla!.


En este proyecto de Joomla! in Paranoid Mode se trata de proteger el acceso a ciertas tablas de la BBDD del sistema a las cuales llamaremos Tablas Críticas aprovechando los triggers de MySQL. En base a estas Tablas Críticas configuraremos tres modos distintos de funcionamiento de la plataforma Joomla!, que serán Read-Only, Edition y Administration. Así pues este sería el esquema de las tablas de la BBDD asociadas a cada modo de funcionamiento:
- Modo Read-Only: Cuando el usuario marque que la plataforma Joomla! que tiene en producción está en modo Read-Only, quiere decir que los triggers de las Tablas Críticas de MySQL no permitirán la Inserción, Modificación o Borrado de ninguno de los registros del sistema, evitando que una vulnerabilidad de un plugin de la plataforma, o un fallo cualquiera a nivel de código de aplicación, pueda ser utilizado por un atacante para alterar el contenido del sistema. 
Solo con esta protección, el 90% de los ataques a plataformas Joomla! se ve eliminado. No se puede modificar, insertar o borrar ningún registro de las tablas que permiten la edición, como son: joomla_content, joomla_content_frontpage, joomla_redirect_links,  ni las necesarias para las tareas de administración, como joomla_users o joomla_extensions.
- Modo Edition: Este modo permitirá a los usuarios con permisos de edición cambiar el contenido y aspecto del sitio, pero no permitirá la gestión de usuarios o los cambios de extensiones en todo el sitio Joomla!, limitando el impacto que podría tener un ataque que requiriese un usuario con privilegios de edición, ya que las Tablas Críticas de usuarios o extensiones seguirían bloqueadas. No se permite acceso a las tablas de administración joomla_users o joomla_extensions.
- Modo Administration: Por último, el modo de administración se abriría solo cuando el administrador del sitio tuviera la necesidad de dar de alta nuevas cuentas o cambiar las extensiones de la plataforma, evitando así que esto esté disponible constantemente disponible para cualquiera que pueda ejecutar una inyección de comandos SQL Injection o una elevación de privilegios por un bug de código.
Cada vez que una consultad de Inserción Modificación o Borrado afecte a una de las Tablas Críticas, se consultará el estado de Latch con un trigger, y si está activado alguno de los modos que prohibe el nivel de acceso que requiere la operación, se bloqueará la operación aprovechando el nivel privilegiado que tienen los tiggers dentro de la BBDD. La estructura de los triggers es la siguiente.

Figura 5: Estructura los tiggers en Joomla! in Paranoid Mode

Los triggers se ejecutan tanto en las operaciones de Insert, como en Update y en Delete. Se puede observar cómo se llama al script desde Python que hace la consulta mediante las MySQL UDF, unas funciones creadas para extender las funcionalidades de MySQL y que nos sirve en este caso para invocar al código externo. Este script tendría la siguiente estructura:

Figura 6: Consulta de Latch desde script de Python

Los códigos APP_ID (Application ID) y SECRET se obtienen de la web de Latch al crear la aplicación que regirá el funcionamiento de ese Latch. El userid se obtiene en la respuesta de la API al realizar el pareado de la cuenta de usuario que va a manejar Joomla! in Paranoid Mode con el APP_ID de Latch que se va a utilizar para tal función. Como podemos ver hay dos tipos de respuesta, que como en cualquier otra aplicación o proceso "latcheado" tiene dos tipos de respuesta:

Figura 7: Intento de acceso a tabla bloqueada por el Modo de Joomla! in Paranoid Mode

Mediante este desarrollo podemos controlar de una manera más efectiva ataques de fuerza bruta a las contraseñas de los usuarios (con las opciones de 2nd Factor Authentication de Latch a nivel de usuario, y por la configuración del modo Read-Only), así como por ejemplo ataques de SQL Injection, que siguen siendo - año tras año - los ataques más usados por los atacantes, como se ve en el TOP 10 OWASP.

Figura 8: Ataques de inyección de comandos nº 1 en OWASP Top Ten

Una vez entregado el proyecto, este código será liberado para que cualquiera pueda aportar sus ideas para un mayor rendimiento y efectividad del mismo, pero para que entiendas todos los detalles, este miércoles 21 de Noviembre tienes la CodeTalk for Developer de Joomla! in Paranoid Mode donde cuento el proyecto completo.

Figura 9: 21 de Noviembre "Code Talk For Devs: Joomla! in Paranoid Mode"

No quisiera finalizar este artículo sin dar las gracias a mis tutores, Pablo González por parte de ElevenPaths y Marcos Fernández en la UCLM, por su interminable paciencia y apoyo. Gran parte de este proyecto les corresponde a ellos. Dar las gracias también a todo el equipo de ElevenPaths por confiar en mí para su realización.


Figura 10: Joomla! in Paranoid Mode

Actualización: Aquí os dejo un pequeño vídeo donde se puede ver cómo funciona lo explicado en este proyecto.

Autor: Mateo González Fernández

Referencias Joomla! & Latch

[GitHub] Plugin de Latch para Joomla!
[Paper] Guía de Instalación de Latch para Joomla!
[Vídeo] Cómo Proteger Joomla! con Latch en 10 minutos
[Vídeo] Cómo instalar Latch en Joomla! por WebEmpresa

Referencias WordPress in Paranoid Mode

[Libro] Máxima Seguridad en WordPress
[Libro] Hardening GNU/Linux
[GitHub] Plugin de Latch paraWordPress
[Paper] Guía de Instalación de Latch en WordPress
[Paper] WordPress in Paranoid Mode (Parte 1)
[Paper] WordPress in Paranoid Mode (Parte 2)
[Vídeo] Proteger WordPress con Latch
[Vídeo] Proteger WordPress con Latch Cloud TOTP
[Vídeo] My WordPress in Paranoid Mode (conferencia Chema Alonso)
[Vídeo] My WordPress in Paranoid Mode (ElevenPaths Talks de Pablo González)
[Vídeo] My WordPress in Paranoid Mode for Developers (CodeTalk for Devs)
[Vídeo] Ejemplo de uso de Latch en WordPress
[Vídeo] Hardening WordPress like a hacker
[Vídeo] WordPress Demo XSS en WP-UserAgent
[BlogPost] My WordPress in Paranoid Mode
[BlogPost] Máxima Seguridad en WordPress
[BlogPost] Hackear un WordPress con Network Packet Manipulation
[BlogPost] Fortificar comunicación entre WordPress y MySQL
[BlogPost] WordPress Latch Enforcement
[BlogPost] WordPress aún más seguro con Latch Lock After Request
[BlogPost] Fortificar WordPress frente a ataques de fuerza bruta
[BlogPost] Ataques (al corazón) de tu WordPress
[BlogPost] Cómo robarle las contraseñas a los administradores de WordPress
[BlogPost] Agrupar el control de varios WordPress con un solo Latch
[BlogPost] WordPress: Time-Based XSPA (Cross-Site Port Attack)
[BlogPost] Cómo debería ser un WordPress un poco más seguro
[BlogPost] WPHardening: Automatizar fortificación de WordPress
[BlogPost] Protege los borradores de los artículos de tu WordPress
[BlogPost] Registro de cuentas en WordPress públicos
[BlogPost] Riesgos en la ejecución de tareas de Cron
[BlogPost] WordPres: XSS en plugin WP-UserAgent
[BlogPost] Listar los plugins de WordPress en un pentest
[BlogPost] WordPress: SQL Injection en Scarcity Builder Plugin
[BlogPost] Docker WordPress in Paranoid Mode
[BlogPost] Faast for WordPress

No hay comentarios:

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares