Hacking Newbie Inyeccion a ciegas SQL CUH

CUH e-zine 3ª Edicion

dicion

INYECCION SQL A CIEGAS I PARTE By Alesteir

INYECCION SQL ACIEGAS
(BLIND SQL INJECTION)
INJECTION)
Para nadie es un secreto que unas
de las mayores vulnerabilidades de
la red son las famosas inyecciones
SQL, pero existen variadas técnicas y una de ellas, es
la que actualmente se conoce como inyección a
ciegas de SQL (blind sql injection), este articulo es
una corta introducción al tema, y nos ayudara a
comprender lo que son, como funcionan dichas
técnicas, y alguna cosilla mas, en un proximo
numero del e-zine trataremos la forma de explotar
dichas vulnerabilidades.
una aplicación web, la cual usa los datos que recibe
por parte del usuario (Cliente) para construir
sentencias de consulta y de esta forma mostrar la
información pertinente (solicitando los datos al
Servidor), ahora resulta que llegado el punto,
sabemos de su vulnerabilidad y procedemos a
inyectar consultas pero no vemos los datos
obtenidos, no obstante, podemos distinguir
comportamientos distintos entre consultas que
muestran datos, y las que no lo hacen, es allí donde
basados en valores verdadero (true) o falso (false)
que son devueltos por la aplicación, que debemos
saber el tipo de inyección ciega pertinente, para de
esta manera obtener los datos que deseamos poseer.
Para saber si un parámetro es vulnerable a una
inyección ciega de sql supongamos que tenemos una
web, y la pagina 467, por decir algo un ejemplo:

http://www.ejemplo.org/pagina.php?id=467

Entonces añadimos abs() de la siguiente manera:

http://www.ejemplo.org/pagina.asp?idpagina=abs(4
67)

Y si la página se muestra correctamente sabremos

Inyección SQL que la web es vulnerable a un ataque a ciegas de
inyección SQL.
Una inyección de código SQL esta basada en una
interacción de un intruso con el motor de una base
de datos, en la cual el atacante puede obtener y
hasta modificar los datos, e incluso el atacante
puede llegar a obtener y manipular archivos, con la
consecuencia de poder manejar los datos y el
sistema a su antojo y con total libertad. Todo ello se
debe a la mala validación y filtrado de los datos
introducidos por el usuario (Cliente), por parte de la
aplicación Web (Servidor) que maneja el gestor de la
base de datos, de forma que el intruso puede
alterar las sentencias SQL aceptadas por la
aplicación server.

Injeccion Ciega de SQL

Esta técnica se usa cuando una web no muestra los

