SQL Injection
Definición
SQL Injection (SQLi) es una vulnerabilidad que ocurre cuando una aplicación web permite que un usuario envíe entradas sin la debida validación en una consulta SQL. Esto permite a un atacante insertar o "inyectar" código malicioso en la consulta, lo que puede otorgarle acceso no autorizado a la base de datos, robar, modificar, eliminar datos o incluso conseguir acceso remoto.
Definiciones importantes
DBMS (Database Management System) - Sistema de Gestión de Bases de Datos:
Un DBMS es un software que permite crear, gestionar y manipular bases de datos. Su función principal es almacenar datos de manera estructurada y permitir que los usuarios o aplicaciones interactúen con esos datos de manera eficiente. Algunos ejemplos comunes de DBMS son MySQL, PostgreSQL, SQL Server (MSSQL) y Oracle.
DBS (Database System) - Sistema de Base de Datos:
Un DBS es el conjunto de la base de datos junto con el DBMS que la administra. Es decir, el DBS es el sistema completo que incluye tanto la base de datos como el software que gestiona y organiza los datos.
Consultas SQL (SQL Queries):
Una consulta SQL es una instrucción escrita en SQL (Structured Query Language) que se utiliza para interactuar con una base de datos. Las consultas SQL permiten a los usuarios realizar operaciones como leer, insertar, actualizar o eliminar datos en la base de datos. Algunos ejemplos de consultas SQL son:
SELECT: Recupera datos de una base de datos.
INSERT: Inserta nuevos datos en la base de datos.
UPDATE: Modifica datos existentes en la base de datos.
DELETE: Elimina datos de la base de datos.
Cómo funciona una SQL Injection:
Un SQL Injection ocurre cuando una aplicación web permite que los usuarios envíen datos sin una validación adecuada, y esos datos se incluyen directamente en una consulta SQL. Esto permite que un atacante inyecte código malicioso en la consulta SQL, que luego es ejecutado por el servidor de bases de datos.
Ejemplo sencillo de SQLi:
Supón que una aplicación web tiene un formulario de inicio de sesión que pregunta por el nombre de usuario y la contraseña. La consulta SQL para verificar las credenciales podría verse algo así:
Si un atacante ingresa en el campo de usuario algo como:
La consulta SQL resultante sería:
El '1'='1' es siempre verdadero, por lo que la consulta se ejecutaría con éxito, incluso si la contraseña es incorrecta, permitiendo al atacante acceder al sistema.
Tipos de SQLi:
Existen varios tipos de SQL Injection que se basan en cómo se manipula la consulta SQL:
In-band SQLi (SQLi Clásica)
La In-band SQLi es la forma más común y fácil de explotar. El atacante puede usar el mismo canal de comunicación para lanzar el ataque y obtener resultados. Se divide en dos tipos:
Error-based SQLi: El atacante aprovecha los mensajes de error generados por el servidor de base de datos para obtener información sobre la estructura de la base de datos. A veces, solo con los errores se puede enumerar toda la base de datos.
Union-based SQLi: El atacante usa el operador
UNION
para combinar los resultados de múltiples consultas SQL y obtener datos de otras tablas en la base de datos.
Inferential SQLi (Blind SQLi)
La SQLi Inferencial es más difícil de explotar porque no se transfieren datos directamente, pero es igual de peligrosa. El atacante envía cargas útiles y observa las respuestas del servidor web para inferir la estructura de la base de datos. Se divide en dos tipos:
Blind-boolean-based SQLi: El atacante envía una consulta SQL que devuelve un resultado verdadero o falso dependiendo de la consulta. Si el resultado es verdadero o falso, el contenido en la respuesta HTTP cambia.
Time-based Blind SQLi: Similar al anterior, pero aquí el atacante induce una demora en la respuesta de la base de datos. El tiempo de respuesta indica si la consulta fue verdadera o falsa.
Out-of-band SQLi
Out-of-band SQLi es menos común porque depende de funciones específicas habilitadas en el servidor de base de datos. En este tipo de ataque, el atacante no puede usar el mismo canal para obtener los resultados, y la técnica se basa en que el servidor de base de datos haga solicitudes DNS o HTTP a un servidor controlado por el atacante, lo que le permite recibir los resultados.
Resumen
In-band SQLi: El ataque y la obtención de datos ocurren en el mismo canal de comunicación (comúnmente mediante errores o consultas combinadas).
Inferential SQLi (Blind SQLi): No se reciben resultados directos, pero el atacante puede inferir información observando las respuestas del servidor.
Out-of-band SQLi: El atacante depende de las funciones del servidor de base de datos que permiten realizar solicitudes externas, como DNS o HTTP, para recibir los resultados.
Comandos básicos
MySQL:
MSSQL
Payloads
MySQL - bypass autenticación
MySQL - Union Based
Para que los ataques UNION SQLi funcionen, primero debemos satisfacer dos condiciones:
La consulta UNION inyectada debe incluir la misma cantidad de columnas que la consulta original.
Los tipos de datos deben ser compatibles entre cada columna.
Pasito a pasito más entendible:
Blind SQLi - Boolean based
// Dado que 1=1 siempre será VERDADERO, la aplicación devolverá los valores solo si el usuario está presente en la base de datos. Usando esta sintaxis, podríamos enumerar toda la base de datos para otros nombres de usuario o incluso extender nuestra consulta SQL para verificar datos en otras tablas.
Time Based
Logramos el mismo resultado con la siguiente consulta: agregamos una condición IF que siempre será verdadera dentro de la declaración misma, pero devolverá falsa si el usuario no existe.
MySQL RCE
MSSQL RCE
SQLMap
Definiciones importantes:
Risk:
Risk 1 (por defecto): No supone ningún riesgo para la mayoría de las inyecciones sql, las técnicas empleadas no son invasivas y no alteran las bases de datos existentes.
Risk 2: Incluye inyecciones basadas en retardos de manera agresiva, lo que puede afectar a la disponibilidad de las bases de datos.
Risk 3: Incluye inyecciones OR que pueden llegar a forzar la actualización de las bases de datos, modificando sus contenidos.
Level:
Define el nivel de pruebas a realizar. Hay cinco niveles, siendo 1 el valor por defecto (pruebas limitadas). El nivel 5 realiza pruebas más exhaustivas con una mayor cantidad de cargas útiles y parámetros SQL. A medida que sube el nivel, SQLMap prueba más parámetros como GET, POST, Cookies y encabezados HTTP (como User-Agent). Se recomienda aumentar el nivel si la inyección es difícil de detectar.
Delay:
Segundos por cada solicitud
Payloads
Nmap
Casos Reales - Pentest
Se viene pronto.......
Referencias
Última actualización