Técnicas de Explotación "Union" -SQLI Parte-7

Técnicas de Explotación "Union" -SQLI Parte-7

El operador UNION se utiliza en la inyecciones sqli para unir una consulta forzada, permitiendo obtener los valores de las columnas de otras tablas;

SQLI 2-Valhalla

Ejercicio de sql injection de la pagina valhalla, primero probamos inyecciones de sql basicas como comillas, dobles comillas, etc, hasta que buscamos algunos payloads de sql en google y a traves de BurpSuite vamos a usar el intruder para buscar cada inyeccion haber si nos acepta alguna; 

SQL Injection-String-Rootme

Seguimos con los retos de esta pagina llamada rootme, de la categoria webserver; estas vez un desafio de inyeccion de sql( SQLI) pero de string; 

Esta aqui y cuando llegamos al codigo fuente vemos que hay una etiqueta href="./?action=recherche>Search</", ahi vamos a intentar inyectar codigo sql; 

el primero es a', para ver que nos da; 

nos da SQLITE 3, sintaxis error "%"; bueno probamos a%' para ver que sale;

Nos da un Warning diferente no existe columna; inyectamos ahora a%' order by 1--, para ver cuantas columnas existen en la base de datos; %' order by 2--, %' order by 3--,

Bueno dice que existen dos columnas, ahora para verificar esto tenemos que buscar consultas para las tablas en  sqlite; 

https://medium.com/@MAFI8919/querying-table-details-in-sqlite-d5436fd7e9b2

Intentamos consultar las tablas con SQLITE_MASTER;

Tras dar con las tablas username y password, estamos a un paso de ver la consulta con exito;

Fingerprinting the Database-Parte 6- SQL Injection

Seguimos con la sexta parte de sql injection(sqli), esta vez, con fingerprinting database; 

El lenguaje SQL es estandar, pero cada vez mas DBMS(sistema de gestion de base de datos) tienen su diferencia, como, comandos especiales, funciones para recuperar datos como nombres de usuario y base de datos, linea de comentarios, etc.

Cuando los testeadores se mueven para una injeccion sql mas avanzada, necesitan saber que gestor de base de datos se usa; 

La primera manera de averiguar que gestor de base de datos se utiliza es observando el error devuelto por la aplicacion. Los ssiguientes son algunos ejemplos de mensajes de error; 

Usando UNION SELECT con VERSION () tambien puede ayudar  a conocer el gestor de base de datos; 

2- si no hay un mensaje de error, el testeador puede intentar inyectar en los campos utilizando diversas tecnicas de concatenacion;

PD: Parte numero 7, Exploitation Techniques

Select Statement Sql Injection-Parte 5

Seguimos con la Parte 5 de Sql Injection; esta vez con la instruccion SELECT; 

Considere la siguiente consulta: 

Cuando el testeador intenta un valor valido ( por ejemplo 10 en este caso), la aplicacion devuelve la descripcion de un producto. Una buena manera de testear si la aplicacion es vulnerable en este escenario es jugar con la logica, usando los operadores AND y OR.

En este caso, es probable que la aplicacion devuelva algun mensaje diciendonos que no hay contenido disponible o una pagina en blanco.

Entonces el testeador puede enviar una declaracion verdadera y comprobar si hay un resultado valido:

CONSULTAS APILADAS: 

Dependiendo de la API que utilice la aplicacion web y del DBMS, por ejemplo, PHP + PostgreSQL, ASP+ SQL SERVER, puede ser posible ejecutar multiples consultas en una sola llamada.

Considere la siguiente consulta: 

Una manera de explotar lo  anterior seria: 

De esta manera es posible ejecutar muchas consultas en una fila e independientemente de la primera consulta.

PD: La Parte 6, se llamara , Fingerprinting the Database

Standard SQL Injection Testing-Parte 4

Ejemplo 1 ( SQL Injection clásico)

Considere la siguiente consulta de SQL:

Generalmente se utiliza una consulta similar desde la aplicación web para autenticar a un usuario. si la consulta devuelve un valor, significa que dentro de la base de datos existe un usuario con ese conjunto de credenciales, entonces se le permite al usuario iniciar sesión en el sistema, de lo contrario se le niega el acceso.

Supongamos que insertamos los siguientes valores de nombre de usuario y contraseña;

La consulta en sql seria la siguiente; 

Si suponemos que los valores de los parámetros son enviados al servidor a través del método GET, y si el dominio del sitio web vulnerable es www.example.com, la petición que llevaremos a cabo sera;

Observamos que la consulta devuelve un valor ( o un conjunto de valores) por que la condición es siempre verdadera ( OR 1=1).

De esta manera el sistema ha autenticado al usuario sin conocer el nombre de usuario y contraseña; En algunos sistemas la primera fila de una tabla de usuario seria un usuario administrador.

