1. Introducción – Blind SQLi

 

En esta práctica se va a tratar en profundidad el funcionamiento de vulnerabilidades tipo inyección Blind SQLi. Para ello se va a crear desde cero una web en PHP vulnerable a Blind SQLi, se va a explotar la vulnerabilidad de manera manual y semiautomatizada, y finalmente se va a solucionar mediante parches de código que saniticen correctamente los parámetros de entrada.

 

2. Implementación de un entorno web utilizando la tecnología PHP.

 

Se va a llevar a cabo la creación del entorno de pruebas Blind SQLi. La base de datos tendrá una estructura similar a la que se muestra a continuación:

Fig. Detalle estructura BBDD.

 

Para dar comienzo a este ejercicio, vamos a realizar la instalación de XAMPP en nuestra máquina con S.O. Windows 11.

Fig. Web oficial Xampp.

 

Una vez realizada dicha instalación, vamos a activar el servidor Web Apache (que incluye PHP) y el servidor MySQL que será el encargado de albergar la BBDD.

Fig. Detalle arranque servidor web apache y servidor BBDD MySQL.

 

Una vez realizado lo anterior, accedemos a la interfaz web de “phpMyAdmin” a través del botón “Admin” de MySQL, para montar la BBDD.

Fig. Detalle acceso phpMyAdmin.

 

A continuación, se muestran las instrucciones SQL a ejecutar para el montaje de la BBDD.

Fig. Detalle comandos SQL montaje BBDD, tablas y columnas.

 

Como se observar en las siguientes capturas, la BBDD ha sido creada satisfactoriamente, así como sus tablas y columnas.

Fig. Detalle de la BBDD prac1.

Fig. Detalle de la BBDD prac1.

 

Así pues, cabe destacar que:

• Para el campo “Password” en la tabla “Users”, he puesto “VARCHAR(255)” con la perspectiva de que debería ser suficiente para almacenar un hash de contraseña generado, por ejemplo, mediante la función “password_hash” de PHP.
• Para el campo “AccountId” he asumido que es una cadena.
• Para el campo “Datetime” en la tabla “News”, se utilizará el valor por defecto “CURRENT_TIMESTAMP” que insertará la fecha y hora actuales cuando se cree una nueva fila.

Llegados a este punto, deberemos tener un usuario de MySQL con los permisos adecuados para operar sobre la BBDD creada (prac1). Es importante que este usuario no sea “root” y que esté limitado exclusivamente al uso de esta BBDD, para salvaguardar los principios de la ciberseguridad.

A continuación, se muestran las instrucciones SQL a ejecutar para llevar a cabo la creación del usuario con los privilegios correspondientes sobre la BBDD “PRAC1”.

Fig. Detalle creación usuario con privilegios sobre BBDD prac1.

 

3. Creación de una página para mostrar una noticia en concreto a través de un parámetro denominado «id».

 

El objetivo es que el parámetro”ID” sea consultado mediante el método HTTP GET, y sea vulnerable a una inyección BLIND SQL, pero no a una inyección SQL de otro tipo.

La aplicación interactuará sólo con la tabla “News” de la base de datos.

A continuación, se muestra el código fuente comentado detalladamente de la aplicación web programada, y a la que hemos llamado “prac1.php”.

Fig. Detalle del código fuente de “prac1.php”.

 

Como se ha indicado, el código es intencionalmente vulnerable a Blind SQL Injection mediante la medición del tiempo en la consulta SQL. De este modo, un atacante podría saber si un ID de noticia específico existe basándose en el tiempo de respuesta. Sin embargo, la información detallada de la noticia solo se recupera si se detecta que la noticia existe, y esta segunda consulta se realiza de manera segura utilizando sentencias preparadas.

A continuación, creamos una noticia en la BBDD y por defecto se crea bajo el ID 1.

Fig. Detalle de la inserción en la BBDD prac1 de la noticia a mostrar.

 

En la siguiente captura se observa que la noticia se ha creado correctamente y puede visualizarse bajo el ID 1.

Fig. Detalle de la noticia contenida en el identificador “ID” 1.

 

A continuación, procedemos a asignar a la noticia el ID número 7, en lugar del 1. Esto es únicamente por no poner la noticia en el primer ID generado y tener que encontrarla más adelante con las pruebas manuales.

Fig. Detalle del cambio de en la BBDD prac1 del ID de la noticia.

 

