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

ChatGPT hace código con SQL Injection, CoPilot mete Security Bugs y los programadores que usan Asistentes AI hacen más "Buggy Code"

Eso es lo que dice el paper publicado el 16 de Diciembre por investigadores de la Universidad de Stanford donde han hecho un experimento muy interesante con programadores para saber si activarles asistentes de Inteligencia Artificial para ayudarles a hacer código - como el caso de Copilot o ChatGPT - y ver después si su código es más o menos inseguro, corrector o incompleto.

Figura 1: ChatGPT hace código con SQL Injection, CoPilot mete Security

Bugs y los programadores que usan Asistentes AI hacen más "buggy code".

El resultado que arroja el artículo académico, titulado "Do users write more insecure code with AI assistants?" es que, a día de hoy, el código es más inseguro cuando los programadores se confían en el asistente de AI y le dejan meter más código, lo que lleva a que haya más bugs. 

Figura 2: Do users write more insecure code with AI assistants?

Probar esto es tan fácil como hacer una prueba con ChatGPT para ver si se come un SQL Injection de libro en un procedimiento en PHP para autenticar una página web, tal y como veis a continuación.

Figura 3: Código PHP con bug de SQL Injection generado por ChatGPT

En el código no ha filtrado ninguno de los datos de entrada que va a introducir en la consulta un bug de SQL Injection, y ha hecho un programa que funciona, pero que no tienen ninguna medida de protección y seguridad del código para evitar SQL Injection. Eso es que no se ha leído aún nuestro libro.

Figura 4: Libro Hacking de Aplicaciones Web: SQL Injection
de Enrique Rando y Chema Alonso

Que Copilot mete bugs, ya lo sabíamos, como vimos en el artículo de nuestro compañero Fran Ramírez donde vimos tres ejemplos en Python de código inseguro, como por ejemplo código para crear un fichero temporal usando funciones inseguras, como en este ejemplo.

Figura 5: Ejemplo inseguro de Copilot para fichero temporal.

Lo que viene a demostrar este paper no es si los asistentes de AI generan "buggy code", que ya sabemos que sí, sino si el usarlos hace que los programadores incrementen el número de bugs, errores, códigos inseguros, etcétera que los programadores que no los usan. Y el resultado es que sí. Que para 5 experimentos, el código seguro generado por programadores que no usaban asistentes AI era del 79% mientras que el de los programadores con asistente AI era del 67%.

Figura 6: Con AI, código más inseguro que sin AI

Por supuesto, cada programador es único, y depende mucho de lo que haga la persona con su código, pero para 5 ejercicios de seguridad, que tienen que ver con cifrar datos, firmas digitalmente, hacer consultas SQL o meter un directorio en un sandbox, el resultado era el anterior. 

Figura 7: Resultado para los ejercicios. Azul con AI, Marrón sin AI

Por supuesto, estamos al inicio del uso de asistentes de AI para programar, pero esto en dos años estará más que evolucionado y llegará un momento donde, probablemente, se alcanzará la Paridad Humana en programar, y entonces ya no habrá vuelta atrás, y programar sin asistentes de AI será una temeridad, pero por ahora, estamos en una fase mucho más temprana, así que cuidado con tu código.

¡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

La importancia de los laboratorios para aprender hacking y un WAF como modSecurity a prueba

Llevo muchos años siendo docente en diferentes universidades con temáticas de ciberseguridad. He tenido la suerte de poder conocer a muchos alumnos, de poder motivar a muchos de ellos y de poder hacerme amigos de mucha gente con un gran potencial. Para mí ha sido y es un orgullo poder decir que he tenido muchas horas de vuelo en las clases y que creo que un porcentaje alto de alumnos han estado contentos conmigo y con lo que he podido transmitirles.

Figura 1: La importancia de los laboratorios para aprender

hacking y un WAF como modSecurity a prueba

