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

Y de tu SAP a conocer tu motor de Bases de Datos

Llegar al Sistema Gestor de Bases de Datos (SGBD) en cualquier proceso de Ethical Hacking es fundamental. Ahí están los datos y suele ser la pieza más preciada. Si un atacante consigue llegar y acceder con privilegios se verían afectados los pilares de la seguridad: La confidencialidad, la Disponibilidad y la Integridad. En otro día vimos en un artículo cómo es posible descubrir la infraestructura SAP de una organización, y hoy vamos a ver cómo continuar para descubrir dónde está el SGBD que utiliza el sistema SAP de una empresa gracias a un componente fundamental en los entornos SAP: el ICM (Internet Communication Manager), responsable de la comunicación del sistema SAP con Internet mediante los protocolos HTTP, HTTPS y SMTP.

Figura 1: Y de tu SAP a conocer tu motor de Bases de Datos

Todos los sistemas SAP utilizan un Sistema Gestor de Base de Datos Relacional (SGBDR) donde mantienen centralizada la casi totalidad de la información manejada por este software de gestión (información de clientes, pedidos, proveedores, etcétera). Dada la naturaleza de esta información, lo lógico es que este SGBD se encuentre en la red interna de la empresa y sólo desde allí se admitan las peticiones a las bases de datos.

Figura 2: Arquitectura del sistema que recibe las peticiones desde Internet

En este artículo se veremos cómo, aprovechándonos de una mala configuración en el ICM del sistema SAP, en ocasiones, es posible conocer el tipo de SGBD es utilizado por el sistema, parte del direccionamiento interno de la empresa donde se encuentra el SGBD, así como el sistema operativo que corre en el host del servidor de bases de datos.

Módulo sap_icf_public_info

Para descubrir el SGBD del sistema SAP de una empresa, puede usarse el módulo sap_icf_public_info de Metasploit disponible en el GitHub de la empresa Rapid7.

Figura 3: Información del módulo sap_icf_public_info en Metasploit desde Kali Linux

Lo que hace este módulo es aprovechar parte de la configuración por defecto del componente ICM, para que éste pueda reenviar peticiones HTTP/S a un recurso XML que guarda la información sobre el SGBD usado en el sistema SAP, versión del sistema operativo del host sobre el que corre el servidor de base de datos, direccionamiento IP interno, etcétera.

La configuración del módulo es muy es sencilla, ya que la mayoría de las veces basta con indicar el en parámetro RHOSTS la dirección pública del sistema SAP expuesto en Internet (set RHOST 200.x.x.x). Por defecto, el módulo realizará peticiones HTTP al puerto 8000/TCP del sistema SAP.

Figura 4: Configuración del módulo sap_icf_pulic_info 

Descubriendo los Sistemas Gestores de Bases de Datos

Tras lanzar el módulo, observamos que devuelve información sobre un SGBD, en este caso Oracle, el nombre del servidor de base de datos, sappbobd, el nombre del host sobre el que corre, sapboci, así como la dirección IPv4 interna que tiene asignada, 192.168.241.40. Además, el sistema operativo es un SunOS.

Figura 5: Información de un SGBD Oracle y el host en el que corre

En este otro caso, tenemos que el SGBD es MSSQL de Microsoft, el nombre interno del servidor de base de datos es SVRPROERP\PRD, el nombre del host es SRVPROER y el sistema operativo es un Windows NT.

Figura 6: Información de un SGBD MS SQL Server del Host en que corre

En este otro ejemplo, tenemos que el SGBD es un DB/400 de IBM, el nombre del host y del SGBD coinciden, sapprod, el sistema operativo sobre el que corre el SGBD es OS/400 de IBM.

Figura 7: Información de un SGBD DB/400 de IBM y el host en que corre

Análisis del tráfico de red generado por el módulo

Siempre que se lanza un módulo en Metasploit es interesante capturar y analizar el tráfico de red que genera, ya que puede proporcionarnos más información que la meramente devuelta por el módulo. Descubrimos que el módulo sap_icf_public_info realiza una petición por GET vía HTTP de un recurso XML cuya URI es /sap/public/info.

Figura 8: Flujo TCP de la petición realizada al sistema SAP

Dado que es una petición bajo el protocolo HTTP, conociendo la URI (/sap/public/info), la dirección IP del sistema SAP y el puerto TCP que recibe la petición, es posible construir la URL completa y acceder al recurso XML directamente desde un navegador web.

Figura 9: Resultado de la petición generada desde un navegador web

Conclusiones

Para evitar este tipo de fugas de información del sistema SAP y evitar que sea indexada por los principales motores de búsqueda, bastaría impedir que el componente ICM realice la petición del recurso XML directamente desde Internet mediante el protocolo HTTP, permitiendo las peticiones únicamente desde la dirección 127.0.0.1 de localhost o indicando qué hosts son aquellos que sí tienen permiso para consultar la información del recurso XML.

Figura 10: Zona de la configuración de los hosts con acceso al recurso XML

Autor: Amador Aparicio de la Fuente (@amadapa)
Escritor del libro "Hacking Web Technologies"

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!