Inyecciones sin agujas con SQLMap

Buenas a todxs,

Tras unas merecidas vacaciones he decidido volver a escribir una nueva entrada. Esta vez os mostraré la herramienta SQLMap.

SQLMap es una herramienta para la automatización de ataques SQLi, lo cual facilita bastante la tarea del auditor a la hora de buscar este tipo de vulnerabilidades y poder posteriormente explotarlas.
Está desarrollada en python y se encuentra ya instalada en distribuciones como Kali, aunque también podéis descargarla desde https://github.com/sqlmapproject/sqlmap/wiki/Usage. Es bastante completa, pero en esta publicación veremos los aspectos más básicos.

Para usar la herramienta sin necesidad de probar las comodidades que nos ofrece la Guardia Civil o Policía en uno de sus lujosos y bien acondicionados calabozos, probaremos a ejecutarla en DVWA (una plataforma de pruebas ya comentada en anteriores post como: https://fwhibbit.blogspot.com.es/2016/07/poc-evitando-filtros-anti-xss.html y https://fwhibbit.blogspot.com.es/2016/03/guia-metasploitable-2-parte-2.html).

Ejecutamos la plataforma, obtenemos la dirección IP donde se aloja y entramos en ella seleccionando el nivel intermedio.

Nos vamos a la pestaña de "SQL Injection" y probamos a introducir un número cualquiera para comprobar el funcionamiento, a la vez que obtenemos información de la Cookie generada (nos será necesaria más adelante para lanzar SQLMap).

Para obtener la Cookie abrimos el inspector del navegador y accedemos a las pestaña que puede verse en la siguiente imagen:

En este punto (siento por haber ido tan rápido hasta aquí, pero quería centrarme en SQLMap y no en DVWA) empezaremos con lo interesante.

Para ejecutar la herramienta utilizaremos el comando "sqlmap" en una consola con la opción "u" para introducir la URL vulnerable (habiendo introducido antes un ID en la web), con el parámetro "--cookie" insertaremos la sesión que obtuvimos con anterioridad y por último el parámetro "--dbs" para mostrar las bases de datos contenidas en la web.

El resultado será el siguiente:

A partir de aquí, se abrirá ante nosotrxs un abanico de oportunidades para obtener información.

Como era de esperar, podemos indagar un poco más buscando en las tablas de las bases de datos mediante parámetros como "-D" para seleccionar la base de datos y "--tables" para mostrar las tablas contenidas.

Obteniendo como resultado:

Ahora que nos sentimos como auténticos juankers, tras ver lo intuitivo y sencillo que es el manejo de esta herramienta tan potente, el siguiente paso no podría ser otro que mostrar las columnas de una de las tablas obtenidas con los parámetros "-T" para seleccionar la tabla y "--columns" para mostrarlas.

Por cada columna se nos facilitará información sobre el tipo de dato que contiene.

Para sacar la información de las columnas user, first_name, last_name y password, lo haremos de una forma bastante complicada. Sólo algunos juankers como yo podrán hacerlo a través de años de experiencia y estudios... Usando el parámetro "--dump"

Todo esto está muy bien, pero las posibilidades de SQLMap son mas variadas que los gorros de Chema Alonso. ¡No preocuparse primoh!

Algunos parámetros como "--current-user" nos dará información sobre el usuario que se está ejecutando en el servidor.

En nuestro caso, es el usuario "root".

Otra cosa que suele partir ojetes, sería ejecutar el parámetro "--file-read" para leer algo tan interesante como /etc/passwd.

El fichero se guardará en la ruta que nos indica: root/.sqlmap/output/192.168.1.105/files/_etc_passwd

Por último y no menos importante, siempre nos quedará para todo lo demás Mastercard y el parámetro "--help".

No olvidéis que todo esto se trata de información para utilizarla de forma responsable, profesional, académica, blah, blah, blah y debéis NO debéis utilizarlo para liarla pardísima por servidores ajenos sin un permiso correspondiente.



"La revolución empieza por casa SQLMap."

Pablo Lorenzo.

Auditando un Entorno Real: SQLi + CURL + TOR

Muy buenas compañeros, llevaba tiempo ya queriendo estrenarme en el blog y finalmente he conseguido el tiempo suficiente para traeros este post.


Primeramente comentar que la vulnerabilidad mostrada en esta entrada ya ha sido comunicada a la empresa auditada, y que por supuesto no se mostrará información sobre la empresa ni sus clientes. La publicación unicamente tiene fines educativos, con el proposito añadido de concienciar a los desarrolladores web a evitar este tipo de fallas de seguridad en sus aplicaciones.



Y sin más os pongo en situación, hoy en día gran parte de las ventas que se hacen vía telefónica (a través de Contact Center), ya sean de un producto, un servicio determinado, o la contratación de suministros requiere de la aceptación de un contrato a través de Internet.

La empresa auditada genera una llamada telefónica hacia el cliente con el fin de venderle su servicio, cuando el cliente accede a contratar el mismo recibe un SMS donde se le redirige a una URL con sus datos y el contrato para aceptar como podemos ver a continuación.

Lógicamente los datos han de ser enviados por GET y podemos apreciar en la URL que se envía un identificador de cliente (id) y un teléfono (phone), comprobamos que sucede si alteramos el teléfono:

Hemos descubierto que si el ID y el PHONE no coinciden la página nos muestra un error de mysql sin controlar. Por lo tanto podemos hacernos una idea de la consulta SQL que hay en el PHP que genera el contrato.

Llega el momento de comprobar si el desarrollador simplemente olvidó quitar el Display Error o es que no realiza ningún tipo de control de los datos recibidos:

 

Tras realizar varias pruebas y comprobar que es vulnerable a una inyección SQL (Más sobre SQLi: Enlace) vemos que tenemos acceso a absolutamente todos los datos de los clientes, incluidas las tarjetas de crédito y sus datos bancarios, además de poder aceptar los contratos en su nombre, si bien el Sistema de Detección de Intrusos (IDS) bloquea las herramientas automatizadas como SQLmap o NinjaSQL, así como las consultas de gran carga como las que abusan de concat.

Por lo tanto emplearemos "--" para comentar la consulta que sigue al id y evitar de esta forma tener que introducir el teléfono del cliente para obtener sus datos.

Es en este momento donde echaremos mano de CURL (empleando un servicio oculto de TOR), para el que no lo conozca CURL nos permite enviar peticiones a un servidor web y analizar la respuesta. En este caso concreto hice un pequeño script para automatizar el envío de peticiones con PHP y almacenar todos los contratos.

 

De esta forma tan sencilla es posible acceder a los datos de los clientes de la Empresa auditada que no pone en peligro sus propios datos sino los que hacen referencia a sus clientes, incumpliendo la normativa europea y por supuesto la LOPD.

¿Cómo evitamos esta vulnerabilidad?

La web está generada en PHP por lo tanto el programador puede utilizar la función mysql_real_escape_string o bien controlar los datos recibidos. Es importante también implantar un protocolo de transferencia seguro (HTTPS en vez de HTTP) para evitar que la información llegue al servidor web en texto plano y evitar que se visualicen los mensajes de error por el cliente.

Espero poder traeros más episodios de Auditando un Entorno Real en breve,

Un saludo compañeros,
Alejandro Cañas