Análisis básico de ficheros PCAP

Hola chicos!! Como tal vez sabréis, unos cuantos autores el blog estamos participando en el curso online de hacking ético organizado por Mondragon Unibersitatea.

Aunque es un curso de nivel básico, sirve para cubrir algunos aspectos fundamentales en el proceso del pentesting, y estamos disfrutándolo a tope. Además, la última parte, en la que estamos ya metidos de lleno, consiste en un wargame en el que los equipos securizan un servidor y posteriormente tratan de atacar los del resto. ¡Promete!

Este ejercicio que os traigo hoy está sacado del propio curso. Dado que de momento por aquí no hemos tocado demasiado el tema de análisis de ficheros pcap, que contienen los paquetes recogidos en una captura, me parece muy interesante presentároslo.

Os dejo aquí el proceso con explicaciones y cada uno de los ficheros que necesitáis para los ejercicios. Enjoy!!

Primera parte: analizando un protocolo inseguro - Telnet

Fichero de la escucha 

A partir de una captura de paquetes de red recogida en un archivo .pcap realizaremos un análisis de las operaciones realizadas mediante el protocolo Telnet. Este protocolo, al carecer de cifrado, permite que la escucha de red revele todo lo intercambiado en la conexión. 

Podemos abrir el fichero con cualquier analizador de paquetes, como puede ser Wireshark, el cual utilizaremos. 

Lectura del fichero con Wireshark

Como puede verse en la imagen, es muy fácil filtrar el protocolo a mostrar escribiendo simplemente telnet en el campo de filtros del programa.

Podemos ver en texto plano en los campos de análisis de cada paquete los datos intercambiados entre los dos hosts, desplegando la pestaña Telnet. Podemos responder asíl fácilmente a varias preguntas:

• ¿Qué usuario y contraseña se ha utilizado para acceder al servidor de Telnet?
• El usuario es fake, y la contraseña user. 
• ¿Qué sistema operativo corre en la máquina?
• Utiliza un OpenBSD 2.6-beta.
• ¿Qué comandos se ejecutan en esta sesión?
• Se ejecutaron cuatro comandos en la sesión:

ls

ls -a

/sbin/ping www.yahoo.com
(ctrl-c)

exit

Segunda parte: analizando SSL

Fichero de la escucha

En la siguiente parte, realizaremos un análisis muy similar con una traza que ha recogido una sesión SSH. A diferencia de Telnet, el protocolo SSH realiza un cifrado de la conexión, de forma que hace imposible que apreciemos a primera vista los datos que se intercambian. 

Lectura del fichero con Wireshark (2)

Aunque no podemos discernir las operaciones realizadas en la sesión, podemos responder a algunas preguntas: 

• ¿Puedes identificar en qué paquete de la trama el servidor envía el certificado?
• Sí. Los certificados se envían en los paquetes enviados por el servidor y que contienen la información marcada como Certificate. Si abrimos dicha información, se puede ver el certificado. 

Certificado encontrado en la sesión

• ¿El certificado va en claro o está cifrado? ¿Puedes ver, por ejemplo, qué autoridad ha emitido el certificado?
• Para que el cliente pueda ver el certificado antes de realizar una conexión completa mediante SSH y así verificar la identidad del servidor a priori, el certificado se envía en plano, sin cifrar. 

Información del certificado en Wireshark

• Si queremos ver la información algo más clara, podemos exportar el certificado clicando con el botón derecho en la pestaña del certificado y en Export Packet Bytes..., para entonces guardarlo como un fichero .der. Podemos ver este certificado entonces haciendo doble clic sobre él. Entre otras cosas, podemos ver los datos acerca de la autoridad de certificación. 

Visualización de datos del certificado

• ¿Qué asegura el certificado, la identidad del servidor o del cliente?
• El certificado asegura la identidad del servidor. 

Tercera parte: analizando SSH

Fichero de la escucha

Por último para esta tarea, analizaremos otra captura del protocolo SSH para responder a otra serie de preguntas respecto a la misma. 

• ¿Puedes ver a partir de qué paquete comienza el tráfico cifrado?
• Sí. Aunque en la captura solamente se muestran los paquetes enviados desde el lado cliente, puede apreciarse que el tráfico cifrado comienza en el paquete marcado como 13, después de haber intercambiado las claves. 

Primer paquete cifrado de la sesión

• ¿Qué protocolos viajan cifrados, todos (IP, TCP...) o alguno en particular?
• Algunos protocolos viajan cifrados, otros no. Tanto TCP como IP son protocolos de capas inferiores a la de aplicación, la cual es la que suele ofrecer funciones de cifrado. Por ejemplo, el protocolo FTP viaja sobre TCP/IP, pero no está cifrado; su derivado seguro, FTPS, también viaja sobre TCP/IP, pero está cifrado.
• ¿Es posible ver alguna información de usuario como contraseñas de acceso?
• No es posible (al menos de forma matemáticamente rentable) recuperar ningún tipo de dato de la sesión una vez pactadas las claves de cifrado. 

