Inyección de código SQL en MS SQL Server 2005 (Parte 1 de 6)
Esta es la primera parte de una serie de artículos donde se va a explicar la tan conocida vulnerabilidad de inyección de código SQL pero centrándose en el motor de bases de datos, MS SQL Server 2005. Se va a obviar si la inyección de código se encuentra en una petición con el método HTTP POST o por GET, ya que es igualmente explotable.
Para los ejemplos, se utilizará una aplicación vulnerable mediante el método HTTP GET, diseñada especialmente para el desarrollo de estos artículos.
El objetivo de esta guía es concienciar tanto a desarrolladores de aplicaciones Web como a administradores de bases de datos, de la trascendencia de esta vulnerabilidad y hasta dónde se puede llegar realizando una buena explotación de la misma.
Es importante destacar que no se van a tratar las vulnerabilidades de inyección ciega de código SQL (BLIND).
1.- Introducción a las inyecciones de código SQL
Inyección de código SQL es un tipo de vulnerabilidad derivada de un incorrecto filtrado de los parámetros que trata la aplicación y que permite la ejecución de código SQL en el DBMS (Data Base Manager System - Sistema Gestor de Base de Datos). En función de los privilegios que tenga el usuario con el que la aplicación se conecte a la base de datos tendremos desde permisos de sólo lectura sobre la base de datos a la que la aplicación se conecta de forma original, hasta permisos de lectura y escritura sobre todas las bases de datos del DBMS e incluso ejecución de comandos en el sistema, escritura de ficheros, etc.
En primer lugar hay que identificar un parámetro sobre el que vamos a realizar las pruebas, por ejemplo, realizamos la petición "http://server/insertar.asp?texto=admin" y obtenemos la siguiente respuesta original de la aplicación:
Hay que comprobar si existe la vulnerabilidad, así como el tipo de dato del parámetro (entero/int o cadena/string) ya que esta información es importante a la hora de construir las peticiones para obtener la información del DBMS.
1.1. - ¿Cómo detectar una inyección de código SQL?
La forma más sencilla es introducir una comilla en el parámetro o variable que queramos comprobar. Por ejemplo, realizamos la petición:
"http://server/insertar.asp?texto=admin'"
y obtenemos el error: Unclosed quotation mark after the character string 'admin''. Este error nos lo devuelve el DBMS e indica que no hemos cerrado correctamente las comillas, como podemos ver en la siguiente captura de pantalla:
Además el parámetro texto contiene un valor string, por lo que podemos obviar que no se trata de un tipo entero.
Vamos a realizar otras validaciones adicionales para estar seguros que estamos interactuando con el DBMS. En primer lugar vamos a concatenar una sentencia lógica que nos devuelva el valor original de la aplicación y no produzca ningún error, la petición es la siguiente:
http://server/insertar.asp?texto=admin'+and+'a'='a
la aplicación devuelve el siguiente resultado:
Hemos introducido este valor en el parámetro: '+and+'a'='a, porque la instrucción interna que la aplicación Web en ASP procesa con dicho parámetro, construye una consulta SQL de la siguiente forma:
cadena = "SELECT * FROM tabla_usuarios where usuario='" & texto & "'"
Para quien no conozca la sintaxis de ASP el resultado real sería que el valor que metemos en el parámetro texto de la aplicación va a ser introducido en la siguiente sentencia en TEXTO: SELECT * FROM tabla_usuarios where usuario='TEXTO' lo que la consulta final que nos queda con la cadena que hemos introducido previamente es la siguiente: SELECT * FROM tabla_usuarios where usuario='admin'+and+'a'='a' por lo que obtenemos de la tabla tabla_usuarios aquellas entradas en las que el campo usuario sea igual a admin Y (and) se cumpla que 'a' sea igual a 'a', por lo que esta última sentencia no aporta nada pero nos ayuda a comprobar que estamos interactuado con el DBMS sin errores.
La siguiente comprobación que vamos a hacer en hacktimes, es ver si podemos obtener otra información diferente a la nuestra, introduciendo la sentencia lógica '+or+'a'='a. Esto va a producir una consulta completa igual a la siguiente SELECT * FROM tabla_usuarios where usuario=admin'+or+'a'='a', lo que quiere decir que estamos pidiendo los datos de la tabla tabla_usuarios donde usuario sea igual a admin ó (or) 'a' sea igual a 'a'. En este caso el DBMS nos devuelve la primera sentencia que se cumpla, y como 'a' siempre es igual a 'a', el DBMS nos va a devolver la primera entrada de la tabla tabla_usuarios que presumiblemente será diferente a nuestro usuario. La petición completa es la siguiente:
http://server/insertar.asp?texto=admin'+or+'a'='a
la respuesta, como era de esperar, es la obtención del usuario pepe:
Con esto, podemos estar seguros de estar ante una aplicación Web vulnerable a una inyección de código SQL. Las anteriores peticiones las hemos realizado para un parámetro vulnerable de tipo string, estas mismas peticiones para un parámetro de tipo entero serían de la siguiente forma:
AND: http://server/insertar.asp?pagina=5 and 1=1
OR: http://server/insertar.asp?pagina=5 or 1=1
Y hasta aquí esta primera parte de esta guía sobre como explotar las vulnerabilidades de Inyección de código SQL en MS SQL Server 2005. En el siguiente artículo de hacktimes.com, hablaremos de la función CONVERT que resulta muy útil a la hora de explotar esta vulnerabilidad.
Comentarios
Nos alegra que te guste, esperamos que suceda lo mismo con el resto de las entregas de este artículo. Gracias por seguirnos.
Muy buen post. Claro, limpio y rápido.
Añadir comentario