Cómo convertirse en Tripulante Aéreo Autorizado con un SQL Injection Level 1 (y saltarse las colas de seguridad de los aeropuertos)

Las técnicas de SQL Injection fueron descubiertas en 1998. El 25 de Diciembre de 1998 el investigador rfp (rain.forest.puppy) publicaba el famoso ezine en el que hablaba de cómo se podía saltar la seguridad de una aplicación web que validaba usuarios contra una tabla en una base de datos usando consultas SQL con cadenas de texto concatenadas. Acababa de nacer el fallo de seguridad que más impacto ha tenido en la historia de la seguridad web desde que nació la Web.

Figura 1: Cómo convertirse en Tripulante Aéreo Autorizado con un

SQL Injection Level 1 (y saltarse las colas de seguridad de los aeropuertos)

Yo le dediqué años de estudio a las técnicas de SQL Injection, di muchas charlas, publiqué muchos artículos, fueron parte de mi trabajo de doctorado, y acabamos publicando un libro con todo esto que a día de hoy sigue siendo uno de los más vendidos, quizá porque sigue siendo fundamental para un pentester o un developer conocer estas técnicas y sus riesgos.

Figura 2: Libro Hacking de Aplicaciones Web "SQL Injection" 4ª Edición

de Enrique Rando, Chema Alonso y Pablo González en 0xWord

Hoy en día no es tan fácil encontrar estas vulnerabilidades como lo fue hasta el año 2010, donde saber SQL Injection era equivalente a tener siempre comodines en la manga. Aparecía en cualquier sitio. Un SQL Injection, un Blind SQL Injection, uno de errores ODBC, un Remote File Downloading, un Time-Based Blind SQL Injection, un Arithmetic Blind SQL Injection. 

Figura 3: NT Web Technology Vulnerabilitys de rfp

(en la Wayback Machine)

Recuerdo jugar con la web de mis admirados Fernando Alonso y Pedro de la Rosa que tenían unos bonitos SQL Injection en sus páginas web, pero podría enumeraros centenares de ellas que aún tengo en mi cabeza. Una de las veces, en el año 2009, fui invitado a ir a la Yahoo! Security Week a dar una charla de Web Security a los Paranoids de Yahoo! Allí Palako y yo hicimos Live-demos de SQL Injection hasta que recibimos un mensaje en papel que ponía: "Please, no more non-Yahoo! sites live demos". Era tan fácil, estaba por tantos sitios, que casi podías hacer lo que quisieras en cualquier página web del mundo. Si es que servía hasta para ligar.

Bypassing airport security via SQL injection 

Hoy en día, 26 años después, a mí me gusta aún, de vez en cuando, echar un ojo y buscar algún sitio que aún tenga estos bugs clásicos, para ver si siguen existiendo y para sentir que he rejuvenecido y he vuelto a tener 25 años y estoy haciendo un pentest a una web. Busco alguno, lo reporto, y luego publico un post de eso por aquí. Es mi pasión, qué os puedo decir que no sepáis ya.

Figura 4: La plataforma para autorizar KCM

Pero parece que no se han erradicado del todo, y dos investigadores, Ian Carroll y Sam Curry, han encontrado un SQL Injection de libro, Level 1, en la web que controla el sistema de autorización de los Known Crewmembers (KCM) o tripulantes conocidos de las compañías aéreas, que tienen cola de acceso priorizada en los aeropuertos americanos gestionados por la TSA (Transportation Security Administration).

Figura 5: Login con SQL Injection Level 1

El sistema de administración es un portal web de acceso púbico sin VPN, sin Passkeys, sin 2FA, sin control de mensajes de error, sin control de cuentas privilegiadas, sin WAF, y con un SQL Injection de libro que permitía poner un 'or '1'='1  y tener un bonito acceso al panel de administración para poder ver los nombres de usuario y las credenciales, en hash MD5, de todos los usuarios de los sistema, además de los datos de todos los tripulantes. Ahí, ¡a lo loco!

Figura 6: Administración de los KCM

Pero por supuesto, lo mejor es que te podías dar de alta como KCM dentro de la plataforma, y luego, siguiendo las reglas de los KCM acceder a esas colas en todos los aeropuertos americanos gestionados por la TSA.