En la siguiente captura se observa que la noticia puede visualizarse bajo el ID 7.

Fig. Detalle de la noticia contenida en el identificador “ID” 7.

Llegados a este punto ya podemos dar por finalizado esto y proseguir con el siguiente punto.

 

4. Demostrar de forma manual cómo la aplicación es vulnerable a blind SQL pero no lo es a una SQLi de otro tipo.

• A continuación, damos respuesta a la primera parte del ejercicio de demostrar manualmente la vulnerabilidad blind SQLi de la aplicación.

La vulnerabilidad Blind SQL Injection se encuentra en las siguientes líneas:

$sql = «SELECT EXISTS(SELECT 1 FROM News WHERE Id = $id AND SLEEP(2))»;

$stmt = $pdo->query($sql);

Este fragmento de código introduce un retraso condicional “(SLEEP(2))” en la consulta SQL, que se activa si la condición “WHERE Id = $id” se cumple. Esto quiere decir que si un ID existe en la tabla “News”, la consulta SQL hará que el servidor espere 2 segundos (2000 milisegundos) antes de continuar.

Para comprobar la vulnerabilidad se prueba con un ID inválido y con un ID válido.

• Prueba con un ID inválido.

Fig. Detalle de los milisegundos que tarda en cargar la página con el ID correspondiente.

 

Como la respuesta es rápida y no hay un retraso significativo, quiere decir que la consulta SQL con el retraso no se activó, lo cual es consistente con el comportamiento esperado de una vulnerabilidad Blind SQL Injection.

• Prueba con un ID válido.

Fig. Detalle de los milisegundos que tarda en cargar la página con el ID correspondiente.

 

Como la respuesta tarda hasta 2 segundos, lo cual es un retraso significativo, quiere decir que la consulta SQL con el retraso se activó, lo cual es consistente con el comportamiento esperado de una vulnerabilidad Blind SQL Injection, que indica que ese elemento existe en la BBDD.

Así pues, la diferencia en el tiempo de respuesta entre un ID existente y uno inexistente puede ser utilizada por un atacante para averiguar si un ID específico está presente en la base de datos.

Para llevar a cabo una mejor investigación, a continuación se muestra cómo la aplicación es vulnerable a un Blind SQLi con un payload específico.

Ante un ID no existente en la BBDD el tiempo de respuesta continua siendo ínfimo.

Fig. Detalle de los milisegundos que tarda en cargar la página con el ID correspondiente.

 

Sin embargo, ante un ID existente en la BBDD el payload en cuestión hace que la respuesta llegue a tardar los 10 segundos que se le ha ordenado ejecutar a la aplicación mediante la inyección de la función “SLEEP(10)”.

Fig. Detalle de los milisegundos que tarda en cargar la página con el ID correspondiente.

 

De esta manera ha quedado demostrado de forma manual la vulnerabilidad existente de Blind SQLi.

• En este punto se procede a mostrar cómo la aplicación no es vulnerable a un SQLi “normal”, es decir, que no sea del tipo “blind”. Para ello se hace uso de algunos de los payloads presentes en los recursos del aula de la asignatura, de manera adaptada a la aplicación en cuestión.
  • Payload: ‘ OR ‘1’=’1

Fig. Detalle de inyección insatisfactoria de SQLi normal.

• • Payload: ‘OR username=’jromo

Fig. Detalle de inyección insatisfactoria de SQLi normal.

• • Payload: Jromo’–

Fig. Detalle de inyección insatisfactoria de SQLi normal.

• • Payload: Jromo’ UNION SELECT Title, Body, Datetime FROM News WHERE ‘1’=’1

Fig. Detalle de inyección insatisfactoria de SQLi normal.

• • Payload: %271%27%20ORDER%20BY%201–

Fig. Detalle de inyección insatisfactoria de SQLi normal.

• • Payload: ‘ OR 1=1 —

Fig. Detalle de inyección insatisfactoria de SQLi normal.

• • Payload: %271%27%20UNION%20SELECT%20@@version—

Fig. Detalle de inyección insatisfactoria de SQLi normal.

• • Payload: ‘ AND 1=1 —

Fig. Detalle de inyección insatisfactoria de SQLi normal.

 

