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)  

Evil Signature Injection: Borrado remoto de bases de datos, buzones de correos y ficheros de log con Evil Signatures y tu EDR

Después del incidente con Crowdstrike, uno de los EDR más famosos del mundo, los ojos de los investigadores de seguridad se han puesto en ellos. Tener en el sistema objetivo de un ataque un software que se ejecuta con tantos privilegios se ha convertido en oportunidad de usarlo como herramienta del atacante en lugar de temerlo como una herramienta defensiva.

Figura 1: Evil Signature Injection: Borrado remoto de bases de datos,

buzones de correos y ficheros de log con Evil Signatures y tu EDR

Ayer sábado, tranquilo por la tarde, comencé a repasar las charlas de BlackHat y DefCON, y me topé con el trabajo de EDR Reloaded: Erase Data Remotely de los investigadores Tomer Bar y Shmuel Cohen. Desde el principio me encantó la idea por lo simple y hacker que es, y sobre todo, porque es algo que hacíamos nosotros hace muchos años.

Back in 2012 with Eicar

En el año 2012, durante un tiempo, estuve jugando mucho con los Terminal Services y la Apps en Citrix. Escribí muchos posts sobre ellos, y acabé dando una charla junto al gran Juan Garrido en DefCON sobre Terminal Hackpplications llamada "Bosses love Excel, hackers Too", donde llevábamos, además de muchos de estos trucos que quedaron en el blog, una idea del gran Silverhack de meter la shell en EXCEL y desde una sesión de Terminal Services o Citrix controlar la máquina. 

Figura 2: Bosses love Excel, hackers too

Entre los trucos, estaba el de forzar que cantara el antivirus del servidor incluyendo la firma de EICAR para testar si estaba siendo investigada por un Antimalware (aún no se utilizaba el concepto de EDR), y cuál era en concreto. Lo dejé en el artículo: "Eicar para hacer jailbreak en Terminal Services o Citrix".

Figura 3: Symantec EndPoint Protection vigila este Citrix
y nos da el botón de ayuda para entrar en el sistema.

La gracia era qué, si saltaba la consola del antivirus, o una alerta, podríamos llamar a la ayuda, sacar un explorador de ficheros y abrir el sistema completo. Es decir, hacer Jailbreak a una sesión de Terminal Services o Citrix mediante un firma de una muestra de malware "ficticia", como era EICAR.

Erase Data Remotely with Evil Signatures

Ese concepto de "Firma Maliciosa" o "Evil Signature" es lo que han utilizado los investigadores para hacer que se borren ficheros, aprovechándose de Windows Defender en los sistemas Microsoft, y de otros EDR en sistemas GNU/Linux, generando una Evil Signature que ingresan en el sistema de diferentes maneras, ya sea incluyéndola en un fichero binario, en un doc, en una llamada HTTP, en una consulta SQL, o en un alta de un usuario de una plataforma SaaS.

Figura 4: Búsqueda de Evil Signatures para Windows Defender

La idea es tan sencilla como, buscar las firmas que usa Windows Defender, y probar para tener tener el mínimo de caracteres necesarios para que el EDR de Microsoft lo detecte como si fuera un malware de severidad HIGH, para lograr que la acción que se lance sea la más drástica, es decir, eliminar el fichero. 

Figura 5: Windows Defender tiene diferentes acciones por severidad

El resto es conseguir que el fichero ese sea el que quiere borrar el atacante. Así que, a partir de ese momento, es objetivo es ver cómo meter la firma más pequeña en el sitio adecuado para saber qué fichero quieres que borre el EDR que está protegiendo esta máquina.

Figura 6: Introduciendo la Evil Signature en un HTTP Post

En el ejemplo anterior, la Evil Signature se introduce simplemente en un parámetro por POST desde una llamada HTTP, para conseguir que Windows Defender elimine los logs del servidor de Web de la máquina.

Figura 7: Logs del servidor Web eliminados por Windows Defender

Lo mismo se puede hacer con una sesión Windows FTP, en este caso inyectando la Evil Signature como si fuera el nombre del usuario, pero al inscribirse este username en el fichero de log, salta el EDR y se carga el archivo completamente porque es severidad High.

Figura 8: La Evil Signature en el username de un Windows FTP

Esto, en determinados sistemas puede ser más crítico. En este caso, se carga el mailbox de un Mozilla  ThunderBird, que no le hará ninguna gracia al usuario que, sin hacer ninguna acción se acaba de quedar sin ninguno de sus correos almacenados.

Figura 9: Borrado del buzón de Mozilla ThunderBird

Y por supuesto, el propio log de la máquina Windows que viene de serie en todos los sistemas de Microsoft y que usan los SysAdmin para controlar lo que está pasando en su plataforma. De repente verán vacíos temporales.

Figura 10: Borrado de los logs de Windows

También, se puede lograr que Windows Defender elimine su propio log, lo que es una maravilla para borrar los rastros que un atacante deja en un sistema.

Figura 11: Eliminando los logs de Windows Defender

Además, se puede lograr que la víctima expanda el ataque, ya que si el fichero de log pasa al servidor de logs, se llevará la Evil Signature consigo, así que si tenemos un Splunk, éste acabará siendo afectado también.

Figura 12: Afectando la Evl Signature a Splunk

Pero lo peor de este ataque es que si lo consigues meter en el Datafile de una base de datos y que el EDR lo tome como un malware de severidad High, entonces podrías conseguir eliminar la base de datos de un objetivo, lo que no debe ser gracioso para nadie.

Figura 13: Borrando la base de datos de un MariaDB con Evil Signature

En este caso, los investigadores han sido capaces de que el EDR se cargue bases de datos de MariaDB ( MySQL), PostgreSQL, MomgoDB (adiós a tu BigData) y SQLLite, lo que podría dejar sin funcionar la gran mayoría de servicios y aplicaciones que corren sobre ellos.

Figura 14: Bases de datos afectadas por Evil Signature Injection

Y por supuesto, también se pueden hacer los ataques desde servidor a cliente. En este caso sería un Client-Side Attack que se puede hacer por culpa de visitar un servidor vulnerado, o por un ataque a través de él.

Figura 15: El Web Server envía la Evil Signature al cliente

Y el cliente ve cómo se le borran los ficheros del sistema a través del EDR que tenga configurado para "protegerlo" de los atacantes. Paradojas de la vida.

Figura 16: Windows Defender borra la historia de

Google Chrome y los Web Data

La gracia es que podría hacerse un CSRF, un XSS, un SSRF, o cualquier otro Client-Side Attack para que un atacante haga un Evil Signature Injection en tu equipo y tengas un problema de seguridad serio. Por suerte, los reportes han sido tomados en serio y - tras varias iteraciones - se han corregido, pero esta técnica hay que tenerla en cuenta porque cualquier software privilegiado que corra en tu máquina podría ser víctima de Evil Signature Injection y tener un problema serio en tu plataforma.

¡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

Time-Based XSPA (Cross-Site Port Attack) en DBKISS

No hace demasiados días os hablé de un bug de Time-Based XSPA en los scripts de instalación de WordPress, y hoy os quiero hablar de otro caso similar con un WebGUI para administrar motores de bases de datos MySQL y PostgreSQL que se llama DBKiss. Es un bug curioso que en este caso se explota bien con el driver de PostgreSQL. Os lo explico en este post.

Figura 1: Time-Based XSPA (Cross-Site Port Attack) en DBKiss

Los bugs de XPSA (Cross-Site Port Attack) se basan en la explotación de un SSRF (Server-Side Request Forgery) mediante la que un atacante fuerza a la aplicación a realizar una determinada conexión a un servicio que se encuentra en un servidor corriendo por un puerto para poder así escanear los puertos de un servidor objetivo. En este caso, aprovechándonos de que la aplicación vulnerable es un WebGUI que muchos usuarios implanta en sus sitios web para gestionar la base de datos MySQL de WordPress o de cualquier otro CMS, basta con manipular los datos de la cadena de conexión.

Figura 2: Un DBKiss gestionando el MySQL de un WordPress

Hay que tener cuidado con publicar estos scripts a la ligera, pues muchas veces son herramientas en proceso de desarrollo o con vulnerabilidades conocidas. Basta con ver el código fuente de DBKiss para darse cuenta de que aún le quedan muchas cosas que corregir a esta herramienta antes de poder instalarse y publicarse a Internet, ya que se estarían asumiendo muchos riesgos.

Figura 3: Cosas aún por solucionar en los comentarios de DKiss (XSS y CSRF)

El peligro de poner estos scripts vulnerables a estas técnicas de XSPA es que el servidor objetivo al que se quiere escanear puede estar dentro de la DMZ, es decir, con direccionamiento en la red local, ya que basta con que el servidor web tenga conectividad con ellos. Con un aplicación web vulnerable a XSPA en un servidor de la DMZ, un atacante podría hacer un mapa detallado de todos los servidores y todos los puertos que estos tienen abiertos.

Time-Based XSPA en DBKiss

En el caso de los ataques de Time-Based XSPA, el atacante mide el tiempo de respuesta de cada conexión para saber si es un resultado que indica que el puerto está abierto, o un un resultado que indica que el puerto está cerrado. Para esto, en las cadenas de conexión a bases de datos el bug se aprovecha de que la configuración de la conexión no tenga un Time-Out bien configurado que evite que el atacante pueda medir las diferencias temporales en las respuestas sin error.

Figura 4: Con la conexión al puerto 80 usando el driver de PostgreSQL el tiempo de respuesta es corto

Como se puede ver, si forzamos una conexión con DBKiss contra un servidor con un puerto abierto, en este caso contra el puerto 80 de la web de Eleven Paths utilizando el driver de PostgreSQL, podemos ver que se obtiene un tiempo de respuesta muy corto.

Figura 5: Con el puerto cerrado el tiempo de respuesta es muy alto y salta el Time-Out por defecto

Si hacemos lo mismo contra un puerto que esté cerrado, lo que pasamos a obtener es un tiempo de respuesta muy largo que llega a generar un Time-Out en la web, es decir, que el tiempo configurado por defecto de Time-Out en la conexión de la base de datos es mayor que el Time-Out configurado en el servidor web.

Figura 6: Hay que configurar el Time-Out en la conexión a PostgreSQL para evitar este leak

Al final, estas vulnerabilidades abren la captura de información de la infraestructura de una organización a un atacante que en un APT será de gran utilidad para poder planificar el siguiente paso del ataque. Cuidado con lo que publicas en tu servidor web.

Saludos Malignos!