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)  

Test de uso de GenAI para la detección de bugs de "Connection String Parameter Pollution" (CSPP) usando Ollama

En la primera parte de este artículo de ayer, titulado "Cómo utilizar GenAI para la detección de bugs en ficheros Web.config usando Ollama" explicaba cómo de bien detectaba el motor de GenAI basado en Ollama con diferentes LLMs los fallos de configuración de un fichero Web.config en aplicaciones ASP.NET , pero en la presentación del trabajo, me llevé deberes para casa, que os voy a contar ahora.

Figura 1: Test de uso de GenAI para la detección

Connection String Parameter Pollution usando Ollama

Y es que cuando terminé de exponer mi trabajo con lo visto hasta el momento, Chema Alonso comentó que le gustaría probar cómo se comportaría este sistema frente a los ataques a los parámetros de las cadenas de conexión a bases de datos.

Vulnerabilidades de Connection String Injection

Chema Alonso y José Palazón presentaron en DEF CON 18 este tipo de ataques, donde destacan los ataques de Connnection String Parameter Pollution (CSPP). Tienes un paper publicado sobre estos ataques en BlackHat y una serie de artículos sobre Connection String Attacks en este blog.


Figura 2: Connection String Attacks en DefCON18

Aunque hay varias formas en las que se puede explotar esta vulnerabilidad, nos centraremos en el escenario de delegación de la autenticación en el motor de BD.  Es decir, tenemos una aplicación que recoge las credenciales del usuario y la cadena de conexión a la BD se calcula dinámicamente con estas. 

Figura 3: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Cada usuario puede tener o no permisos de conexión a la BD y permisos de lectura o no a ciertas tablas. En el siguiente código C# de una aplicación ASP.NET se puede ver la idea:

private void EnlazarGrid(string usuario, string contraseña)
{

string cadenaConexion = $"Server=UK5FCMI;Database=WebApp;User Id={usuario};Password={contraseña};"; 

using (SqlConnection con = new SqlConnection(cadenaConexion))

{

using (SqlCommand cmd = new SqlCommand("SELECT * FROM Products"))

{

using (SqlDataAdapter sda = new SqlDataAdapter())

{

cmd.Connection = con;

sda.SelectCommand = cmd;

using (DataTable dt = new DataTable())

{

sda.Fill(dt);

GridViewProductos.DataSource = dt;

GridViewProductos.DataBind();

}

}

}

}

}    

El método construye, mediante interpolación de cadenas, una cadena de conexión a una BD tipo SQL Server a partir de los parámetros de usuario y contraseña. Estos parámetros no se validan en ningún momento (ni en el llamador). Con esta cadena de conexión, se lanza una conexión contra la BD y se lee la información de la tabla Products (si el usuario de BD tiene permisos SELECT sobre dicha tabla) para mostrarla en la grid del formulario ASPX. Todos estos ataques se explican en mucho detalle en el libro "Hacking Web Technologies 2ª Edición" de 0xWord.

Figura 4: Libro de "Hacking Web Technologies Silver Edition"

donde Chema Alonso habla de los Connection String Attacks

Una forma de explotarlo sería, por ejemplo, introducir como contraseña la cadena ;Integrated Security=True;, con cualquier usuario. Si se permite la autenticación integrada en SQL Server y el usuario del pool de IIS con que se está ejecutando la aplicación tiene permisos de conexión y consulta a la BD de la aplicación, podemos conseguir acceder a información que no nos corresponde. 

Utilizando el mismo prompt que ya hemos diseñado, vamos a pedir al modelo de Llama 3.1 que evalúe la seguridad del código.

Figura 5: Análisis de vulnerabilidad de inyección en la cadena de conexión

El modelo detecta un problema en la cadena de conexión, identificando que los parámetros de usuario y contraseña, que provienen de los campos de un formulario, no se han validado ni comprobado. Detecta que esto puede presentar un problema de SQL Injection, sin embargo, la propuesta de solución NO es acertada. En la cadena de conexión, elimina los parámetros de usuario y contraseña:

string cadenaConexion = $"Server=UK5FCMI;Database=WebApp;";

using (SqlConnection con = new SqlConnection(cadenaConexion))