Como se ha podido observar, con los payloads propios de SQLi normales no se obtienen errores ni información propia que pueda llegar a propiciar un SQLi. De esta manera queda demostrado de forma manual que la aplicación no es vulnerable a SQLi normal.

 

5. Auditar la seguridad de la aplicación creada utilizando “SQLMap”, “The Mole” y “jSQL Injection”.

 

• SQLMap.

Se trata de una herramienta de prueba de penetración de código abierto, apoyada por una amplia comunidad de seguridad, que automatiza el proceso de detección y explotación de vulnerabilidades de inyección SQL en aplicaciones web. SQLmap puede realizar desde simples detecciones de inyección hasta tomar control de bases de datos completas, soportando varios tipos de inyecciones SQL, incluyendo inyecciones basadas en errores, ciegas (blind), basadas en tiempo, entre otras. También es capaz de enumerar bases de datos, tablas, columnas, y datos, así como ejecutar comandos del sistema operativo en bases de datos que lo permitan. Cabe destacar que la herramienta viene instalada por defecto en Kali Linux.

A continuación, se muestra la auditoria realizada con este herramienta a la aplicación web que nos atañe en este ejercicio.

Fig. Detalle de la ejecución de SQLMap.

 

A continuación, realizamos un volcado completo de la BBDD prac1 para ver si obtenemos los resultados previstos.

Fig. Detalle de la ejecución de SQLMap.

 

De los resultados que nos arroja la herramienta SQLMap podemos observar que, efectivamente, la aplicación solo es vulnerable a blind SQL injection. Del mismo modo se puede observar cómo se han obtenido todos los datos de la base de datos prac1.

 

• The Mole.

Es una herramienta diseñada para la explotación automatizada de vulnerabilidades de inyección SQL en sitios web. Requiere simplemente una URL que sea vulnerable y un string válido dentro del sitio para iniciar su proceso de detección y explotación. La herramienta es capaz de realizar ataques tanto con técnicas de unión como con consultas basadas en booleanos. Se opera a través de una interfaz de línea de comandos, y ofrece a los usuarios una forma sencilla de especificar comandos para diversas acciones. Además, facilita la auditoría de sitios web en busca de vulnerabilidades de inyección SQL de manera eficiente y automatizada.

Las características destacadas de The Mole son:

• • Soporte de bases de datos como MySQL, PostgreSQL, SQL Server y Oracle.
  • Una interfaz de línea de comandos intuitiva.
  • Funciones de autocompletado para comandos, argumentos de comandos, así como nombres de tablas y columnas en las bases de datos.
  • Desarrollo compatible con Python 3.
  • Automatización en la explotación de vulnerabilidades de inyección SQL, aprovechando técnicas de unión y booleanas.
  • Capacidad para explotar automáticamente inyecciones SQL ciegas.
  • Funcionalidad de explotación sobre parámetros GET, POST y COOKIES.
  • Soporte para la implementación de filtros que ayudan a evadir reglas de IPS/IDS, incluyendo filtros genéricos y la opción de crear nuevos fácilmente.
  • Capacidad para explotar inyecciones SQL que retornan datos binarios.
  • Un intérprete de comandos que facilita la operación y uso de la herramienta.

En la siguiente captura se muestra su proceso de instalación en Kali linux.

Fig. Detalle de la instalación de TheMole.

 

A continuación, se muestra la auditoria realizada con este herramienta a nuestra aplicación web.

Fig. Detalle de la ejecución de TheMole.

 

Exportamos los resultados en formato XML como se observa en la siguiente captura.

Fig. Detalle de la exportación de resultados de TheMole.

 

De los resultados que nos arroja la herramienta podemos observar que, efectivamente, la aplicación es vulnerable a blind SQL injection y que se han obtenido todos los datos de la base de datos prac1.

 

• jSQL Injection.

Es una herramienta de inyección SQL automática que se utiliza para identificar y explotar vulnerabilidades de inyección SQL en aplicaciones web. Es una herramienta ligera que viene con una interfaz gráfica de usuario (GUI) y, además, soporta varias estrategias de inyección, incluyendo inyecciones basadas en errores, inyecciones ciegas, y basadas en tiempo. También puede usarse para enumerar nombres de bases de datos, nombres de tablas, columnas y datos.

Cabe destacar que no se ejecuta mediante comandos de línea de comandos, sino que tiene una interfaz gráfica en la que se debe ingresar la URL objetivo y seleccionar las opciones para realizar la inyección. Una vez que inicias la herramienta, puedes simplemente ingresar la URL y dejar que la herramienta haga su trabajo.