Hasta aquí el ejercicio, hackers. Espero que os sirva para practicar un poco y disfrutar!!

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.

https://github.com/twitter/mysql/blob/master/sql/password.c

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 ) ) )"

Fuente: http://dev.mysql.com/doc/internals/en/secure-password-authentication.html

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!

Evil GO.ogle

Buenas hackers!
En esta prueba de concepto os explicare como una persona con fines mal intencionados puede obtener el correo electronico Gmail de los empleados de una organización a través de Twitter como medio de propagación.

A traves del bypass del hsts conocida por @ShargonXL, el link http://www.google.es/?gws_rd=ssl fuerza el http saltandote el https, capturando la cookie de sesión de la cuenta de Gmail si ese usario previamente esta logeado en el navegador. Es un fallo de seguridad ya que un usuario mal intencionado puede enviar ese link a traves de ingenieria social y con un ataque man-in-the-middle obtener la cookie y sesión de Gmail.
¿Se consideraria un fallo de seguridad el degradar de https a http? Si se da el caso o la opinión de que no lo es, ¿por qué se implementa el sistema de seguridad hsts? El hsts precisamente consiste en evitar que una pagina web nunca vaya por http, porque es un protocolo inseguro, entonces ¿por qué el hsts de Google no funciona con ese link?, si la medida de seguridad hsts no funciona un atacante mal intencionando mediante Man-In-The-Middle tiene una capacidad enorme para interceptar las peticiones y respuestas entre un usuario y un servidor de aplicaciones web, es decir, se manda el link,  se abre un esnifer para capturar el trafico, pincha la victima y se obtiene la cookie y el email, saltando el https de Google.

Proof of concept by naivenom,
El empleado con conocimientos de hacking y con sintomas de Burnout (esta quemado con su trabajo :S), realizará un ataque Man-In-The-Middle estando en medio de la comunicación interceptando la información entre el emisor y receptor. Para ello tendrá que estar en la misma red LAN, y utilizar el protocolo IPv4 para el intercambio de datos.
El ataque esta basado en ARP Spoofing, donde el atacante con malas intenciones se colocará entre el router y la victima. Cuando el router envie tráfico a la victima, este pasara primero por la maquina del atacante.
El protocolo ARP permite el conocimiento de la dirección física de otro dispositivo partiendo de la base que conoce una dirección IP.

El planeamiento del ataque deberá ser meticuloso y saber el medio de propagación del link. En este caso el atacante usará el Twitter y mediante ingenieria social convencera al personal de la empresa para seguir esa cuenta. Propagará el link con un mensaje privado a todo el personal diciendo que el lugar del restaurante donde van a cenar es este: http://www.google.es/?gws_rd=ssl

Una vez planeado el ataque, empieza el ataque Man-In-The-Middle:

PASO 1: 

Será necesario que el atacante tenga un portatil y acceso a la red. Cumple de sobra estos requisitos. Abrira el programa EvilFOCA para realizar el ataque Man-In-The-Middle.

Una vez envenenado la tabla ARP de la victima, todos los paquetes enviados entre router y victima pasarán por nosotros.

PASO 2: 

Ahora procedemos a abrir un esnifer de paquetes de red como por ejemplo Wireshark.
Quizas sea este el paso más delicado y dependemos de varios factores:

• Tiempo que haya de interacción entre victima y el software Twitter
• Si la victima pincha el enlace o no. Se presupone de nuestra previa habilidad en convencimiento y confianza que le ofrecemos a la victima. 

Una vez que la victima pincha el enlace desde su maquina, se le abrirá la pagina de google y si hay suerte de que tenga ya logeada la cuenta de Gmail, obtendremos la cookie y el correo.

Guardamos la captura en .pcap

PASO 3:

Analizaremos la captura hecha con el software Fiddler.
Podemos observar que a través de la petición GET, obtenemos el Gmail de la victima con tan solo estar logeada.

Con el correo electronico podemos realizar ataques de phishing o envio de malware, obteniendo una shell del sistema victima.

PASO 4: 

Al capturar el tráfico, obtenemos unas cookies. De un modo u otro instalando una extensión en chrome podemos replicar esas cookies y tener la sesión loegada del Gmail victima en nuestra maquina. También deberemos modificar el user-agent con otra extensión proporcionada por Chrome:

Replicamos las cookies que obtenemos en la captura de Wireshark o Fiddler y la añadimos o editamos en nuestro navegador:

Actualizamos con la replica de las cookies obtenidas mediante el esnifer y escribimos la URL del link:

Como pueden observar es fácil a traves de un ataque Man-in-the-middle y el bypass del hsts, obtener información sensible como puede ser el correo electronico o el nombre y apellidos.

P.D Esta prueba de concepto esta realizada con fines educativos siempre en un entorno de trabajo propio, usando la propia red LAN y cuenta de correo (en este caso) de Gmail. No nos hacemos responsables de su mal uso.