Siempre he hablado de la importancia que tiene que un alumno no se limite a observar al profesor, cuando éste les muestra un ejemplo para afinar el conocimiento. El alumno debe actuar y poner a prueba lo que le cuentan, lo que le muestran, lo que le enseñan. Es importante que los alumnos levanten sus contenedores de Docker, sus máquinas virtuales, sus entornos privados para probar sobre sus recursos lo que les enseñan.

Figura 2: Libro de Docker: SecDevOps de
Fran Ramírez, Rafael Troncoso y Elías Grande

Muchos me habrán escuchado decir que no vale de nada que yo lo haga, que yo ya lo hice muchas veces, que tienes que probarlo tú, hacer el conocimiento tuyo, hacerlo interno, entenderlo a base de encontrarte problemas cuando al profesor no se le presentaron dichos problemas. Creo que en algún minuto de este video se puede ver justo lo que comento.


Figura 3: Pablo González en CiberCamp 2018: Aquellos años locos
No creáis que hoy me he levantado nostálgico o que voy a dejar algo que me llena tanto como seguir conociendo al talento, al potencial que hay detrás de cada historia que se sienta a ver lo que éste joven les tiene que contar. Solo quería dar pie al artículo técnico que quería contar hoy y es que hoy quiero hablar de la importancia de montarte tus laboratorios y aprender.  Hoy quiero dar respuesta a algunas consultas que me llegan y que me preguntan por mi buzón de MyPublicInbox por algún consejo para aprender, para iniciarse, para entrar en este mundo tan apasionante, por consultas de alguno de mis libros, etcétera. 

Figura 4: Libro de Hardening de Servidores GNU/Linux 4ª Edición

(Revisada y Ampliada) de Carlos Álvarez y Pablo González en 0xWord

Muchos no saben que simplemente con su curiosidad y con sus ganas ya están dentro de este mundo.  Aprovechando que acaba de salir la 4ª Edición del libro de Hardening Servidores GNU/Linux donde yo participo, hoy quiero hablar de ModSecurity, quiero montarme mi laboratorio con dos, tres máquinas y mostrar cómo sería eso de “móntate tu entorno y prueba, aprende”. Lo primero es tener claro que queremos montar:

- Una máquina Ubuntu a la que instalaremos modsecurity. 

 

- Una máquina Kali Linux 2020 a la cual llamaremos “la mala”.

- Un entorno web vulnerable al que ayudaremos a proteger.

Hay que tener en cuenta que poner un WAF (Web Application Firewall) no es exactamente solventar los problemas de seguridad. Los problemas de seguridad del entorno web seguirán estando ahí, aunque el WAF nos proteja de ciertas situaciones. Por esto, es interesante que en las auditorías web se prueben con y sin WAF activado. La falsa sensación de seguridad que nos puede dar un WAF puede ser un fallo de concepto de nuestra apreciación.

Instalando ModSecurity: Manos a la obra

Vamos a instalar ModSecurity. Haremos un resumen y una instalación sencilla, ya que el proceso se puede complicar hasta límites, en algunos casos, insospechados. A continuación, se resumen el proceso de instalación de un Apache con     :

- Instalar apache2 y modsecurity a través de Ubuntu con apt install. Ejemplo: apt install apache2 libapache2-mod-security2. 

 

- Tras instalar apache2 y la librería de modsecurity hay que verificar que modsecurity está habilitado. Para ello se puede hacer uso de apachectl -M. con esta instrucción podemos verificar que modsecurity se encuentra instalado, incluso podríamos filtrar con un grep para encontrar entre todo lo disponible.

Figura 5: Instalación de Apache

- Encontramos el módulo security2 con el valor “(shared)”. 

 

- Si es así, parece que todo ha ido bien, toca configurar modsecurity.

La configuración de modsecurity se puede llevar a cabo a través del fichero /etc/modsecurity/modsecurity.conf. Hay varias cosas que debemos mirar y revisar en este fichero que vamos a ver a continuación.

Figura 6: modsecurity.conf