A continuación, se muestra la auditoria realizada con este herramienta a nuestra aplicación web.

Fig. Detalle de la ejecución de jSQL injection.

 

De los resultados que nos arroja la herramienta podemos observar que, efectivamente, la aplicación es vulnerable y que se han obtenido todos los datos contenidos en la base de datos prac1.

 

6. Automatizar la extracción de datos mediante un script que explote la vulnerabilidad blind SQL.

 

Primeramente, para poder extraer datos de la tabla “users” deberemos introducir datos en dicha tabla. Procedemos manualmente como se observa en la siguiente captura.

Fig. Detalle de inserción de datos en tabla users de BBDD prac1.

 

Llegados a este punto, preparamos el script que aprovechará la vulnerabilidad blind SQL para extraer todos los datos alojados en la tabla “Users”, y los guardará en un fichero de texto llamado “users_data.txt”, además de mostrar el progreso por pantalla. El script es el siguiente.

Fig. Detalle del código fuente del script.

 

A continuación, se muestran los resultados obtenidos tras la ejecución del script.

Fig. Detalle de la ejecución del script.

 

Los resultados obtenidos se guardan en el archivo “users_data.txt”, como se muestra en la siguiente captura.

Fig. Detalle del archivo users_data.txt generado tras la ejecución del script.

 

Se concluye que el script realizado ha extraído todos los datos de la tabla Users satisfactoriamente, habiéndolos mostrado por pantalla, además de haberlos guardado en el fichero “users_data.txt”.

 

7. Distintas formas de mitigar la vulnerabilidad Blind SQLi.

 

Para mitigar y prevenir las vulnerabilidades de blind SQLi en la aplicación web que nos atañe, se puede realizar de la siguiente manera.

 

• Uso de consultas preparadas (Prepared Statements).

Las consultas preparadas son una de las maneras más efectivas de prevenir la inyección SQL, ya que se separa la lógica de la consulta SQL de los datos que se insertan y esto evita que los atacantes inyecten código malicioso.

Para implementar la opción de consultas preparadas en el archivo “prac1.php” y mitigar la vulnerabilidad de Blind SQL Injection, se debe modificar la forma en que se ejecuta la consulta SQL.

Para ello se debe:

1. Eliminar la consulta SQL vulnerable: Primero hay que eliminar la consulta SQL que es vulnerable a la inyección SQL. En el código, se trata de la línea donde se define “$sql” y se ejecuta con “$pdo->query($sql)”.
2. Implementar la consulta preparada: Hay que reemplazar esa parte del código con una consulta preparada. Esto asegurará que los valores sean manejados adecuadamente por PDO, previniendo la inyección SQL.

Al nuevo script lo hemos denominado “prac1_parche1.php” y queda de la siguiente manera.

Fig. Detalle del código fuente del script parcheado.

 

A continuación, se ejecuta SQLMap para demostrar que se ha parcheado correctamente la vulnerabilidad.

Fig. Detalle de la ejecución de SQLMap.

 

Como se puede observar en los resultados arrojados por SQLMap, la vulnerabilidad ha quedado correctamente subsanada.

 

• Escapado de entradas (Input Escaping).

Este tipo de parcheo consiste en asegurarse de que los datos que se insertan en las consultas no puedan ser interpretados como SQL. Para implementarlo, se pueden usar las funciones de escape propias de PDO, concretamente se puede utilizar el método quote() para escapar las entradas.

Al nuevo script lo hemos denominado “prac1_parche2.php” y queda de la siguiente manera.

Fig. Detalle del código fuente del script parcheado.

 

Como se ha indicado anteriormente, se ha reemplazado la línea directa de ejecución de la consulta SQL con una versión que utiliza el método quote() de PDO para escapar de forma segura el valor del parámetro ID. De este modo se previene la inyección SQL al asegurarse de que cualquier entrada proporcionada por el usuario se trate como una cadena literal en la consulta SQL, en lugar de como una parte ejecutable de la consulta.

A continuación, se ejecuta SQLMap para demostrar que se ha parcheado correctamente la vulnerabilidad.

Fig. Detalle de la ejecución de SQLMap.

 

Para lo que necesiten pueden escribirnos a info@jaymonsecurity.com