SQL Injection: Vulnerabilidad en las Bases de Datos

vulnerabilidad de inyección SQL

Mediante la inyección SQL un atacante podría realizar entre otras cosas las

siguientes acciones contra el sistema:

Descubrimiento de información (information disclosure): Las técnicas de inyecciónSQL pueden permitir a un atacante modificar consultas para acceder a registros y/o objetos de la base de datos a los que inicialmente no tenía acceso.
Elevación de privilegios: Todos los sistemas de autenticación que utilicen credenciales almacenados en motores de bases de datos hacen que una vulnerabilidad de inyección SQL pueda permitir a un atacante acceder a los identificadores de usuarios más privilegiados y cambiarse las credenciales.
Denegación de servicio: La modificación de comandos SQL puede llevar a la ejecución de acciones destructivas como el borrado de datos, objetos o la parada de servicios con comandos de parada y arranque de los sistemas. Asimismo, se pueden inyectar comandos que generen un alto cómputo en el motor de base de datos que haga que el servicio no responda en tiempos útiles a los usuarios legales.
Suplantación de usuarios: Al poder acceder al sistema de credenciales, es posible que un atacante obtenga las credenciales de otro usuario y realice acciones con la identidad robada o “spoofeada” a otro usuario.

Entorno de explotación del ataque

Los condicionantes necesarios para que se pueda dar en una aplicación web la vulnerabilidad de inyección de comandos SQL son los siguientes:

Fallo en la comprobación de parámetros de entrada: Se considera parámetro de entrada cualquier valor que provenga desde cliente. En este entorno se debe asumir “un ataque inteligente”, por lo que cualquiera de estos parámetros pueden ser enviados con “malicia”. Se debe asumir también que cualquier medida de protección implantada en el cliente puede fallar. Como ejemplos de parámetros a considerar donde se suelen dar estos fallos, tendríamos:

Campos de formularios: Utilizados en métodos de llamadas POST
Campos de llamada GET pasados por variables.
Parámetros de llamadas a funciones Javascript.
Valores en cabeceras http.
Datos almacenados en cookies.

Utilización de parámetros en la construcción de llamadas a bases de datos: El problema no reside en la utilización de los parámetros en las sentencias SQL, sino en la utilización de parámetros que no han sido comprobados correctamente.

Construcción no fiable de sentencias: Existen diversas formas de crear una sentencia SQL dinámica dentro de una aplicación web, que dependen del lenguaje utilizado. A la hora de crear una sentencia SQL dinámica dentro de una aplicación web, existen, dependiendo del lenguaje utilizado, diversas maneras. El problema se genera con la utilización de una estructura de construcción de sentencias SQL basada en la concatenación de cadenas de caracteres, es decir, el programador toma la sentencia como una cadena alfanumérica a la que va concatenando el valor de los parámetros recogidos, lo que implica que tanto los comandos como los parámetros tengan el mismo nivel dentro de la cadena. Cuando se acaba de construir el comando no se puede diferenciar qué parte ha sido introducida por el programador y qué parte procede de los parámetros, para ver ejemplos descarga el libro aqui

Ataque: Genera un mensaje de error que le permitirá ver datos de la base de datos.Para ello, se buscaría formar alguno de los siguientes errores:

Errores matemáticos: Permiten extraer información mediante el desbordamiento de los límites de los formatos numéricos. Para ello se convierte el dato buscado a un valor matemático y se opera para conseguir el desbordamiento. En el mensaje de error se obtendrá el resultado del desbordamiento que nos permitirá conocer el dato buscado.

Errores de formato: Consiste en la utilización implícita de un valor de un tipo de dato con otro distinto. Esto generará un error al intentar el motor de base de datos realizar una conversión y no poder realizarla.

Errores de construcción de la sentencia SQL: Permiten encontrar los nombres de los objetos en la base de datos. Sirven para averiguar nombres de tablas y/o campos de las mismas.

Herramienta Priamos

Allá por el año 2001, en las conferencias de BlackHat, David Litchfield presentaba un documento titulado “Web Application Disassembly with ODBC Error Messages” en el que se contaba cómo podía sacarse información sobre la base de datos de una aplicación web a partir de los mensajes de error ODBC no controlados por el programador.

En estos primeros documentos la extracción de información se hacía utilizando la visualización de los mensajes de error de los conectores ODBC, aún quedaba un año para que salieran a la luz pública las técnicas ciegas (blind).

Para ello, el objetivo es generar una inyección que provoque un error y leer en el mensaje de error datos con información sensible.

Blind SQL Injection

Una de las maneras de realizar estos ataques se basa en ataques a ciegas, es decir, en conseguir que los comandos se ejecuten sin la posibilidad de ver ninguno de los resultados. La inhabilitación de la muestra de los resultados del ataque se produce por el tratamiento total de los códigos de error y la imposibilidad de modificar, a priori, ninguna información de la base de datos. Luego, si no se puede alterar el contenido de la base de datos y no se puede ver el resultado de ningún dato extraído del almacén, ¿se puede decir que el atacante nunca conseguirá acceder a la información?

La respuesta correcta a esa pregunta, evidentemente, es no. A pesar de que un atacante no pueda ver los datos extraídos directamente de la base de datos sí que es más que probable que al cambiar los datos que se están enviando como parámetros se puedan realizar inferencias sobre ellos en función de los cambios que se obtienen. El objetivo del atacante es detectar esos cambios para poder deducir cuál ha sido la información extraída en función de los resultados.

Para un atacante, la forma más fácil de automatizar esta técnica es usar un vector de ataque basado en lógica binaria, es decir, en Verdadero y Falso. Este es el vector de ataque en el que nos vamos a centrar en este apartado, las técnicas de inferencia ciega basada en inyección de comandos SQL.

El parámetro vulnerable

El atacante debe encontrar en primer lugar una parte del código de la aplicación que no esté realizando una comprobación correcta de los parámetros de entrada a la aplicación que se están utilizando para componer las consultas a la base de datos. Hasta aquí, el funcionamiento es similar al resto de técnicas basadas en inyección de comandos SQL. Encontrar estos parámetros es a veces más complejo ya que, desde un punto de vista hacker de caja negra, nunca es posible garantizar que un parámetro no es vulnerable, pues tanto si lo es como si no lo es, puede que nunca se aprecie ningún cambio en los resultados aparentes.

Definimos el concepto de “Inyección SQL de cambio de comportamiento cero” (ISQL0) como una cadena que se inyecta en una consulta SQL y no realiza ningún cambio en los resultados y definimos “Inyección SQL de cambio de comportamiento positivo” (ISQL+) como una cadena que sí que provoca cambios.

Cómo se atacan este tipo de vulnerabilidades

Al tener una página de Verdadero y otra página de Falso, se puede crear toda la lógica binaria de estas.

En los ejemplos anteriores, supongamos que cuando ponemos como valor 1 en el parámetro id nos da una noticia con el titular “Raúl convertido en mito del madridismo”, por poner un ejemplo, y que cuando ponemos 1 and 1=2 nos da una página con el mensaje “Error”. A partir de este momento se realizan inyecciones de comandos y se mira el resultado.

SIGUE APRENDIENDO DESCARGANDO EL ARCHIVO