La primera regla y la más importante es SecRuleEngine que habilita modsecurity. Después, modsecurity tiene un conjunto de reglas por defecto, las cuales se encuentran en el directorio /usr/share/modsecurity-crs. Es altamente recomendable descargar reglas actualizadas desde repositorios de Github, con ejemplos para aprender. 

Un ejemplo de repositorio a tener localizado es el de SpiderLabs con Owasp-modsecurity-crs. Ahora se conoce como OWASP Modsecurity Core Rule Set. Para poder descargarlo se puede hacer uso de git clone. Una vez descargado se puede copiar el fichero de configuración a /usr/share/modsecurity-crs/crs-setup.conf. 

Figura 7: modsecurity core rule set en Git Hub

Ahora se puede configurar dichas reglas editando el fichero security2.conf que se encuentra en el directorio /etc/apache2/mods-enabled. Debemos añadir un par de IncludeOptional en el fichero security2.conf.

o IncludeOptional /usr/share/modsecurity-crs/*.conf. 

 

o IncludeOptional /usr/share/modsecurity-crs/rules/*.conf.

Una vez hecho todo esto, debemos reiniciar el servicio de Apache2 y tendremos listas las nuevas reglas descargadas y ModSecurity. 

Probando ModSecurity: Entorno con dos máquinas

Lo primero es definir qué tendremos en la máquina Ubuntu, en este caso tenemos una aplicación web vulnerable y nuestro apache con la librería de modsecurity. Hemos montado un DVWA sobre Ubuntu, la instalación se puede encontrar fácilmente. Nuestro modsecurity protegerá al DVWA y se podrá estudiar el funcionamiento del WAF in situ. En este ejemplo vamos a utilizar uno de los ataques a aplicaciones web más conocidos y del que Chema Alonso escribió un libro junto con Enrique Rando: Los ataques de SQL Injection.

Figura 8: Libro Hacking de Aplicaciones Web: SQL Injection 3ª Edición
de Chema Alonso y Enrique Rando en 0xWord

 

Esto es algo vital, enfrentarse a las situaciones, a los entornos, es una forma interesante de aprender y encontrarse con la realidad, por compleja que pueda parecernos. DVWA (Damn Vulnerable Web Application) es un entorno de pruebas para practicar y entender las vulnerabilidades web. Una de las cosas interesantes de este entorno es que se puede ver el código web con diferentes niveles. Es decir, si tenemos un SQL Injection se puede ver en diferentes dificultades, diferentes errores en el código que introducen en la aplicación el SQL Injection. Sin duda, interesante para aprender.

Figura 9:  Aplicación DVWA

Con la configuración de DVWA en modo fácil, en la última versión hay 4 niveles, introduciendo una comilla veremos como se genera un error de sintaxis. Si aplicamos un ‘or’1’=’1 veríamos los datos de la tabla a la que se consulta. Seguramente sea el SQL Injection más sencillo y más intuitivo. Perfecto para aprender.

Figura 10: Resultado del SQL Injection Level 1

Ahora habilitamos modsecurity a través del fichero /etc/modsecurity/modsecurity.conf. Habilitamos la opción SecRuleEngine y la ponemos a ON. A partir de aquí todo el tráfico pasará por las reglas de modsecurity que descargamos y añadimos en los apartados anteriores. Ahora veremos que cuando se intenta llevar a cabo la misma operación el resultado es un “forbidden”.
 

Figura 11: modsecurity funcionando

Una forma de aprender cómo funcionan, no solo los ataques de SQL Injection, sino todas las técnicas de Hacking Web Technologies, e incluso se pueden ver los ataques Client-Side que pasan por un servidor web, y como un WAF puede ir trabajando sobre ellos para protegernos es éste. Aplicando a diferentes tipos de ataques en plataformas como DVWA se puede aprender y mucho. Siempre pensando en el ataque y en la protección. En la vida real te encontrarás protecciones y tendrás que conocer cómo funcionan para poder aplicar bypasses. Eso lo dejamos para otra historia.

Saludos,

Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell”, "Pentesting con Kali Silver Edition" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox

 Contactar con Pablo González