típicos mensajes de error de la base de datos, al no
haber un resultado positivo en una consulta
especifica, o sea que solo se enviará una respuesta
por parte del servidor si el resultado es correcto. Es
por ello que sentencias que contengan entre sus
condiciones valores comparativos como 1=1 o
0=1 ofrecen respuestas, bien sea respuestas
negativas o positivas, esta es la base de esta técnica
de inyección SQL. Ahora Supongamos que tenemos
Hacking Newbie Inyeccion a ciegas SQL
Inyeccion a ciegas basado en tiempos de respuesta
Las primeras referencias en cuanto al tema las hizo
Chrish Anley en el documento: Advanced SQL
Injection” en el 2002 hacia referencia de la
posibilidad de realizar ataques a ciegas basado en
tiempos de respuesta , en dicho documento el
explicaba códigos, métodos y practicas para hacer
consultas sin importar si obteníamos resultados
palpables, e indefectiblemente saber si eran ciertas
o no, todo ello dependiendo, de el tiempo en que el
motor de la base de datos tardaba en dar la
respectiva respuesta a la consulta. A partir de allí se
empezó a indagar por parte de otras mentes
inquietas, pronto se descubrieron parámetros
vulnerables a inyección SQL, de forma que sin
necesidad de ver los resultados de la consulta, se
podían conseguir resultados a partir del tiempo de
respuesta dado por el gestor (y con un poco de
lógica se podían transforman en datos reales), otros
mas osados crearon herramientas para explotar
(exploits) dichos parámetros vulnerables a
inyecciones ciegas y hasta que con el tiempo se
volvió ya todo un tópico, a la hora de penetrar un
sistema basado en consultas a un gestor de base de
datos. La técnica consiste en generar retardos en las
inyecciones, y la mejor forma de usar esta
vulnerabilidad, es conociendo las funciones
especificas cada motor de base de datos, benchmark
benchmark
(sleep en la versión 5 y posteriores) en mysqlm,
waitfor en SQL server, DBMS_Lock.Sleep() en
Oracle; por nombrar solo algunas.
Veamos pues la forma de inyectar código a ciegas
en distintos gestores:
Mysql_
Mysql
http://server/ejemplo.php?id=35 and exists(select *
from Passwords and
benchmark(8000000,md5(rand()))=0
Mysql (versiones 5):
http://server/ejemplo.asp?id=35 and exists(select *
from Passwords) and sleep(8)
Oracle:
http://server/ejemplo.php?id=1; begin if (exists(select
* from Passwords)) then dbms_lock.sleep(8); end if;
end;
CUH
CUH e-zine 3ª Edicion
dicion
Microsoft SQL Server :
http://server/ejemplo.php?id=35; if (exists(select *
from Passwords)) waitfor delay ‘0:0:8’—
En la anterior consulta el motor evalúa si la tabla
Passwords existe y si contiene registros, al cumplirse
la condición la respuesta se retardará por un lapso
de 8 segundos, es bueno recalcar que no todos los
gestores permiten la técnica de inyección a ciegas
con retardo de tiempo
Inyección a ciegas basado en tiempos de respuesta
usando consultas pesadas
Existe otra técnica que se basa en usar consultas
pesadas, las cuales al exigir al motor de bases de
datos y de manera obvia generar un retardo de
tiempo ante respuestas positivas. Supongamos que
sabemos cual es el parámetro vulnerable de una
consulta y queremos saber si existe una tabla X en
especial, aquí optaríamos por elaborar una consulta
que solo haga trabajar al motor un tiempo extra con
nuestra consulta pesada si dicha sentencia cumple la
condición de que la tabla X exista en la base de
datos, de otra forma no lo haría y por lógica el
tiempo de respuesta seria distinto, es aquí donde se
deben conocer las clausulas y el tipo de condiciones
que se pueden llegar a manejar, (tal como sucede
con la clausula Where), para así mismo poder
elaborar adecuadamente nuestro consulta , para ello
se hace necesario conocer la evaluación de las
condiciones por parte de los gestores, en el caso de
la clausula Where , si la cláusula tiene encadenada
sus condiciones por operadores de tipo OR la
consulta se evaluará, mientras ninguna condición
devuelva un resultado verdadero, contrariamente
cuando están encadenadas por operadores de tipo
AND las condiciones se evaluarán mientras ninguna
devuelva un valor falso, basado en este mecanismo
es que se optimiza el tiempo de respuesta para las
condiciones, es por ello que los motores tienen un
orden a la hora de hacer la evaluación, pero es el
programador quien realmente define el orden de las
condiciones en una clausula Where, veamos por
ejemplo la siguiente consulta:
Select nombre from Passwords where nombre=Aleks
and pass=qwerty;
Select pass from Passwords where nombre=Aleks or
pass=qwerty;
En el primer caso usamos una condición AND, si al
evaluar la primera condición obtenemos un valor
FALSO el gestor no evaluar la otra, en la segunda
consulta con el operador OR si la primera condición
es VERDADERO no se evalúa la siguiente condición.
Sucede que no siempre es el gestor el que realiza la
Hacking Newbie Inyeccion a ciegas SQL
optimización, es entonces donde el programador
debe saber la precedencia y el mismo efectuar la
optimización, pudiendo ser de izquierda a derecha o
viceversa.
Actualmente los motores modernos estiman el tiempo
de cada condición y evalúan primero la condicional
de menos valor en tiempo real de ejecución, esta
particularidad es la que nos permite aprovecharnos
de este tipo de situación.
Imaginemos que tenemos el parámetro vulnerable
id_usuario en alguna URL:
http://www.ejemplo.org/pagina.asp?id_Usuario=1
Con lo dicho anteriormente, si quisiéramos saber si
una tabla existe realizamos más o menos la siguiente
consulta:
http://www.ejemplo.org/pagina.asp?id_Usuario=1
[nuestra
nuestra consulta pesada]
pesada and exists (select * from
Passwords)
De lo anterior deducimos que si la tabla claves
existe, nuestra consulta pesada se efectuara
generando un retraso de tiempo considerable, lo
cual nos revelará que efectivamente la tabla
Passwords existe y que además posee mas de un
registro. La elección de nuestra consulta pesada será
la clave a la hora de saber el retardo y por ende
saber si nuestra consulta ha sido efectiva. Entonces
como elegimos nuestra consulta pesada? La
respuesta se da conociendo las tablas internas para
cada gestor de base de datos, por ejemplo en SQL
Server tendríamos “sysobjects” y en Access
tendríamos “MSysObjects”; o tablas propias de la
web vulnerable, que por obvias razones nosotros
seriamos quienes deduciríamos aquellas tablas que
contienen registros, de esta forma podemos medir
los tiempos entre una consulta que cumpla las
condiciones y una que no. Podemos generar
consultas pesadas es unir tablas con otra s y otras
hasta generar una cantidad grande de registros de
forma que tan que obliguen al servidor a consumir
un tiempo medible en procesarlo. Para ello basta
con conocer o averiguar o adivinar una tabla del
sistema de bases de datos, que tenga algún registro,
y unirla consigo misma hasta generar un tiempo
medible. Vamos a ver algunos ejemplos.
Según lo dicho anteriormente podemos hacer la
siguiente consulta en la cual se invierte la condición y
así poder comparar los tiempos entre cada una de
ellas:
CUH
CUH e-zine 3ª Edicion
dicion
la cuenta con que accedamos al servidor. También
existen otro tipo de técnicas que nos permiten
hacernos con archivos directamente del sistema
operativo del servidor, con esto ya tenemos casi que
un acceso total a la web. Existen distintas funciones
en cada gestor por ejemplo en Microsoft SQL Server
2005 tenemos las funciones OpenRowset y BULK que
se manejan combinadas, he aquí dos ejemplos :
http://www.ejemplo.org/pagina.php?id=1 and (select
datalength(Z) from OpenRowset(BULK 'c:\Boot.ini',
SINGLE_CLOB) as t(Z)) >1
http://www.ejemplo.org/pagina.php?id=1 and
(select substring(Z,{PosByte},1) from
OpenRowset(BULK 'c:\ Boot.ini', SINGLE_CLOB) as
t(Z)) > 5
Es asi como podríamos automatizar el proceso y
obtener todo el contenido del archivo con un código
que llame uno a uno los caracteres del archivo que
vamos a conseguir.
En MySQL podemos usar la función LOAD_FILE, la
cual acepta como parámetro la ruta del archivo,
pero en hexadecimal. Ahora si queremos realizar un
ataque a el archivo c:Boot.ini debemos primero que
todo convertirlo a hexadecimal:
0x633A5C626F6F742E696E69 con esto podemos
proceder con la inyección:
http://www.ejemplo.org/pagina.php?id=1 and
mid(Load_File(0x633A5C626F6F742E696E69),1,1)=C
HAR(34)
La condición será positiva, si la primera letra del
archivo corresponde con el carácter ASCII 34., es asi
que por medio de automatización y de fuerza bruta
podríamos obtener todos los datos de un archivo,
alginas herramientas se basan en este método
Para una próxima edición queda la parte final de
este articulo, espero que les haya gustado!
Suertes!!!
By Alesteir
Alesteir

http://www.ejemplo.org/pagina.asp?id_Usuario=1
[nuestra pesada and not exists (select *
nuestra consulta pesada]
from claves)
Otras técnicas de Blind SQL Injection
De esta forma ya sabemos que podemos consultar a
ciegas cada uno de los elementos del motor de una
base de datos vulnerable, es lógico que
dependiendo todo ello de los tipos de privilegios de