Hace unos meses Chema Alonso y yo nos pusimos manos a la obra con una nuestras ideas locas para Configurar Wordpress in Paranoid Mode, dónde fuimos lo bastante locos para controlar con Latch las opciones que se podían hacer sobre la base de datos MySQL en una configuración de Wordress. El objetivo era sencillo y claro, y se trataba de configurar la base de datos que utiliza WordPress en distintos modos de funcionamiento detectacon cuando se hacían operaciones de inserción, de eliminación o modificación y en función del estado del modo configurado en Latch que protege cada tabla dejara que se haga la acción o bloquearla.

Figura 1: Configurar WebApps con MS SQL Server in Paranoid Mode usando Latch

Con esta forma de funcionar es posible evitar ataques de diversos tipos, que van desde inyecciones no deseadas en esquemas de Network Packet Manipulation, pasando por acciones hechas con cuentas robadas, hasta principalmente, los ataques de SQL Injection que se pudieran producir por un 0day en cualquiera de los plugins de WordPress. Para eso creamos un pequeña PoC llamada WPM (WordPress in Paranoid Mode), el cual podéis descargar desde el laboratorio de ElevenPaths.


Figura 2: My WordPress in Paranoid Mode
Pero si conocéis a Chema Alonso, ya sabéis que no iba a dejar las cosas a medio probar, así que liamos a varios compañeros más para probar si esta idea de poner un segundo factor de autorización a nivel de trigger lo podíamos exportar a otros entornos, así que primero con Rubén Alonso y luego con nuestro compañero Jhonattan Fiestas hicimos una variante que consistía en probar que el Paranoid Mode se podía llevar a cualquier WebApp que funcione sobre MS SQL Server.

Arrancando la PoC: Configuración inicial del Paranoid Mode

Para ver las posibilidades que teníamos de migrar el trabajo que hicimos en WordPress in Paranoid Mode y poder llevar el modo paranoico de cualquier WebApp a un servidor Microsoft SQL Server nuestro compañero Jhonattan Fiestas creó una pequeña aplicación como prueba de concepto. La aplicación no es nada especial, y es lanzada en local usando las credenciales de Microsoft Windows locales. El estado inicial, a modo de instantánea, de la base de datos a la que en un alarde de imaginación hemos denominado ‘MiBaseDeDatos’ es la que se puede ver en la imagen.

Figura 3: Configuración inicial de MiBaseDeDatos

En ella se puede ver como la base de datos está totalmente limpia, no hay tablas creadas, ni ensamblados cargados. Lo primero que vamos a tocar es el fichero ‘LatchForSQLServer.exe.config’ que tenemos creado para esta aplicación de prueba. Actualizaremos el fichero utilizando una cadena de conexión con autenticación Windows, tal y como se puede visualizar en el ejemplo.

Figura 4: Configuración de la cadena de conexión al motor de bases de datos

Ahora, desde el binario LatchForSQLServer.exe se puede iniciar la aplicación y ver el menú que se ha creado para la PoC de SQL Server in Paranoid Mode. En el menú, podemos ver diferentes acciones, como son la posibilidad de crear las tablas necesarias en la base de datos de ejemplo, la posibilidad de realizar el pareado con Latch, la creación de los triggers con toda la inteligencia y código necesario para poder consultar los estados de Latch y la posibilidad de realizar el despareado con Latch.

Figura 5: Menú de Latch for SQL Server

En primer lugar, crearemos tablas sobre la base de datos, por lo que debemos ejecutar la opción 1. Una vez realizada la operativa, se habrán creado un par de tablas: LatchSettings y LatchUse. Son en estas tablas dónde se tiene que completar la configuración de Latch. Para el ejemplo, se utiliza la configuración mostrada en imagen en la parte inferior.

Figura 6: Tablas LatchSettings y LatchUse

Como se puede ver, en LatchSettings creamos en formato tabla un registro con la información que se necesita para consultar el estado de las operaciones creadas. Es decir, es la configuración de la aplicación de Latch.

Figura 7: Configuración de LatchSettings

Primero es necesario, crear una  con una cuenta gratuita de desarrollador en Latch se crea una aplicación y se configura en un registro de esta tabla toda la información para consultar el estado en cada ocasión.

Figura 8: Aplicación creada en Latch

Para ello se ha definido una aplicación en Latch que tiene tres modos de funcionamiento. Modo Insert, Modo Delete y Modo Update. Desde la aplicación de Latch se podrá definir si se permite o se bloquea ese modo.

Figura 9: Modos controlados por este Paranoid Mode

En la tabla LatchUse, lo que se va a definir es el nombre de las tablas que estarán afectadas por cada uno de los modos controlados por las operaciones de Latch. Las tablas que aparezcan en cInsert se verán afectadas por la operación del Latch de Insert, en cUpdate la lista de qué tablas se verán afectadas por el estado de la operación de Latch en Update y en la columna cDelete las tablas que se verán afectadas por la operación Delete de Latch.

Poc: Pareado de cuentas

En primer lugar, ejecutamos la operación correspondiente en el menú de LatchForSQLServer, en este caso la Opción 2, y se nos solicitará un Token Temporal de Pareado que debemos obtener desde nuestra aplicación móvil de Latch. Una vez introducido el token y validado podremos

Figura 10: Pareado de Base de Datos en SQL Server con Latch

Aplicando triggers a las tablas

Antes de aplicar los triggers se han creado tres tablas con la misma estructura, denominadas mitabla, mitabla2 y mitabla3 - en otro alarde de imaginación -. Estas tablas son creadas para simular las tablas que pudiera tener cualquier WebApp, por ejemplo, en un sistema CMS, que haga uso de Microsoft SQL Server.

Figura 11: Tablas en LatchUse para cada modo

En la tabla LatchUse debe reflejarse la configuración de los triggers que se quieren aplicar y dónde se quieren aplicar. Tenemos una columna denominada cInsert, la cual contendrá todas las tablas sobre las que se quiere aplicar un trigger para las operaciones Insert. De manera similar tenemos los casos de cUpdate y cDelete como ya se ha explicado antes. En la imagen, se puede ver que vamos a aplicar lo siguiente:

• Trigger sobre la operación Insert sobre la tabla mitabla y mitabla3.
• Trigger sobre la operación Update sobre la tabla mitabla2.
• Trigger sobre la operación Delete sobre la tabla mitabla2 y mitabla3.

La aplicación leerá los datos de la tabla y entonces descartará los registros vacíos, nulos y duplicados. Cuando se ejecute en el menú de la aplicación la Opción 3, es decir, ‘Apply triggers’ los disparadores sobre las tablas de la WebApp se crearán.

Figura 12: Creación de triggers y ensamblados necesarios para consultar el estado de Latch

En primer lugar, se instalan las dependencias y, posteriormente, los triggers en las tablas que lo requieren. Ahora solo hace falta realizar dichas acciones sobre las tablas para comprobar el funcionamiento, y ver que si tenemos el Latch cerrado, no se pueden realizar operaciones sobre las tablas que están protegidas.

Figura 13: Operación de Insert bloqueada por Latch

Esta solo es una prueba de concpeto de cómo es posible introducir un Segundo Factor de Autorización a nivel de tablas usando triggers en SQL Server que permitirían configurar un Modo Paranoico en cualquier WebApp sobre este motor de base de datos.


En el vídeo se puede ver el funcionamiento de esta PoC, y si tienes interés en hacer algo similar, no dudes en contactar con nosotros en nuestra Comunidad de ElevenPaths, sección Latch.

Saludos!

Autores: Pablo González, Jhonattan Fiestas & Chema Alonso