Figura 7: Prueba de acceso de un nuevo KCM

¿Os acordáis de la famosa película de "Catch me if you can" de Leonardo di Caprio con la escena en la que accede a los aeropuertos vestido de piloto para ir de un lugar a otro? Pues con un SQL Injection de Level 1, hasta mediados de 2024 era así de sencillo. 

Figura 8: Reglas de acceso para los KCM

(lo de las azafatas de la película es opcional)

Hoy en día el bug ha sido corregido, que los investigadores han hecho Responsible Disclosure. Pero no me digáis que no es una historia que te hace caer una lagrimilla al ver ese SQL Injection.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Nuestro nuevo "viejo" libro de Hacking de Aplicaciones Web: SQL Injection 4ª Edición ya disponible

Algunos de los libros que publicamos en 0xWord se han convertido ya en compañeros de viaje de toda mi vida. Libros como Pentesting con FOCA, Hacking Web Technologies, Metasploit para Pentesters, Ataques en redes de datos IPv4 & IPv6, Pentesting con Kali Linux, Máxima Seguridad en Windows o Ethical Hacking, llevan miles y miles de ejemplares vendidos y han servido como parte del material de formación de centenares de cursos. Son libros que cuidamos y, edición tras edición intentamos mejorar, corregir, y dejar actualizado. Y entre ellos está el que hoy sacamos la 4ª Edición. El libro de Hacking de Aplicaciones Web: SQL Injection.

Figura 1: Nuestro nuevo "viejo" libro de Hacking de Aplicaciones Web: SQL Injection 4ª Edición ya disponible

Este libro, que sacamos entre Enrique Rando y yo hace ya una década, lo hemos ido actualizando, con la colaboración de Pablo González, para que siga estando de actualidad y los nuevos pentesters que quieran entrar en este mundo puedan estudiar y aprender con él. Son más de 4.000 ejemplares de este texto que hacemos con tanto cariño.

Figura 2: Libro Hacking de Aplicaciones Web "SQL Injection" 4ª Edición

de Enrique Rando, Chema Alonso y Pablo González en 0xWord

El contenido sigue teniendo la misma base que tenía desde la primera edición, pero con cambios y correcciones - algunas aportadas por los lectores - para hacer más entendibles, reparar un error, o añadir una pequeña explicación extra que deje más claro un concepto que no quedaba claro. 

Figura 3: Índice del libro "Hacking Aplicaciones Web: SQL Injection 4ª Edición"

Y, para entender mejor el objetivo de lo que cuenta el libro, las palabras de Enrique Rando presentándolo en  su descripción:

Si fuera preciso explicar qué es un programa a alguien que no conociera nada en absoluto sobre el tema, quizá habría que comenzar indicándole que es "algo muy complejo". Algo que, aunque no lo parezca, hace muchas cosas y se relaciona con muchas otras componentes para realizar su trabajo. Algo que obedece ciegamente y al pie de la letra las instrucciones de su autor. Y algo a lo que no le preocupan las consecuencias de sus actos.  

 

Complejidad. Ésa es la clave. 

Tanto en el producto como en el proceso de elaboración. Miles de líneas de código. Algoritmos complicados. Entornos de ejecución cambiantes. Presiones para entregar el producto en una determinada fecha. Escasez de medios humanos, materiales y técnicos... Pero esto es sólo el principio: después viene la puesta en producción y su posible exposición al mundo exterior. Un mundo que también es complejo. 

Visto lo visto, no es de extrañar que los programas contengan fallos, errores, que, bajo determinadas circunstancias los hagan funcionar de forma extraña. Que los conviertan en algo para lo que no estaban diseñados. Aquí es donde entran en juego los posibles atacantes. Pentesters, auditores,... y ciberdelincuentes. Para la organización, mejor que sea uno de los primeros que uno de los últimos. Pero para la aplicación, que no entra en valorar intenciones, no hay diferencia entre ellos. Simplemente, son usuarios.

Esperamos que este libro, con el que muchos habéis estudiado, siga siendo un compañero de viaje nuestro y vuestro, que mientras que las vulnerabilidades de SQL Injection sigan existiendo, nosotros seguiremos trabajando en este área tan bonita que es el pentesting.

¡Saludos Malignos!

Autor: Chema Alonso

