Mostrando entradas con la etiqueta MySQL. Mostrar todas las entradas
Mostrando entradas con la etiqueta MySQL. Mostrar todas las entradas

jueves, 29 de septiembre de 2016

Crackeando credenciales de MySql obtenidos por un MITM like a Sir!


¡Hola amigos! vamos a explicar como poder hacernos por nuestros medios un crackeador de credenciales de MySql. Nos vamos a centrar en atacar una debilidad existente en MySql desde sus inicios, si bien es cierto que la han fortificado desde la versión 4.1, yo considero que en realidad sigue como estaba, pero un poquito mejor.



Para crackear las claves no vamos a requerir de acceso a la tabla mysql.user (mediante un sqli o similar), sino esnifando la trama de la conexión al mas puro estilo MITM (Man in the Middle).

Para ello realizaremos los siguientes pasos:


1- Entender como funciona el proceso de login en MySql

En la siguiente dirección podemos ver el código que utiliza MySql para la comprobación de la contraseña, aunque el link se trata de un fork hecho por twitter, nos vale, ya que este aspecto no cambia desde la versión 4.1 de MySql , no es necesario saber c o c++ pues amablemente, nos han comentado como funciona.



Como se puede ver, el servidor genera una cadena aleatoria (public_seed), esta cadena es enviada al cliente. El cliente la recibe, y realiza el SHA1 de la contraseña introducida (hash_stage1), después vuelve a generar otro SHA1 del resultado anterior (hash_stage2) y envía al servidor un XOR de hash_stage1 con el SHA1 de public_seed y hash_stage2 (generando el reply). 

Lo que parece un poco confuso, en realidad es muy simple, pues en la propia documentación de MySql nos resumen el proceso a una sóla linea "SHA1( password ) XOR SHA1( "20-bytes random data from server" <concat> SHA1( SHA1( password ) ) )"



Nos vamos a centrar en el plugin de autentificación mysql_native_password (Secure Password Authentication) ya que es el que por defecto aparece en las instalaciones mas modernas. Nos explican de una manera mas clara en esta dirección (http://dev.mysql.com/doc/internals/en/authentication-method.html) los diferentes tipos de autentificación que hay, y como se comprueban.

También podemos ver, que lo único que ha variado es en incrementar el tamaño de la semilla enviada por el servidor y de la respuesta del cliente (versión <4.1 en la imagen inferior), que por tema de compatibilidades en la versión "segura", enviarán partida en dos trozos.



Ahora que ya sabemos como funciona, nos queda intentar extraer de la trama la semilla generada (public_seed) y el reply del cliente, realizar el mismo proceso que realiza el cliente con la public_seed fija (hardcodeada), y cuando nos de lo mismo que el reply enviado, ¡la contraseña será la misma!

2 - Obteniendo la trama de una conexión lícita

Lo primero es lo primero, como se trata de un ataque de red, los credenciales se pueden obtener mediante un MITM (como hemos visto en otras ocasiones) ... o en un ataque local, ¿local? pues si, supongamos que nuestro programa de gestión del trabajo utiliza MySql, tenemos derecho a instalar un WireShark, y somos unos meros operarios al que no nos dejan acceder a todos los datos de la empresa. Bastaría con encender el WireShark y abrir el programa en cuestión, para capturar la trama de la conexión a la base de datos. Pero, ¿es esto tan fácil?

Para la prueba de concepto, me he instalado un servidor MySql en una máquina remota, y he puesto al usuario root una contraseña que aparece en un diccionario de palabras (rockyou), ¡pero larga!



Y en el momento que el programa, se conecte de forma lícita, enviará la trama que necesitamos, la cual capturaremos por WireShark (o mediante un MITM)

Podemos ver que WireShark ya hace el trabajo sucio, y localiza los dos valores que más adelante vamos a necesitar:

  • En la salida del servidor: Los dos Salt (lo que llamabamos antes public_seed), tal y como os dije, aparece partida en dos Salt.


  • Y en la respuesta del cliente: el hash del password (lo que llamábamos antes reply). 

¡OJO! no confundir con el hash que guarda MySql en la tabla mysql.user, pues es totalmente diferente. 

El más observador, verá que el usuario viaja en texto plano, ¡Ya tenemos algo!



¿Y que hacemos con esta ristra de datos? Después de este paso, podríamos copiarnos toda esa información a un pendrive y continuar con nuestro ataque en offline. Los únicos valores que vamos a necesitar para más adelante son:


Salt:   28544c632e5956244e3b7e2b56537b3329712357

Hash: 78c87d4766993a5cc3b6b6c4a943069ecd94780b

Nótese que el 00 que nos muestra wireshark no le copiamos, ya que es el fin de cadena y concatenando los dos Salt, obtenemos un Hash SHA1 válido de 20 preciosos bytes.


3 - ¡Creando el kraken! ... digo ¡el cracker!

Lo primero es intentar replicar el funcionamiento de la función que realiza el cliente para generar el reply, para ello, nos creamos una función, que realize exactamente el mismo procedimiento (el lenguaje elegido es C#, pero puede hacerse en cualquiera)


Y después el cuerpo del programa, se leerá nuestro diccionario de palabras a la espera de encontrar la correcta.



Esperamos unos segundos y ... tachan!!



4 - ¡Pero que diantres es eso del c# y de programar!

Algunos os estaréis preguntando si se puede hacer sin necesidad de programar, y la respuesta es: SI, pero le quitamos la gracia. No ... en serio, hashcat y john the ripper tienen ya implementados el hash de MySql (tanto el obtenido por un sniffer como el Hash de la tabla mysql.user).


Para proceder a crackearlo con ayuda de hashcat, haremos lo siguiente:

Si nos vamos a la dirección https://hashcat.net/wiki/doku.php?id=example_hashes , podemos ver el ejemplo de como implementar el crackeo:
11200
MySQL Challenge-Response Authentication (SHA1)
$mysqlna$1c24ab8d0ee94d70ab1f2e814d8f0948a14d10b9*437e93572f18ae44d9e779160c2505271f85821d

Por lo que creamos un archivo hash.txt con el siguiente contenido (donde el primer hash es el Salt y el segundo la Password)
$mysqlna$28544c632e5956244e3b7e2b56537b3329712357*78c87d4766993a5cc3b6b6c4a943069ecd94780b
y ejecutamos el siguiente comando:
hashcat -m 11200 hash.txt /usr/share/wordlists/rockyou.txt


Y con esto, habremos obtenido de otra manera, la misma contraseña utilizada durante la conexión :)

¡Un saludo de @ShargonXL!

lunes, 5 de septiembre de 2016

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.



miércoles, 31 de agosto de 2016

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




Google Analytics