Este puede ser el perfil devuelto en algunos casos. Otro ejemplo de consulta es el siguiente;

Hay dos problemas, uno debido al uso de los paréntesis y otro debido al uso de la función hash MD5, primero resolveremos el problema de los paréntesis, eso simplemente consiste en añadir un numero de paréntesis de cierre hasta que obtengamos una consulta corregida. Para resolver el segundo problema tratamos de eludir la segunda condición.

Añadimos a nuestra consulta un símbolo final que significa que esta comenzando un comentario, de esta manera, todo lo que sigue a tal símbolo se considera un comentario.

Cada DBMS tiene su propia sintaxis para comentarios , sin embargo, un símbolo común de las bases de datos es /*. En oracle el símbolo es el --, dicho esto, los valores que usaremos como nombre de usuario y contraseña son;

La consulta SQL quedaría de la siguiente manera;

La solicitud de URL sera: 

esto puede devolver una serie de valores, a veces, el código de autenticacion verifica que el numero de registros/resultados devueltos es exactamente igual a 1.

En los ejemplos anteriores, esta situación seria difícil ( en la base de datos solo hay un valor por usuario). Para evitar este problema, basta con insertar un comando SQL que imponga la condición de que el numero de resultados devueltos sea uno.

Para alcanzar este objetivo, utilizamos el operador "LIMIT <num>", donde <num> es el numero de resultados / registros que queremos que se devuelvan. Con respecto al ejemplo anterior, el valor de los campos quedaría así; 

La solicitud en URL sera; 

PD: Parte 5, Select Statement, continuara..

Detection Techniques SQL INJECTION-Parte 3

El primer paso  es entender cuando la aplicación interactua con un servidor de base de datos para acceder a los datos.

Algunos ejemplos cuando una aplicación necesita hablar con una base de datos: 

Authentication forms( formularios de autenticacion): 

Esto es cuando la autenticacion se realiza a traves de un formulario web, es muy probable que las credenciales de usuario se comparen con una base de datos que contiene todos los nombres de usuario y contraseñas ( o, hashes de contraseñas).

Search engine ( motores de busqueda):

La cadena enviada por el usuario puede ser utilizada en una consulta SQL que extrae todos los registros relevantes de una base de datos.

E-commerce sites(sitios de comercio electronico):

Es muy probable que los productos y sus características ( precio,

descripción, disponibilidad,etc.) se almacenen en una base de datos.

el testeador tiene que hacer una lista de todos los campos de entrada cuyos valores puedan ser utilizados en la creación de una consulta SQL, incluyendo campos ocultos de las peticiones POST y luego probarlos por separado, tratando de interferir con la consulta y generar un error.

considere también las cabeceras HTTP y las COOKIES.

La primera prueba suele consistir en añadir una sola cita (') o un punto y coma (;) al campo o parámetro que se esta probando.

El primero se utiliza en SQL como terminador de cadenas y, si no se filtra por la aplicación, daría lugar a una consulta incorrecta.

La segunda se utiliza para terminar una Sentencia SQL y, si no se filtra, también es probable que genere un error. La salida de un campo vulnerable puede parecerse a la siguiente ( en un Microsoft SQL Server, en este caso):

También se pueden utilizar delimitadores de comentarios (- or /**/,etc.) y otras palabras clave como SQL como AND y OR para intentar modificar la consulta.

una técnica muy simple pero a veces todavía efectiva es simplemente insertar una cadena donde se espera un numero, ya que se puede generar un error como el siguiente:

Supervise todas las respuestas desde el servidor web y eche un vistazo al código fuente HTML/Javascript. A veces el error presente en su interior, pero por alguna razon ( por ejemplo, un error de javascript, comentarios HTML,etc.) no se presenta al usuario.

Un mensaje de error completo, como los de los ejemplos, proporciona una gran cantidad de información al testeador con el fin de montar una ataque de inyección exitoso.

Sin embargo, las aplicaciones a menudo no proporcionan tantos detalles; un simple '500 Server Error' o una pagina de error personalizada puede ser emitida, lo que significa que necesitamos usar técnicas de inyección ciega.

En cualquier caso, es muy importante probar cada campo por separado; solo una variable debe variar mientras que todas las demás permanecen constantes, para poder entender con precisión que parámetros son vulnerables y cuales no.

PD: Parte 4 se llamara "Standard SQL Injection Testing"

Hackthis-Sql Injection 1

Siguiendo con los retos de la pagina Hackthis, nos encontramos con uno muy similar al del reto de wechall, tiene que ver con SQLI (sql injection) y un login bypass; 

como ya sabemos la técnica que se utiliza, es ir probando con las inyecciones login bypass;

hasta que nos diga que esta bypaseado y asi completamos el reto de SQLI 1 y walaaa!