{

...

Y propone utilizar consultas parametrizadas, de la siguiente manera:

using (SqlCommand cmd = new SqlCommand("SELECT * FROM Products WHERE Usuario = @Usuario AND Contraseña = @Contraseña"))

{

cmd.Parameters.AddWithValue("@Usuario", usuario);

cmd.Parameters.AddWithValue("@Contraseña", contraseña);

...

} 

Pero esto NO funcionará. En primer lugar, no se podrá conectar a la BD sin un usuario y contraseña en la cadena de conexión. Y la consulta modificada de la tabla Products tampoco funcionará porque Usuario y Contraseña no son campos de dicha tabla.

Parece que el modelo está intentando encajar la solución de una SQL Injection clásica a este tipo de vulnerabilidad. Una solución podría ser utilizar la clase SqlConnectionStringBuilder, de la que Chema habla en la segunda parte de su serie en el blog.

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

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

Al ser Llama un modelo general, se probó también con un par de modelos especializados en código. Por ejemplo, el modelo Code Llama de Meta (basado en Llama 2), es un modelo especializado en código y está entrenado, entre otros, con lenguajes C#. El análisis de este modelo (en su versión 13B) del código anterior fue muy similar a Llama 3.1, proponiendo como solución la consulta parametrizada que incluye los parámetros de usuario y contraseña en la SELECT de productos.

Figura 7: Análisis de vulnerabilidad de Connection String Injection

 con Code Llama 13B

El modelo CodeGemma 7B también propuso el uso de consultas parametrizadas y además sacar la cadena de conexión a la sección ConnectionStrings del fichero Web.config. Esto tampoco soluciona la vulnerabilidad, aunque se saque la cadena a otro sitio.

Figura 8: Análisis de vulnerabilidad de Connection String Injection

con CodeGemma 7B

Es cierto que descubre que hay una inyección, pero no acierta con el tipo, y por lo tanto la solución no es correcta, lo que hace que para este caso, tenga una bonita alucinación. Así que queda tarea que hacer para conseguir que estas vulnerabilidades se puedan detectar y corregir correctamente.

Saludos,

Autor: Fernando Gutiérrez Calderón

Contactar con Fernando Guitérrez Calderón

El amo de los datos

Ayer tuve una jornada interesante de transformación digital en Londres. Hablando de datos, ML, GenAI, arquitecturas RAG, y normalización de datos. Cosas habituales hoy en día en cualquier empresa. En uno de esos momentos en los que estaba escuchando, sobre casos de uso que que se iban a crear usando ML, el debate acabó una vez en los datos. El Catálogo, el Data-Fabric, el Data Wharehouse, Data Curation, la validación de la ingesta, los Data Streams, etcétera. Cosas habituales en la vida de la digitalización de empresas.

Figura 1: El amo de los datos

Para mí, eso fue el día a día cuando en al año 2016 tuve la responsabilidad de ser el Chief Data Officer de Telefónica y tuve que tomar muchas, muchas, muchas decisiones sobre estos temas que, a día de hoy que soy el Chief Digital Officer, siguen perdurando en nuestro trabajo diario. 

Estando en ese debate, mi cabeza viajo temporalmente a mis inicios con los datos. Cuando bajaba la calle Barcelona de Móstoles, pasaba por delante del Eco Móstoles, y me metía en un pequeño parque a medio terminar que se encontraba y se encuentra a espaldas de calle Libertad de Móstoles. Allí estaba uno de los locales de la Academia RUS de la que os he hablado muchas veces. Tendría yo 14 o 15 años e iba a mi clase de Informática diaria. A seguir aprendiendo a programar.

En aquellos años ya había dejado el BASIC y el Logo atrás, y estaba con con COBOL, SQL y MS/DOS. También tocaría aprender DBASE, C y Pascal, pero antes de ellos, mi paso era hacer códigos con la IDENTIFICATION DIVISION y la PROCEDURE DIVISON. Había que aprender a identar el código, usar muchas mayúsculas, y ser muy disciplinado en la forma de hacer programas con este lenguaje llamado COBOL.

Las clases a las que asistía de informática se multiplicaban en mi agenda, normalmente hacía tres cursos a la semana diferente, haciendo clases los lunes y miércoles, y los martes y jueves, y repitiendo algunas de 17:30 a 18:30 y de 18:30 a 19:30, y luego había algunos cursos que se daban los viernes y sábados. De los 12 a los 16 años fueron años en los que mi afición era programar, así que no me importaba pasarme dos horas cada día en la academia, e incluso quedarme los viernes y sábado. ¿Qué podría haber más divertido que eso? Además, de vez en cuando daba yo la clase, y me llevaba de maravilla con Bea, mi profesora muchos de esos años.

Nada de lo que aprendí en aquellos años fue en vano. Todo ese aprendizaje sigue en mí, cambiado, adaptado, y mejorado, pero como base sobre la que construí mucho de mi conocimiento futuro. Y ayer me acordé de la época de COBOL y el acceso a Datos para hacer cosas. En aquellos momentos, cuando pasé de BASIC a COBOL, entré en el mundo de las reglas de estilo y la programación estructurada con técnicas de diseño de software muy metódicas. Formas de hacer las cosas de manera industrial. El trabajo de programador como factoría de software. Dados unos requisitos, escribir código como si fueras una máquina tú.

Los programas de gestión, hechos con COBOL y datos almacenados en bases de datos o ficheros tenían siempre las mismas estructuras. Y todos mis primeros Menús eran siempre ALTAS, BAJAS, MODIFICACIONES y CONSULTAS. Tendía que definir las fuentes de datos, los tipos de datos que iba a utilizar, si eran ficheros, los accesos que serían Secuenciales (si eran en cinta), acceso aleatorio (si eran en cintas modernas con aceleración de rebobinado y avanzado) o de acceso directo (si el almacenamiento era en disco). O los tipos de datos que se iban a leer de las bases de datos, en forma de registros que había que procesar,  pintar por pantalla en listados, etcétera.

La programación era una ingeniería. Las cosas tenía una forma de hacerse. Había metodologías de desarrollo de software. Hablábamos de los modelos de solucionar cada uno de los problemas. Y teníamos guías de estilo de programación, nombres de variables, llamadas a procedimientos, factorización del software, etcétera, para hacerlo mantenible, aduitable, y permitir que cualquier código fuera tocado por cualquier programador de COBOL. Me encantaba saber que era una pieza de parte de una industria de desarrollo de software. Podría ser programador o mi sueño entonces, ser "Analista", para poder asignar las tareas a los programadores siguiendo las guías de desarrollo del software de una empresa. 

Podéis imaginaros lo que un niño de 14 o 15 años sentía cuando se veía ahí. Siento un analista de software. Metiendo líneas de código y jugando con los decimales como Richard Prior en Superman III, desde tu terminal. Identando tu código. Flipante.

Y os cuento todo esto, porque de aquella época también aprendi parte de la gestión de los datos que décadas después usé como Chief Data Officer en Telefónica. Y es que, allí, en aquellos años, me explicaron cómo la Banca creaba sus aplicaciones para preservar sus datos. Cómo los informáticos habían creado para COBOL una metodología de trabajo con datos basada en mantener el core más sagrado de la empresa, LOS DATOS, a salvo de malos programadores. Metiendo una capa de seguridad, metiendo una capa de protección. 

Y yo escuchaba atento. ¿Cuál sería el truco? ¿Cómo lo han hecho? ¿Cuál es el secreto?

No había mucha magia. O sí. Según se mire. 

Lo habían hecho otros informáticos que llegaron a interesarme tanto o más que los Analistas, se trataba de tipos más duros aún. Que tenían más poder porque protegían el activo más valioso de las empresas. De la poderosa industria bancaria. Los datos, que al final de día era dinero. Se trataba de los Administradores de Bases de Datos.

¡¡Buaahhh!

¡Qué pasada!

Resulta que había unos tipos que para que los Analista de Programación pudieran diseñar sus programas de ALTAS, BAJAS, MODIFICACIONES y CONSULTAS, con sus infinitos listados por pantalla y por impresora (no conté yo espacios ni nada para cuadrar listados en papel continuo de impresoras matriciales), estos Analistas tenían que hablar con los Administradores de Bases de Datos para que les disponibilizaran los datos que necesitaban utilizar para sus programas. Y ellos decidían cómo lo hacían.

Esto, tenía su ciencia. Porque no iban a dejar que cualquier Programador tocara cualquier dato, así que se dedicaban a crear VISTAS, VISTAS para Actualización de datos, y Tablas de solo lectura que disponibilizaban a los Analistas para que hicieran su aplicación de ABMyC sobre estas fuentes de datos. Los Analistas repartían las tareas a los Programadores, y la Factoría de Software de la empresa seguía produciendo sistemas de información para la empresa.

Si habéis leído esto, sabréis porque cuando llegué a la Universidad me centré en aprender todas las asignaturas de Bases de Datos. A aprender a hacer el diseño lógico y el diseño físico de las bases de datos. A aprender cómo funcionaban los Tablespaces, las p-codes de las consultas de bases de datos, a descubrir los detalles de las formas normales de Boyce-Codd, a aprender PL/SQL, T-SQL, hacer optimización de bases de datos y aplicaciones, etcétera. El resto, ya os lo sabéis, trabajé mucho con las bases de datos Oracle cuando salí de la Universidad, luego llegó el SQL Injection... y el resto es historia moderna, desarrollando mi perfil profesional en datos y hacking.

Pero ayer volví a ello una vez más, porque el debate nos llevaba a cómo preservar los datos y disponibilizarlos a los modelos. Hoy hablamos de Data Streams, de Gestores de Consentimientos para acceso a datos, de políticas y procedimientos de anonimización y pseudoanonimización, de consultas con algoritmos de cifrado homomórfico, de roles de seguridad, de las plantillas de cumplimiento regulativo, etcétera. 

Entonces, el Administrador de la Base de Datos era el "amo de los datos" y de todo eso. Y yo lo aprendí en una academia de barrio de Móstoles. Leyendo libros y deseando un día poder ser parte de esa Industria y la Ingeniería del Software. Flipante.  

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

El comodín del % que leakea los usuarios de tu web por usar un LIKE

Estos últimos días he estado jugando con el comodín del %, un viejo conocido de las técnicas de SQL Injection, ya que permite utilizarse para buscar una cadena sustituyendo uno o varios caracteres por ese carácter de %. Este comodín solo se usa en comparaciones basadas en LIKE, por lo que en una búsqueda de una cadena "a%" debería ser para buscar cosas como "albaca", "alacena" o "administrador". Una utilidad fantástica en bases de datos relacionales y consultas SQL.

Figura 1: El comodín del % que leakea los usuarios

de tu web por usar un LIKE

Curiosamente, jugando con las recuperaciones de contraseñas, me encontré con dos curiosidades en algunos sitios, que os quería compartir por aquí, y que afectó a una de nuestras webs internas, pero que me ha sorprendido ver lo común que es, y que os la dejo por aquí, ya que es un pequeño truco para hacer Hacking de Web Technologies.

Figura 2: Libro de Hacking Web Technologies en 0xWord de los autores:
Amador Aparicio, Chema Alonso, Pablo González, Enrique Rando y Ricardo Martín.

/

La primera es una curiosidad en el filtrado de datos de entrada en las direcciones de correo electrónico y los procesos de recuperación de contraseñas - que tienen que ver con lo que os publiqué ayer para recuperar una password con una dirección de e-mail que no es tuya. La segunda es ver cómo se puede utilizar ese comodín para extraer mediante enumeración todos los usuarios de una base de datos. Vamos a verlo.

Un comodín no filtrado en las direcciones de e-mail

Este es una curiosidad que me he encontrado en muchos filtros de protección frente a ataques de inyección, y se trata simplemente de que el carácter comodín está prohibido en los dominios de las direcciones de e-mail, pero no en los usuarios. Este es solo un ejemplo de los muchos donde, probando una dirección con % en el dominio da error el filtro, y en el usuario no lo da.

Figura 3: El % en el dominio falla

Figura 4: El % en el usuario no falla

Tener un % como parte de un usuario, aunque se pueda utilizar en el Identity Provider que utilices, es una muy mala idea siempre, por ser un carácter reservado en otros motores, así que no debería poder suceder lo que aparece ahí. 

Figura 5: AirBnB permite usar el % como usuario

del e-mail para recuperar la contraseña

Esto no es un fallo en sí mismo, pero sí una muy mala idea. La web de AirBnB, por ejemplo, permite utilizar ese carácter comodín en las direcciones durante el proceso de recuperación de la contraseña, lo que no parece una buena idea. De cualquier forma, insisto, no es un bug porque no permite usar ese carácter como un comodín, ya que aunque parece que existe la dirección lucas@gmail.com, no reconoce la dirección l%@gmail.com. Así que solo es eso, una pequeña mala idea.

Figura 6: El % no funciona como "comodín" porque lucas existe y l% no.

Sin embargo, te dice cuando una dirección de e-mail tiene cuenta (lucas)

y cuando una no "fasfas....." lo que es un "leak del login" en AirBnB.

Eso sí, el proceso de recuperación de contraseñas de AirBnB es "verbose" y tiene el "leak del login", ya que permite saber si la cuenta de e-mail está dada de alta o no en su base de datos, lo que permite saber si tú te has creado una cuenta su base de datos. Perfecta para nuestro proyecto de "Dirty Business Card".

El comodín % en el nombre de usuario como comodín

La curiosidad anterior es solo eso, una curiosidad - y para mí una pequeña debilidad -, pero lo peor es que se convierta en un bug de enumeración de usuarios, ya que, si ese % funciona como un comodín, la cosa es más peliaguda. Para ello solo hay que probar a ver si se puede saber si está funcionando o no con unas sencillas pruebas.

Figura 7: Mensaje de una dirección de e-mail que no existe

En la imagen anterior se puede ver que, introduciendo una dirección de e-mail sin poner ningún carácter % y que no existe en esta web, sale un mensaje de error que informa de que no hay ningún usuario con esa dirección de e-mail.

Figura 8: Aquí se ve que no existe ningún e-mail comenzando por aaaaaa

En la Figura 8 se puede ver que el carácter % no genera ningún error de formato en la dirección de e-mail, como sucedía en el caso anterior con la web de AirBnB. El comodín % pasa el filtro. Lo que no tenemos aún es la garantía de que funcione realmente como un comodín. Sin embargo, probando una dirección común de gmail comenzando por "a", vemos que da un mensaje correcto.

Figura 9: Existe un usuario que comienza por a del dominio gmail.com

Esto quiere decir que el carácter % está funcionando. Hay algún correo que comienza por "a" y tiene el dominio @gmail.com. El resto es hacer un árbol de despliegue como en el ejemplo de Blind LDAP Injection, e ir desplegando las direcciones que dan positivo, en este caso... la segunda letra que funcionaba era la "l", así que existe alguna dirección comenzando por "al" en el dominio @gmail.com.

Figura 10: Se despliega el username carácter a carácter

(con el % en lugar del * que se usa en Blind LDAP Injection)

Esta situación es un tanto curiosa, ya que índica que el programador a utilizado una claúsula LIKE en la búsqueda y verificación de los usuarios o direcciones de e-mail completas, lo que no parece lo más correcto y seguro en ninguna aplicación.

Figura 11: Ejemplo de uso de LIKE y % en SQL

Si estás haciendo tu propio sistema de gestión de usuarios, intenta no recrear procesos que son conocidos y estudiados ya hace muchos años, porque puedes acabar creando problemas de seguridad que se conocen desde hace veinte años.

¡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

Un RFD (Remote File Downloading) "protegido" por ofuscación

Hace no demasiado, cuando recordaba las charlas que había dado con mi amigo Palako por todo el mundo de hacking, me vinieron las demos de RFD (Remote File Downloading) que contamos en Noruega o Washington D.C. en la que utilizando diferentes ataques de SQL Injection íbamos descargando ficheros del servidor web, junto con otras técnicas de LFI (Local File Inclusion) o RFI (Remote File Inclusion).

Figura 1: Un RFD (Remote File Downloading) "protegido" por ofuscación

En todas estas técnicas, la idea es siempre la misma, ver cómo utilizar código Server-Side para que al final se acceda a un fichero que está en el servidor web y nos lo entregue vía web browser. Ni sé cuantos proyectos de Ethical Hacking a empresas o pentesting a aplicaciones web se han terminado con una sola técnica de estas, ya que en el momento en el que te puedes descargar ficheros del servidor vas a ir a por los "juicy files" que te van a entregar las configuraciones de acceso a la base de datos, los usuarios del servidor web, los datos de la DMZ por las configuraciones de red, etcétera.

Figura 2: Hacking Web Applications: Client-Side Attacks

De hecho, cuando te enfrentas a una auditoría de un sitio web, es una de las cosas que primero buscas. SQL Injection, Blind SQL Injection, errores verbose que te dan información jugosa, Client-Side Attacks como XSS/CSRF/SSRF y descarga de ficheros. Por eso los pentesters en los Red Team, en los equipos de QA de seguridad y en los equipos de Ethical Hacking, estas disciplinas se entrenan con fuerza. En muchos CTFs de las CONs, conseguir una bandera es descargar un fichero - o muchos - del servidor web. 

Un RFD protegido por ofuscación

El caso que os voy a contar es uno de muchos, pero me hizo gracia encontrármelo de casualidad, ya que, en lugar de hacer las cosas bien, han puesto un parche de oscuridad que seguro que a los bots, y a los menos expertos evita, pero desde luego no a ningún pentester profesional. 

Figura 3: Aplicación PHP que descarga ficheros

En esta implantación, el código que te permite acceder a los ficheros es un fichero PHP que devuelve un fichero PDF o un PNG. Hasta aquí tiene toda la pinta de ganarse la atracción de cualquier auditor de seguridad profesional, pero lo que más llama la atención es que utiliza dos parámetros para conseguir la descarga. El primero de ellos un hash y el segundo un Ln.

Figura 4: Analizando el hash con Hash Analyzer

Lo primero que puedes pensar es que se trata de un esquema tipo cucharón, donde el programa tira un Select contra una base de datos, y puedes intentar hacer un UNION para que devuelva un Path al fichero que tú quieras. Es un esquema típico de RFD, pero no era así. Analizando el Hash se ve rápidamente que era un BASE64, así que se puede decodificar fácilmente.

Figura 5: Libro de Hacking Web Technologies 2ª Edición en 0xWord de
Chema Alonso, Enrique Rando, Amador Aparicio, Pablo González y Ricardo Martín

Al decodificarlo, se ve que aparece una ruta a un fichero, pero que cuenta con unos caracteres de más al inicio, y otros caracteres del más al final, como si llevara más información de la que es necesaria en esa ruta. 

Figura 6: Decodificando el hash. Aparecen caracteres antes y después de la ruta

Tras probar las cosas que hay que probar, es decir, probar el Hash original con valores aleatorios de LN se observa que no descarga nada y salen todos los ficheros vacíos, pero cuando se pone un LN+1 se descarga un fichero vacío con un nombre que tiene una letra más que el nombre del fichero correcto, y eso hizo saltar el dato final.

Figura 7: con LN+1 busca un fichero con extensión pngo que no existe

Al principio confundí los caracteres de inicio como parte del Path pero viendo este comportamiento y contando LN caracteres hacia atrás desde .png y ver que acaba en la barra de /home, es fácil asumir que el valor de LN es el límite de caracteres que se debe tomar del string de caracteres que viene en el HASH Base64 del parámetro de llamada. Pero... ¿para que sirve la cadena de  caracteres al inicio y la cadena de caracteres al final?

Figura 8:Codificando la ruta de /etc/passwd con los caracteres sobrantes

Para probar si esta suposición es correcta y si tenemos que hacer algo más con los caracteres al inicio y al final, basta con hacer una sencilla prueba. Vamos a dejar los caracteres al principio y los caracteres al final tal y como están, y vamos a meter la ruta al /etc/passwd en el medio. Después vamos a codificar en BASE64 esta cadena. Y ahora hacemos la llamada al programa PHP poniendo este Hash como parámetro uno y como parámetro LN al valor de lenght(/etc/passwd), y vemos si el fichero descarga y que hay dentro.

Figura 9: Fichero /etc/passwd descargado

Como se puede ver, tenemos el fichero /etc/passwd descargado, y haciendo lo mismo todos los ficheros del servidor a los que tenga acceso el usuario del servidor web - que no es root -. Tras unas cuantas pruebas, y ver que con ese sencillo algoritmo era posible descargar todos los ficheros, la respuesta de para qué sirven esos caracteres al inicio y al final es sencillo. Son "Tokens de ofuscación" que el programador ha metido para que no le sea tan fácil a un script kiddie o a un bot automático descargar los ficheros.

Figura 10: Probando con /etc/hosts y los mismos caracteres sobrantes

Realmente es una solución inútil, porque cualquier pentester profesional va a encontrarlo fácilmente, y si tienes que hacer una aplicación web, más vale que conozcas las técnicas de hacking de aplicaciones web, y que sepas cómo desarrollar de forma segura, porque lo que te puede parecer una buena idea, puede ser un desastre de seguridad.

¡Saludos Malignos!

Chema Alonso (Contactar con Chema Alonso) (Consigue Tempos gratis con ESET)

Chema Alonso en MyPublicInbox

WordPress: Role-Based Database Connection Strings

Una aplicación web, o un framework CMS como WordPress, utiliza un repositorio de datos en un motor de bases de datos, en concreto MySQL. Para eso, durante el proceso de instalación se crea un usuario del motor de bases de datos que es el que tiene el control de todas las tablas dentro de la base de datos y puede hacer con ellas lo que le plazca. Es decir, puede insertar, modificar o borrar registros en todas y cada una de las tablas sin ninguna limitación.

Figura 1: Role-Based Database Connection Strings

Las acciones que ese usuario de MySQL realiza dentro de ellas, como por ejemplo dar de alta un nuevo registro mediante una instrucción INSERT que represente a un nuevo usuario del CMS, están limitadas por el código de la propia aplicación, es decir, el código PHP del motor WordPress. 

Esta es una situación muy habitual en todas las aplicaciones web, y en especial en la mayoría de los frameworks de Internet, y tiene implicaciones en la seguridad porque, si un atacante es capaz de encontrar un bug de SQL Injection en cualquiera de los códigos de WordPress, ya sea en el core del framework, en un plugin o en un tema, implicaría directamente el control de todas las tablas y su contenido que están en MySQL. En la charla de Hardening Wordpress Like a Hacker lo explico en detalle.

Figura 2: Hardening WordPres like a Hacker

Esto se debe a que WordPress no utiliza un sistema de Role-Based DB Connection Strings, es decir, que todos los usuarios de WordPesss - ya sea un usuario anónimo o el administrador - utilizan la misma cuenta de MySQL en la cadena de conexión para ejecutar las consultas SQL, algo que debería evitarse en un entorno fortificado.

De esto ya os hablé hace tiempo, y aunque lo suyo es que cada usuario de la aplicación web tuviera su representación en un usuario de la base de datos, a veces por gestión de cuentas volátiles, por licencias en algunos modelos de venta de algunos motores de base de datos, por la implicación que cuentas del motor puedan tener dentro del resto del sistema informático - por ejemplo, motores integrados en Active Directory - o por complejidad en el desarrollo no se hace.  En esos casos, habría que diseñar un modelo de Role-Based Database Connection Strings.

En el gráfico que os pintaba en el artículo de hace unos años, os hablaba de que se deberían reconocer los roles principales de la aplicación, en este caso del motor de WordPress, y crear un usuario en MySQL por cada uno de esos roles. Después, se deberían entregar permisos sobre las tablas a cada uno de esos usuarios teniendo en cuenta que solo deberían tener acceso a lo estrictamente necesario para el cumplimiento de su rol.

Figura 3: Esquema de Role-Based Database Connections

Después, cuando se produce el proceso de login de un usuario de WordPress en el framework, el sistema debe ser capaz de reconocer su rol en WordPress y ejecutar las consultas SQL al motor MySQL con una DB Connection que haya utilizado el usuario adecuado de su rol, consiguiendo limitar el impacto que pueda tener un posible bug de SQL Injection que fuera descubierto en un plugin, un tema o en el core del sistema.

Figura 4: Cuando sea un usuario loggado se utiliza un usuario privilegiado en MySQL

Como prueba de concepto, en los artículos de WordPress in Paranoid Mode nosotros hicimos una modificación al sistema de conexiones a la base de datos para que el framework diferenciara algo muy básico: Entre un usuario de WordPress que ha hecho login, y un visitante anónimo que no ha hecho login en WordPress.

Figura 5: Cuando sea un usuario anónimo se utiliza un usuario sin privilegios en MySQL

De esta forma, cuando se lance una consulta al motor MySQL esta utilizará un usuario distinto de MySQL, siendo el segundo un usuario sin ningún privilegio de INSERT, UPDATE o DELETE en las tablas que WordPress utiliza en MySQL.

Figura 6: Definición de distintas cadenas de conexión

El funcionamiento es muy sencillo, cuando se va a realizar la conexión a MySQL desde WordPress, miramos a ver si el usuario está logado o no en el framework y se elige uno u otro usuario de MySQL para tirar la cadena de conexión.

Figura 7: Comprobación de si usuario está logado o no en la PoC

Toda la información la tenéis en el paper y en los diferentes artículos que he ido recogido, pero este vídeo de aquí os enseña cómo funciona en nuestra prueba de concepto.

Figura 7: WordPress Role-Based Database Connection Strings to MySQL

Para que tengáis toda la información disponible, os dejo aquí la lista de recursos sobre Hacking, Hardening y Seguridad en WordPress que he ido publicando en el último tiempo por aquí.

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

Saludos Malignos!