Contactar con Chema Alonso

Preguntas del examen de Seguridad en Aplicaciones Web de la UEM 2017

Ayer fue el día en que mis alumnos del Master de Seguridad de la UEM tenían que hacer el examen del modulo de Seguridad en Aplicaciones. Este año, además, aprovechamos para ir en uno de los días de clase a la RootedCON, así que entre las preguntas que cayeron estaba una relativa a la charla que allí dimos. 

Figura 1: Preguntas del examen de Seguridad en Aplicaciones Web de la UEM 2017

Como suelo hacer, os dejo lo que les pregunté. Cosas sencillas, para que me quede claro si han aprendido los conceptos básicos de este módulo. Os las dejo por aquí por si los que estáis estudiando las queréis comprobar. Además, os dejo enlaces a algunos artículos que detallan las respuestas.

1.- Dada una aplicación PHP que utiliza MySQL como motor de base de dato. y es vulnerable a SQL Injection en el programa miprog.php?id=1 que muestra noticias. Explicar cómo sería un ataque de Blind SQL Injection para sacar la versión del motor de la base de datos.

Los ataques Blind SQL Injection se basan en hacer una booleanización de los datos que se buscan utilizando patrones de reconocimiento de las repuestas True o False basados en mensajes de error, cambios en las respuestas de la web, tiempos de respuesta o sumas lineares de valores ASCII. Una vez encontrada la vulnerabilidad se puede explotar manualmente con consultas del tipo miprog.php?id=1 and 54>ASCII(Substr(version(),1,1). En el vídeo se puede ver la explotación SQLbFTools

Figura 2: Blind SQL Injection en MySQL con SQLbTools

2.- Dada una aplicación PHP que utiliza MySQL como motor de base de dato. y es vulnerable a SQL Injection en el programa miprog.php?id=1 que muestra noticias. Explicar cómo sería un ataque de Time-Based Blind SQL Injection para sacar la versión del motor de la base de datos.

En este caso es necesario utilizar un ataque de Time-Based Blind SQL Injection. En MySQL se pueden utilizar las funciones de retardo de tiempo explícito "sleep()" a partier de MySQL 5 o superior, las funciones intensivas en cómputo Benchmark o los ataques con Heavy Queries.

Figura 3: Time-Based Blind SQL Injection using Heavy Queries

3.- Una aplicación web cuenta con un programa download.php?file=doc.pdf que es vulnerable a técnicas de LFI (Local File Inclusion) o RFD (Remote File Downloading). Explica cómo sacarías las credenciales de acceso de la aplicación a la base de datos.

Si se pueden descargar ficheros del servidor con un Local File Inclusion o con técnicas de Remote File Downloading, al final te pueden inspeccionar el código Server-Side para ver dónde está configurada la conexión a la base de datos. En este artículo se explica un proceso completo: Cómo te pueden robar la Base de Datos de tu sitio web con bugs de Path Transversal & Local File Inclusion.

4.- Una aplicación ASP tiene un formulario de login vulnerable a SQL Injection en el campo de usuario. Explica alguna combinación que pudiera utilizarse para intentar hacer login con el usuario Chema sin conocer la password del mismo.

Esta es una pregunta básica de SQL Injection. Dependiendo del motor de bases de datos y la creación de la consulta SQL que haya hecho el programador habrá muchas pequeñas diferencias (incluso si está hecho con Inverted SQL Queries). Pero lo más básico sería probar un Chema';--

5.- Dada una aplicación ASP que muestra un listado de alumnos de una clase con nombre y apellidos con el siguiente comando SQL:

Select nombre, apellidos from alumnos where clase=‘+$clase+’;

Donde $clase se recibe como parámetro GET mediante listado.asp?clase=primeroA. Describe cómo sería un ataque Inband para sacar los usuarios y contraseñas de la tabla USERS (UID,PWD) por pantalla

En este caso se trata de un ataque UNION para usar el mismo Recordset que utiliza el programador, así que bastaría con hacer que la consulta original no devolviera ningún dato y enlazar la nuestra. Algo como: clasequenoexiste' UNION SELECT UID,PWD FROM USERS;--

Figura 4: Feliz 15 aniversario SQL Injection

6.- Describe en qué consiste un ataque de SQL Injection OutBand basado en errores ODBC

En la conferencia de arriba lo tenéis descrito. Se trata de conseguir ver la información que se quiere extraer de la base de datos usando los mensajes de error ODBC. Esta técnica fue descrita por David Litchfield en el año 2001 en el paper: Web Application Disassembly with ODBC Error Messages. Yo la utilicé combinada con los ataques de Serialized SQL Injection tiempo atrás.

7 .- Describe en qué consiste el ataque de Rogue DirtyTooth Speaker contra terminales iOS y qué mecanismos podría poner Apple para minimizar su impacto.

Esta pregunta es fácil si has atendido a la conferencia de la RootedCON y has leído el artículo en cinco partes que publiqué esta semana: DirtyTooth Hack.

Figura 5: Cómo funciona DirtyTooth Hack

8.- Una página web tiene un login con un fichero login.swf que no hace Callback. ¿Qué habría que probar?

Tan sencillo como decompilar el SWF a ver qué sorpresas nos trae. Parece mentira, pero aún nos encontramos sitios en los que el login se basa en eso.

9.- Una tienda online usa un sistema de venta de productos pero un cliente ha comprado un producto por la mitad de su precio. ¿Cuál puede haber sido el fallo? ¿Cómo se ha podido explotar?

Probablemente se trate de un error clásico en el que el programador ha utilizado el precio que le llega desde el cliente en lugar del precio de la base de datos. El atacante puede cambiar ese valor con un proxy de interceptación igual que en el caso de La compañía de vuelo low-cost y la tasa de facturación anticipada. En el libro de Hacking Web Technologies se explican en detalle estas técnicas.

10.- Explica en qué consiste una tautología en un ataque de SQL Injection.

Las tautologías son valores que son siempre ciertos. Se usan para conseguir manipular el funcionamiento de una web inyectando condiciones que anulan el resto de las comprobaciones. Especial mención de esto al artículo de las "quasi-tautologies" que también pueden utilizarse.

Hasta aquí el examen que hicieron mis alumnos. Ahora espero que las notas que saquen todos sean muy buenas y que te haya entretenido ver lo que aprenden en clase.

Saludos Malignos!

Configurar WebApps con MS SQL Server in Paranoid Mode usando Latch

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.

Figura 14: Demo de SQL Server in Paranoid Mode

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

SIDU: Un Database Web GUI para escanear servidores

Este domingo por la noche no conseguía dormirme con la vuelta al trabajo por lo que aproveché para revisar algunas cosas en Internet. Esta vez le tocó el turno a los ataques a cadenas de conexión de bases de datos, así que, como ya hiciera tiempo atrás con Chive, con SQL Web Data Administrator, MyLittleAdmin, MyLittleBackup, ASP.NET Enterprise Manager o las aplicaciones Citrix, busqué algún nuevo panel de control de bases de datos por medio de un interfaz web, y di con SIDU, una herramienta que permite gestionar motores de bases de datos MySQL, Postgres, SQLite y CUBRID.

Figura 1: SIDU - Un DB Web GUIO con bugs de XSPA

Encontrar la herramienta publicada en Internet no es difícil. Hay muchas organizaciones que tienen este tipo de aplicaciones en sus sitios web, para poder administrar sus bases de datos, y ésta, en concreto, viene con muchas posibilidades.

Figura 2: Lista de bases de datos a las que se puede conectar para lanzar comandos SQL

Como se puede ver, permite hasta Microsoft SQL Server, por lo que podría ser una víctima propicia para los ataques de Connection String Parameter Polution, pero lo cierto es que necesita un driver especial en los entornos en los que mirado. Pero sí que se pueden hacer otras cosas, como vamos a ver.

Remote XSPA (Cross-Site Port Attacks)

Estas herramientas son propensas a la vulnerabilidad de XSPA (Cross-Site Port Attacks). Al final, una cadena de conexión a una base de datos permite introducir una dirección IP o nombre de dominio de un servidor de bases de datos y un puerto, por lo que si los mensajes de error no han sido controlados, alguien podría manipular estos servicios para valores para escanear servidores. Por supuesto, esta escaneo se puede hacer a tres niveles distintos:

1.- Escanear puertos del propio servidor de bases de datos: Bastaría con manipular el valor del puerto con respecto a localhost. 

2.- Escanear puertos de cualquier servidor de Internet: Esto se podría realizar si el firewall de la infraestructura de red donde está montado el servidor web que hospeda a SIDU no controlar las conexiones de salida. 

3.- Escanear la DMZ: Esto se podría hacer si se averigua la dirección IP local del servidor en el que está hospedado SIDU.

En la última versión, en la 5.3 de SIDU, la vulnerabilidad de XSPA está presente, y basta con hacer unas sencillas pruebas para comprobarlo. En este caso vamos a ver como un puerto está abierto o cerrado según los mensajes de error. Para ello he elegido la web de un diario.

Figura 3: El puerto está cerrado

Cuando el puerto está abierto, tal y como se puede ver arriba, el mensaje de error que se obtiene es un Connection Time-Out, esto es así porque la conexión TCP nunca se abre.

Figura 4: El puerto está abierto

Por el contrario, cuando el puerto está cerrado, el mensaje que se obtiene es completamente distinto. En este caso un "MySQL Gonne Away", porque el puerto TCP se abre pero está esperando el desafío de login de MySQL que nunca llega.

Figura 5: El puerto está abierto y es un MySQL

Si el puerto estuviera abierto, y además hubiera un servidor MySQL en él, se obtendría aún un tercer mensaje de error, informando de que el usuario y la contraseña son incorrectos, con lo que tendríamos el bug de XSPA completo.

SIDU PHP Info: Local IP disclosure

Para poder hacer lo mismo en el servidor local, bastaría con cambiar el puerto con localhost, pero si lo que deseamos es hacerlo con la DMZ, entonces hay que averiguar cuál es la dirección IP de la red local con que se ha configurado el servidor web que hospeda a SIDU. Esto, gracias al propio SIDU es una tarea bastante sencilla.

Figura 6: Conexión a una base de datos SQLlite que no existe

Una de las cosas que trae SIDU, es una conexión para lanzar consultas a bases de datos SQLite que no necesita usuario ni contraseñas. Cuando seleccionas esa opción, no se valida si la base de datos existe o no, así que puedes poner lo que quieras en ella y llegar al panel interno creado para lanzar consultas SQL.

Figura 7: En el menú interno hay acceso a un PHP Info

Lo mejor de todo es que, entre las opciones que han puesto en el menú se encuentra la de lanzar un PHP Info, tal y como se ve en la pantalla.

Figura 8: Acceso a la dirección IP local del servidor que hospeda SIDU

Y por supuesto, con esto llegaríamos a la dirección IP local del servidor web en el que se encuentra hospedado SIDU. Algo bastante sencillo de hacer para cualquier visitante. 

DMZ XSPA (Cross-Site Port Attacks)

Una vez que se tiene la dirección IP local del servidor web, se puede comenzar a escanear el segmento completo, haciendo un barrido a toda la red - en este caso de tipo C - para localizar todos los servidores que allí se encuentran.

Figura 9: Escaneo por puertos de MySQL del segmento de red

Como habría que escanear todos los puertos de todos los servidores, lo suyo sería buscar los well-known más comunes, como el 80 de los servidores web, o el propio puerto de los servidores MySQL de la red.

Figura 10: Connection String Attacks @ DefCON 18

Este tipo de herramientas de administración de bases de datos, donde delegan toda la seguridad en el establecimiento de conexiones, tienen habitualmente los mismos problemas. Os dejo arriba la charla de Connection String Attacks que dimos en DefCON por si te apetece repasar los fallos más habituales, así como los ataques que se pueden hacer.

Saludos Malignos!

El caso del fingerprinting al SQL Server TDS7 de Microsoft

Como sabéis, nuestra Foca As A Service by Telefonica (Faast) es uno de mis juguetes preferidos, así que siempre me paso revisando los resultados y haciendo de beta tester malo, malo, maligno de las nuevas versiones que el equipo de Faast va sacando. La historia que os cuento hoy lleva un tiempo detrás de mis orejas rondándome como una daemon en background, y esta mañana, aprovechando que el estrés me ha levantado a las 5 A. M. he vuelto a revisarla un poco más en detalle.

Figura 1: El "caso" del fingerprinting al SQL Server 7 de Microsoft

Como sabéis, yo suelo testear las ideas con empresas Hacking Friendly que cuando les reportas un bug te lo agradecen, así que Microsoft y Apple son dos de esas empresas en las que pruebo las ideas ya que su infraestructura expuesta en Internet es tan grande que suelen tener de casi todo. Además, cuando les he reportado algo, lo han corregido y han sido de lo más cordiales. 

La historia y la pregunta a responder

En este caso la historia comienza con el descubrimiento por parte de Faast de una dirección IP con un servidor Microsoft SQL Server expuesto a Internet que nuestro sistema detectó como un MS SQL Server 2012. 

Figura 2: Microsoft SQL Server 2012 descubierto por Faast

Como os podéis imaginar, a mí me llamó la atención que estuviera publicado con el puerto por defecto a Internet, además de que el sistema operativo diera que es un Kernel 6.1, así que quise revisar si esto era así o no, ya que las diferencias entre la arquitectura de seguridad de Windows son grandes entre cada versión. Para ello, primero me fui a Shodan y busqué en la dirección IP para ver si con una visión del hacking con buscadores podría contrastar esta información. La sorpresa es que Shodan no tenía asociado ningún servidor MS SQL Server a esta dirección IP. El misterio crecía.

Figura 3: Shodan no reconoce ningún motor de SQL Server en esa dirección IP

Tocaba hacer una comprobación manual. Salí el primero de la zona sur en el malignomóvil y me planté esta mañana a las 7.00 en las oficinas de Eleven Paths para acabar de responder a por qué en Faast aparecía y no así en Shodan. En la soledad de la oficina, aproveché para actualizar la versión de WireShark y de Microsoft Excel 2016 para probar el "truco" de sacar el nombre de un servidor MS SQL Server por medio del establecimiento de una conexión desde Excel.

Figura 4: Estableciendo una conexión a un motor SQL Server (sin credenciales válidas) desde Excel 2016

En las capturas de WireShark apareció un paquete distinto al esperado GSS-API, y sin esperarlo me topé con un paquete de TDS7 Pre-Login. La cosa se ponía más extraña aún, ya que los paquetes de Pre-login TDS7 son de la versión de SQL Server 7.0, que es el que utiliza Tabular Data Stream 7.

Figura 5: Mensaje capturado por WireShark en el establecimiento de la conexión a SQL Server desde Excel

Además de eso, como se puede ver en la captura, la configuración del servidor SQL Server no solo es con el puerto por defecto a Internet, sino que el cifrado de la conexión está deshabilitado por lo que se podrían hacer ataques de Network Packet Manipulation como ya vimos en MySQL Server.

Figura 6: Versiones de TDS asociadas a versiones de MS SQL Server

Ya tocaba hacer las últimas pruebas, así que manualmente probamos nmap con un fingerprinting contra el puerto, pero el servidor tiene filtrados los puertos contra los escaneos y no nos dio mucha información. 

Figura 7: Nmap detecta el puerto 1433 pero no la versión del servicio

Como última prueba, tocaba usar Exploit Next Generation SQL Fingerprint, una herramienta con tiempo pero que hace muchas pruebas para garantizar el fingerprinting de SQL Server, así que la buscamos, la localizamos y la probamos. El resultado es el que veis en la siguiente captura. Descubre el servidor SQL Server, pero no es capaz de dar la versión exacta, por lo que al final, el análisis manual con la conexión Excel y WireShark es lo que mejor ha funcionado.

Figura 8: Prueba de ESF contra la dirección del servidor SQL Server

¿Será un SQL Server 7 o un SQL Server 2012?

Llegados a este punto, había que documentarse a ver por qué Faast estaba reconociendo el SQL Server como 2012, así que fuimos a ver cómo hace nmap el filtro de detección de versión de SQL Server en detalle. La respuesta es curiosa. Microsoft SQL Server no hace disclosure de la minor version de TDS, así que hasta la versión Microsoft SQL Server 2014 se utiliza TDS 7 en el paquete de Prelogin. Lo que hace nmap y Faast es comprobar la firma del paquete. Para ello hay una pequeña base de datos que reconoce los paquetes de prelogin de todos los TDS7 y sabe si es un TDS 7.1, TDS 7.2, etcétera.

Figura 9: Volviendo a hacer la prueba con nmap tal y como la hace Faast obtenemos un SQL Server 2012

Al final, no ha sido más que responder una pregunta, y para ello ha habido que hacer pruebas, suposiciones y más verificaciones para descartar posibilidades, pero el resultado es una pequeña mejora en Faast que hará que el fingerprinting de los servidores SQL Server sea un poco más afinado aún. Por supuesto, un servidor SQL Server expuesto a Internet sin cifrado en la conexión no es lo más seguro que puede estar un motor de bases de datos. Me encanta este mundo en el que cada detalle cuenta y cada situación extraña genera un misterio a resolver.

Saludos Malignos!

Examen del Máster de Seguridad de la UEM 2016

Como viene siendo tradición, un año más he vuelto a "torturar" a mis alumn@s con un examen al final del módulo dedicado a la seguridad de las aplicaciones. No me gusta ser excesivamente maligno, así que más o menos pongo siempre los mismos exámenes pero cambiando las preguntas porque, en este módulo de 16 horas, yo quiero que se lleven claros algunos conceptos básicos fundamentales. Estas son las preguntas que les tocó responder ayer a última hora. Anímate a responderlas.

Figura 1: Examen del módulo de Seguridad en las Aplicaciones del
Máster de Seguridad de la UEM. Curso 2015 -2016

A ver si saco algo de tiempo para responderlas yo - y las del último examen que también las dejé sin responder - para que tengáis la información completa. Al final os dejo la lista de exámenes de años anteriores.

1.- Tu organización dispone de una aplicación web de cara a internet consistente en ofertar productos y servicios con pasarela de pago propia desarrollada para una plataforma Java utilizando tecnologías Linux. Los datos de registro de los clientes, así como los pedidos solicitados se almacenan en una base de datos MySQL de la empresa, gestionando todo el proceso a través de la lógica de negocio. ¿Qué mecanismos de protección consideras que deberían implantarse en cuanto a la arquitectura de servidores y servicios se refiere? Cita reglas generales de fortificación y algunas medias concretas que creas convenientes para implantar.

2.- Una aplicación web de una empresa proporciona un proceso de autenticación que sospechamos un tanto curioso. Al analizar el código fuente de la página, vemos que la aplicación utiliza para el proceso de autenticación un Applet de Java con extensión JAR. Tras probar varios intentos de inicio de sesión, detectamos que no se produce Post-Back al servidor. ¿Qué fallo de seguridad podría tener esta aplicación y cómo debería investigarse?

3.- En qué consiste un ataque de tipo SQL Injection inband a una aplicación web. Pon algún ejemplo para sacar la lista de usuarios Tabla_USERS[Campo_Login, Campo_Password] de una web en un entorno vulnerable.

4.- Describe en qué consisten los ataques de Time-Based Blind SQL Injection y con qué tipo de funciones o métodos pueden realizarse en los motores de base de datos SQL Server, MySQL, Oracle y Access.

5.- Describe con tus palabras en qué consisten los ataques de LFI y cómo los podrías descubrir en una aplicación web durante un proceso de auditoría.

6.- Una aplicación web en PHP con MySQL es vulnerable a SQL Injection. Se quiere extraer la versión de Mysql realizando un ataque de Blind SQL injection. Describe el proceso que habría que realizar.

7.- En una aplicación web, la aplicación autentica a los usuarios con un árbol LDAP, para ello, cada usuario tiene un atributo uid y un atributo password. El programador ha filtrado el * y utiliza la función crypt antes de usar la contraseña en una consulta AND LDAP como ésta.

V_username: valor de usuario introducido en la página web por el cliente.
V_passwd: valor de contraseña introducido en la página web por el cliente.
C_passwd =crypt(v_passwd)
Consulta que da acceso o no a la aplicación:
(&(uid=+v_username+)(password=+c_passwd+))
¿Con qué inyección LDAP conseguirías entrar si la se está utilizando un árbol LDAP basado en OpenLDAP?

8.- Como administrador del sistema de tu organización, una mañana monitorizas que el antivirus corporativo reporta un malware en un directorio local del servidor donde tu empresa tiene alojado el sitio web. El archivo en cuarentena es un fichero denominado C99.php. ¿Qué tipo de ataque estás sufriendo y qué fallo o fallos de seguridad se ha/n podido aprovechar?

9.- Describe un posible método para robar una cookie marcada como HTTP-Only con un ataque de XSS y describe en qué entornos funcionaría.

10.- Describe como se puede hacer un proceso de hijacking de sesión a un usuario de una red social en la que las cookies no vayan por HTTP-s si en la web no se ha descubierto ninguna vulnerabilidad de código (ni SQLi, ni XSS).

Tiempo: 1 hora

Por si te animas a seguir, aquí tienes los exámenes de años anteriores, que también los he ido publicando en el blog.

- Examen Máster de Seguridad de la UEM 2009-2010
- Examen Máster de Seguridad de la UEM 2010-2011
- Examen Máster de Seguridad de la UEM 2011-2012
- Examen Máster de Seguridad de la UEM 2012-2013
- Examen Máster de Seguridad de la UEM 2013-2014
- Examen Máster de Seguridad de la UEM 2013-2014 (Herramientas auditoría)
- Examen Máster de Seguridad de la UEM 2014-2015

Saludos Malignos!

Un tip para SQL Injection Smuggling: @@Version en MySQL

Llevo muchos años con el mundo de las bases de datos y las técnicas de SQL Injection, de las que he dado muchas charlas y he participado en la publicación de un libro dedicado a ellas [Hacking aplicaciones Web: SQL Injection]. Aún así, siempre hay algo que no habías probado o que no había mirado, y este fin de semana, con mis alumnos del Master de Seguridad de la UEM, tocó revisar un pequeño detalle que no había usado nunca. Se trata de @@version en los motores de bases de datos MySQL.

Figura 1: Un tip para "SQL Injection Smuggling". @@version en BBDD MySQL

El objetivo es simple, se trata de averiguar la versión concreta de un motor de bases de datos que está detrás de una aplicación web vulnerable a SQL Injection. Para eso hay muchos trucos, y dependiendo del motor puedes ir a buscar elementos reconocibles en el diccionario de datos para saber a qué te enfrentas. Cada motor y cada entorno tienen sus trucos.

Figura 2: Mostrando @@version de Microsoft SQL Server en un error ODBC

En el caso de los motores Microsoft SQL Server, uno de los trucos más sencillos es imprimir el resultado de la función @@version, tal y como se puede ver en la imagen superior con un ataque outband usando los errores ODBC.

Obtener la versión en My SQL

En el caso de MySQL, ya sea por medio de ataques Blind SQL Injection, por medio de ataques outband de todo tipo, o por un ataque inband, se puede usar la función version(), tal y como se ve en este ejemplo en el que se saca partido de una inyección inband con claúsula UNION.

Figura 3: Ataque Inband SQL Injection en una WebApp con MySQL.
Se muestran los campos 2 y 3 la Select

Lo que no había usado yo nunca, quizá porque nunca lo había necesitado lo suficiente, es utilizar la función @@version en motores de bases de datos MySQL. De hecho pensaba que no funcionaba en ellos, ya que en la documentación de MySQL siempre te encuentras con la referencia a version(). 

Figura 4: Las funciones version() y @@version son sinónimos en MySQL

Ni en la parte de Determining your Current MySQL Version ni en la parte de Information Functions aparece. Pero sí, sí funciona, y en muchos sitios de Internet puedes encontrar referencia a ello.

Figura 5: Referencia en Internet a @@version en MySQL

Lo cierto es que en el pasado me he topado con algún filtro en el que se quitaban los paréntesis, con lo que hacer el SQL Smuggling (o como meter exploits de SQL Injection de contrabando saltándose los filtros de seguridad) se hace más complicado. En la charla de Codemotion 2013 hablé un poco sobre esto, por si quieres verlo.

Figura 6: Codemotion 2013 - SQL Injection: Feliz 15 Aniversario

En el ejemplo de averiguar la versión de MySQL, si lo haces con @@version no se necesitan paréntesis pero sí el símbolo de la arroba. Si el filtro es seguro y quita todos los caracteres, no vale de nada, pero no será la primera vez que se encuentra un filtro que quitar espacios pero no comentarios, o que quita paréntesis pero no arrobas. Si como yo has usado siempre version() en MySQL, que sepas que también puedes usar @@version, solo eso.

Saludos Malignos!