| Artículos | 01 JUN 2007

Protección contra las técnicas de Blind SQL Injection

Tags: Histórico
Chema Alonso.
Ésta es la primera de una serie de dos entregas en las que repasaremos las principales técnicas de ataques para aplicaciones web. En ambas entregas podremos ver las vulnerabilidades más habituales y aprenderemos a minimizar los riegos que supone publicar un servicio en internet.

Aunque son relativamente recientes, parece que las técnicas de SQL Injection para atacar aplicaciones web llevan toda la vida entre nosotros. Y es que en esto de la tecnología siempre sucede algo similar, en muchas ocasiones tenemos la percepción de que llevamos utilizando ciertos componentes o servicios, y al echar la vista atrás comprobamos que no es tal.
Pero, desgraciadamente, este tipo de ataques, aunque sobradamente conocidos, documentados y bien estudiados desde hace tiempo (el concepto SQL inyection data del año 1998), en la práctica nos encontramos con más sitios web vulnerables de lo que deberíamos.
Pero, como ocurre en todos los aspectos de la tecnología, a medida que se publican técnicas para combatir este tipo de problemas, van surgiendo nuevamente metodologías más y más complejas que, de una forma o de otra, ponen a prueba nuestra pericia.
En este artículo vamos a ir un paso más allá de SQL Inyection, repasando una técnica, también conocida, pública y documentada, pero todavía no lo suficientemente manida como para evitar que los hackers la sigan utilizando. Se trata de Blind Sql Injection.

Blind SQL Injection
El modo de funcionamiento de este tipo de ataques se basa en conseguir que los comandos se ejecuten con la desventaja de no poder visualizar 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, ¿esto quiere decir que el atacante nunca conseguirá acceder a la información? La respuesta correcta, evidentemente, es no, ya que, a pesar de que un atacante no pueda ver los datos extraídos directamente de la base de datos, sí es más que probable que al cambiar los datos que se están enviando como parámetros se puedan obtener pistas sobre ellos en función de los cambios que se obtienen. El objetivo del atacante que utiliza Blind SQL Injection es detectar esos cambios para poder averiguar cuál ha sido la información extraída en función de los resultados.
La forma más fácil de automatizar este tipo de técnicas para un atacante es usar un vector de ataque basado en lógica booleana, es decir, verdadero o falso. Éste es el matiz que va a centrar todo el estudio de la presente metodología.

El parámetro vulnerable
En primer lugar, a la hora de realizar una intrusión de este tipo, el atacante debe encontrar una parte del código de la aplicación que esté realizando una comprobación incorrecta de los parámetros de entrada, con el fin de inyectar algún tipo de comando personalizado. Hasta aquí, el funcionamiento idéntico al resto de técnicas basadas en inyección de comandos SQL. Encontrar estos parámetros es a veces una labor compleja, porque, desde el punto de vista del hacker, nunca es posible garantizar que un parámetro no es vulnerable, ya que tanto si lo es, como si no lo es, puede que nunca se aprecie cambio alguno en los resultados aparentes.
Llegados a este punto, antes de comenzar a inyectar código, y aquí es donde comienzan las principales novedades de un ataque a ciegas, es necesario identificar un par de posibles comportamientos. El primero de ellos lo obtenemos cuando inyectamos una cadena y el resultado de la página web no realiza ningún cambio aparente sobre lo que esperamos. Este estado se denomina “Inyección SQL de cambio de comportamiento cero” (o ISQL0). Por el contrario, cuando al inyectar código sí apreciamos algún tipo de comportamiento anormal en el resultado de la página web, estamos ante una “Inyección SQL de cambio de comportamiento positivo” (o ISQL+). Veamos unos ejemplos de estos escenarios; Supongamos una página de una aplicación web del tipo www.miweb.com/noticia.php?id=1. En este caso, vamos a suponer que 1 es el valor del parámetro id, y dicho parámetro va a ser utilizado en una consulta a la base de datos de la siguiente manera:
Select campos
From tablas
Where condiciones and id=1
Para este caso concreto, una inyección ISQL0 sería algo como lo siguiente:

http://www.miweb.com/noticia.php?id=1+1000-1000
http://www.miweb.com/noticia.php?id=1 and 1=1
http://www.miweb.com/noticia.php?id=1 or 1=2

Si lanzamos estas tres instancias, en ninguno de los casos estamos realizando cambio alguno en los resultados obtenidos en la consulta. Por el contrario, cogiendo este mismo ejemplo, una ISQL+ sería algo como lo siguiente:

http://www.miweb.com/noticia.php?id=1 and 1=2
http://www.miweb.com/noticia.php?id=-1 or 1=1
http://www.miweb.com/noticia.php?id=1+1

En los tres casos anteriores sí estamos cambiando los resultados que debe obtener la consulta, ya que, si al procesar la página con el valor sin inyectar (y con ISQL0), nos devuelve la misma página, se podrá inferir que el parámetro está ejecutando los comandos, es decir, que se puede inyectar comandos SQL. Ahora bien, cuando optamos por la modalidad ISQL+ nos reporta siempre una página de error, que no nos permite ver ningún dato. Pues bien, éste es un caso típico para realizar la extracción de información procedente de una base de datos a través de una aplicación vulnerable a las técnicas de Blind SQL Injection.

¿Cómo se atacan esas vulnerabilidades?
A nivel de tratamiento, al tener una página de “verdadera” y otra “falsa” se puede crear toda la lógica binaria de las mismas.
En los ejemplos anteriores, supongamos que cuando ponemos como valor 1 en el parámetro id nos devuelve una noticia con el titular “Conozca más sobre Blind SQL Inyection”, y que cuando enviamos el parámetro 1 and 1=2 obtenemos una página de error. A partir de este momento, con el fin de conocer en profundidad el comportamiento de las páginas, habría que realizar distintas inyecciones de comandos y se observar cómo se comporta ante las diferentes situaciones.
Continuando con el ejemplo anterior, supongamos que queremos saber si existe una determinada tabla en la base de datos. Para ello habríamos de indicar la siguiente sentencia después como valor del parámetro id:

id= 1 and exists (select * from usuarios)

Si el resultado obtenido es la noticia con el titular anterior, podremos inferir que la tabla sí existe, mientras que si obtenemos la página de error sabremos que, o bien no existe, o el usuario no tiene acceso a ella o incluso es posible que no hayamos escrito la inyección correcta SQL para el motor de base de datos que esta aplicación está utilizando en con

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información