2011-12-16 25 views
6

En pocas palabras, a través de un antiguo sitio asp, ejecuté que alguien encontró un parámetro de URL no filtrado y pude ejecutar esta consulta. Estoy tratando de averiguar lo que hace sin embargo ...¿Qué está haciendo esta inyección de SQL?

La consulta debe decir:

select * from reserve where id = 345 

el que estaba RAN fue:

select * from reserve where id = 345 and ascii(substring((select concat(user,0x3a,password,0x3a,host) from mysql.user limit 0,1),17,1))=53 

Realmente no estoy seguro lo que esto obtiene Cualquier entrada?

+0

Parece que están tratando de reducir el conjunto de caracteres que su base de datos está utilizando. –

+0

Extraño, esta consulta aparece en todo Internet, aunque no en ningún sitio en inglés, pero la consulta me parece inútil. Obviamente están buscando algo ... –

Respuesta

5

Podría estar sondeando si la aplicación web está accediendo o no a la base de datos como root. La eliminación de las porciones ascii(substring()) devuelve el siguiente cuando se ejecuta como root:

mysql> select concat(user,0x3a,password,0x3a,host) from mysql.user limit 0,1; 
+--------------------------------------+ 
| concat(user,0x3a,password,0x3a,host) | 
+--------------------------------------+ 
| root:<rootpw-hash>:localhost   | 
+--------------------------------------+ 

Después de una sonda de éxito, es posible que luego tratar de recuperar el contenido de mysql.user de la que puede empezar a agrietarse contraseñas contra las tablas del arco iris.

+0

Interesante conjetura. Parece que la consulta quiere saber si el 17º personaje de esa concatenación es ASCII char 53, que es el número 5. –

+0

@MikeChristensen Solo estoy investigando eso. En mi caso, devolvió ascii 52 (numeral 4) por lo que puede estar buscando contraseñas en blanco o alguna contraseña predeterminada bien conocida. –

+0

Sí, aunque uno pensaría que simplemente consultarían 'user = 'root'' y' password = 'y terminarían con eso ... –

2

El SQL intenta leer los datos del usuario de la tabla de usuarios My-Sql que generalmente contiene una lista de usuarios y hosts que pueden acceder a un servidor my-sql determinado.

Me parece que el delincuente está tratando de engañar a mysql para que descargue el contenido de la tabla de usuarios para que luego puedan registrar los hash de contraseñas sin conexión y los puedan descifrar para encontrar inicios de sesión válidos.

Si su aplicación web está utilizando un inicio de sesión que permitirá el acceso a la tabla de usuarios de mysql, esta es una falla de seguridad grave, si utiliza un inicio de sesión que solo otorga permiso para las tablas requeridas para la aplicación, entonces no hay información será obtenible

Consejo de seguridad: Al configurar CUALQUIER tipo de base de datos, es de vital importancia que la aplicación lo haga con una función de acceso/acceso que SOLO le otorga lo que necesita.

Si su aplicación solo necesita leer datos y nunca modificarlos, entonces nunca debería tener más permisos que los de lectura. Siempre debe verificar esto, ya que la mayoría de los sistemas de bases de datos crearán por defecto roles de usuario para una base de datos dada con privilegios de lectura, creación y modificación completos.

Crea siempre un usuario específico, solo para ese db y/o colección de tablas, y siempre dale a ese usuario el mínimo absoluto que se requiere, si tu aplicación luego es atacada con un ataque de scripting cross-site, lo máximo que se obtener acceso también es esa base de datos específica.

2

La segunda parte donde la condición es realmente extraño: se ve por unos credenciales MySQL y los procesa de la siguiente manera:

  • concat (user, 0x3a, password, 0x3a, anfitrión) será algo así como 'unUsuario : hisPass: localhost'
  • la cadena anterior se dividirá en una
  • la cadena anterior más pequeña se convierte en código ASCII (que podría saber que desde lenguajes heredados, ord())
  • el resultado de la conversión se compara con 53 entero

supongo que la primera parte de la instrucción WHERE (id = 345) siempre devolverá true mientras que el segundo es demasiado específico, por lo que toda la consulta probablemente devolver un resultado vacío todo el tiempo.

2

la consulta es aparentemente uno de la de un conjunto de ellos:

  • cambiando la posición charCode y subcadena inicio y se puede encontrar todos los nombres de usuario y las correspondientes hashes de contraseñas (cuando la página se representa como se esperaba tiene una coincidencia)
  • permite saber que el usuario actual tiene acceso al esquema de mysql.
+0

¿Qué información tienen en el" conjunto de ellos? "¿?" Cualquier enlace o algo? –

+0

@ neil-m, no tengo ninguna información específica. La consulta comprueba si el código de caracteres del 17º elemento de la concatenación del nombre de usuario + passhash es 53. El atacante ya sabe que el usuario actual tiene acceso a las tablas del sistema y ya ha leído 16 caracteres de la fila resultante. – newtover

+0

@ nail-m, y conociendo el código hash de su contraseña, el atacante puede buscarlo en una tabla de arcoíris y buscar su contraseña u otra cadena que tenga el mismo valor hash. – newtover

2

Una inyección SQL explotar no necesariamente de inmediato la salida del resultado de la consulta a la pantalla atacantes, a menudo el resultado es más que sea un error, o error, o tal vez la inyección causa un medible (al atacante) demora. de esta forma, el atacante puede obtener 1 bit de información por solicitud.

Al enviar muchas solicitudes, iterar sobre posiciones de cadena, hacer una búsqueda binaria en los caracteres, o como en este caso una búsqueda lineal (que puede indicar que el atacante realmente no entiende lo que está haciendo, pero lo hará llegar allí con el tiempo), él será capaz de encontrar todos los caracteres en el usuario root de mysql passwordhash. (Que posiblemente puede ser bruteforced fuera de línea).

Cuestiones relacionadas