Press "Enter" to skip to content

SQL Injection: técnicas OAST

Last updated on octubre 3, 2020

Hoy te traigo un tipo de SQL Injection muy interesante, y que no es muy conocido. Es una variación de Blind SQL Injection.Si todavía no estás muy puesto con las inyecciones SQL, te recomiendo que visites primero este post. También deberías echarle un ojo a las noSQL injections de las bases de datos no relacionales.

 En las Blind SQL Injection, podemos obtener información de la base de datos si el servidor devuelve respuestas distintas según sea verdadero o falso el payload inyectado (Boolean Blind SQL) . En caso de que devuelva siempre la misma respuesta, podemos hacernos con la información de la base de datos a partir de los tiempos de respuesta del servidor (Time Blind SQL).

Sin embargo, puede darse el caso de una aplicación que sea vulnerable a SQL Injection pero mande las respuestas de forma asíncrona. En ese caso, si inyectamos un payload para intentar causar un retraso de 10 segundos en la respuesta, pero el servidor recibe la petición y la procesa en el hilo original, pero usa otro hilo para ejecutar la query, no nos daremos cuenta de que la inyección ha funcionado porque el proceso que sufrirá el delay es diferente al que devuelve la respuesta.

En estos casos, la única solución es intentar una Blind SQL utilizando técnicas fuera de banda (OAST). Esto es, hacer que el servidor interacúe con otro sistema que tengamos bajo nuestro control mediante otro protocolo. Normalmente se suele utilizar el protocolo DNS. Esto es debido a que probablemente el servidor tenga prohibido comunicarse con el exterior con la mayoría de protocolos, pero es habitual que tenga permitido realizar querys de DNS, puesto que lo necesitan para resolver dominios en su funcionamiento habitual. Veamos un ejemplo.

Blind SQL Injection Out of Band con interacción DNS

Lo primero que necesitas es un servidor capaz de recibir peticiones. Para esto lo más fácil es abrir una instancia en Burp del Burp Collaborator client.

BurpSuite Collaborator
Para abrirlo, ve a Burp -> Burp Collaborator Client

Si el servidor víctima es vulnerable y podemos inyectar código en la query SQL, puedes inyectar un comando que haga que el servidor víctima se conecte al tuyo para hacer un DNS lookup.

Dependiendo de la base de datos que se esté usando, el comando es distinto. Yo suelo utilizar las cheatsheets de pentestmonkey:

Oracle    –    MSSQL    –    MySQL    –    PostgreSQL    –    Ingres    –    DB2    –    Informix

También está bastante bien la cheatsheet de portswigger.

En este ejemplo la víctima corre una base de datos Oracle. Tras un par de intentos conseguí que se ejecutase inyectando el siguiente payload, que realiza un dns lookup a nuestro servidor (en mi caso el servidor de Burp Collaborator Client que lancé previamente tiene asignado el nombre “569xdp89rrergcdn1060o459m0srgg.burpcollaborator.net” ):

La forma de comprobar si ha funcionado es ir al Burp Collaborator client y clicar en “Poll now”. Si recibimos una petición DNS desde la víctima, entonces es que ha ejecutado la query:

Ahora veamos si podemos obtener información de la base de datos.

Exfiltrando información de la base de datos con técnicas Out of Band

Una vez has comprobado que el servidor víctima realiza la petición a tu servidor, puedes ejecutar las queries y que el servidor te vaya mandando los resultados de las mismas. Por ejemplo, a continuación voy a hacer que me devuelva la password del usuario administrados

Vuelvo a pulsar Poll now en mi Burp Collaborator client (que ahora ha pasado a ser ob3gi8dswajalvi66jbjtnasrjxfl4.burpcollaborator.net) y aparece la contraseña como subdominio:

Mediante la técnica de SQL Injection Out of Band hemos conseguido averiguar que la contraseña del usuario administrador es “pass36”.

 

Lethani.

3 Comments

  1. Victor Victor junio 26, 2020

    Hola. Eso está en la academia de PORTSWIGGER, lo que sería interesante es que publicaras, utilizando ésta técnica OAST:
    PRIMERO: cómo averiguas el nombre de la tabla, en éste caso “users”.
    SEGUNDO: cómo averiguar los campos de la tabla descubierta en el paso PRIMERO (users),
    esos campos serían “username” y “password” por ejemplo.
    TERCERO: cómo averiguar el contenido del campo “username” por ejemplo, que se descubre en
    el paso SEGUNDO.
    CUARTO: Con esos datos(tabla users y campo username conteniendo el dato administrator),
    RECIEN ahi haríamos esa línea: (SELECT+password+from+users+where…etc…

    Eso es algo que PORTSWIGGER en su academia no lo toma en cuenta en los labs que pone a resolver. Con técnicas basada en Booleanos, en errores condicionales y desencadenando retrasos se puede hacer perfecto todos esos pasos anteriores pero con OAST lo tengo que investigar.
    Gracias y saludos.

    • Lethani Lethani julio 7, 2020

      Dependiendo de la base de datos que se utilice, existen diversas formas para averiguar esa información. Por ejemplo, si se trata de MySQL puedes averiguar los nombres de las tablas con
      SELECT table_schema,table_name FROM information_schema.tables WHERE table_schema != ‘mysql’ AND table_schema != ‘information_schema’
      De estos resultados buscarías una tabla que tenga pinta de contener los usuarios y contraseñas, en este caso ‘users’. Conociendo el nombre de la tabla, a continuación puedes obtener los nombres de las columnas con:
      SELECT table_schema, users, column_name FROM information_schema.columns WHERE table_schema != ‘mysql’ AND table_schema != ‘information_schema’
      Y de este resultado obtendrías las columnas ‘username’ y ‘password’. Para obtener el contenido de username bastaría con hacer
      SELECT username from users
      Espero haberte ayudado.
      Lethani

  2. Victor Victor julio 23, 2020

    Gracias Lethani, me voy a poner a probar con eso. Te agradezco la respuesta. Un abrazo!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *