lunes, 24 de diciembre de 2018

Y como regalo de Navidad ¡OTRA TOOL! Atenea

Creía que no me iba a dar tiempo para antes de final de año, pero al final, apretando un poco, ha salido todo como esperaba. Puede que incluso mejor de lo que pensaba. Tengo que admitir que lo mío me ha costado, ha habido bastantes problemas durante el desarrollo de esta herramienta, pero al fin ha salido, le quedan algunos retoques, pero está lista para la batalla. Adelante Atenea.


Pero empecemos esta historia desde el principio. Esta historia comienza cuando vi una conferencia que hizo que se me encendiera la bombilla de perfeccionar un ataque que ya estaba comentando el ponente.


En la CyberCamp  2018 que se celebró este año en Málaga, acudí al taller de José Selvi, un gran investigador de seguridad. En ese taller habló de un side-channel que hay en Google Contacts que permite, a pesar de ser HTTPS, obtener información de esa comunicación cifrada. Me resultó interesante, y conforme veía el taller, pensaba en cómo podría mejorar el escenario y el ataque que presentó.

¿Qué es un side-channel?

Un Side-channel es un canal paralelo. José Selvi lo explica muy bien en la CON de la Ekoparty, una CON de la que os dejo el vídeo. Pero voy a tratar de explicarlo para que todo el mundo lo entienda.

Imagina que pides un paquete por Amazon. Ese paquete llega al repartidor. El repartidor no sabe qué hay en el paquete porque el paquete "está cifrado extremo a extremo". No obstante, hay determinadas acciones que si las hace, podrá ir obteniendo información de lo que hay en el paquete.

Por ejemplo, si mira con la mano cuanto pesa y ve que pesa un poco, ya sabe que un folio no es. Si ve que el paquete es rectangular en lugar de redondo, ya sabe que un balón inflado no es. Si lo mueve un poco y ve que no suena mucho, puede pensar que, a lo mejor, es ropa. Pues un side-channel es eso exactamente.


Pues bien, ahora vamos, y vemos que Google Contacts, utiliza el formulario de búsqueda con el método GET y, si analizamos el tráfico de red, veremos que cuando buscamos un número de teléfono correcto, el paquete tiene un tamaño de 722 bytes. Esto es importante.


Ahora lo que tenemos que probar es a, por ejemplo, cambiar un dígito en el número de teléfono. Vemos que ahora el mismo paquete tiene un tamaño de 723 en lugar d e 722 ¿por qué?


Esto ocurre porque comprueba, carácter a carácter, el dígito que se introduce. Lo que hace es preguntar si en la posición i0 hay una "A" por ejemplo. Si es correcto, nada, devuelve un True y listo. Sin embargo, si no hay una "A", devuelve un False y suma 1 a i0, de ahí que cuando es incorrecto sea 723 (722+1).

Este es nuestro side-channel, pero claro, mandar a manopla de una en una letra por cada hueco del array es bastante tedioso. Para esto tenemos unos equipos muy potentes que nos facilitan el trabajo. En el caso del número es un poco más fácil, ya que sabemos que son 9 dígitos siempre +2 del código  del país (España es +34 por ejemplo)+ 1 del símbolo "+".


Como hemos dicho, para el número de teléfono es "más fácil" ya que sabemos que el tamaño es fijo. Tenemos un total de 48620 combinaciones posibles. No hace falta que nos pongamos nosotros a hacerlo a mano. La herramienta Crunch nos generará el diccionario por nosotros.

crunch 9 9 0123456789 -o numberphones.txt

Con el comando anterior, lo que estamos haciendo es decirle a crunch, que genere un diccionario con un tamaño mínimo de 9 dígitos, un tamaño máximo de 9 también y que en las "palabras", incluya los valores 0123456789. Todo eso, que lo guarde en el documento de texto numberphones.txt.

Es evidente que, al utilizar el método GET, podemos recorrer todo el fichero con las combinaciones de números de teléfono, formando esos números, parte de la URL que vamos a solicitar.

contacts.google.com/search/$numbers

La URL sería algo como eso, y en GNU/Linux es sencillo de montar un escribir que ejecute Firefox haciendo la petición a esta URL en segundo plano. Antes, hemos tenido que lanzar tcpdump en segundo plano para que recoja todo el tráfico.

tcpdump -i eth0 -w captura.pcapng &

Después tendremos que leer esa captura de tráfico. Algo como esto nos servirá.

tcpick -C -yP -r tcp_dump.pcap

Tenemos que tener en cuenta, además, que tenemos que considerar el tamaño de los paquetes. Por supuesto, cuanto más grande sea la query, más tamaño tendrá el paquete. Cuidado con eso. Tendremos que tener en cuenta el pipe grep.


Así pues, para la PoC, me monté sobre un Apache Server una web con un formulario de búsqueda en PHP que consultaba los contactos a una Base de datos que me monté en MariaDB 10.


Para que veáis que no es una página estática, aquí os enseño la Base de datos en la que he añadido 3 contactos, uno el teléfono de las Meetings de trabajo, y otro 2 amigos, Fulano y Pepito.


Ignorad el diseño tan pésimo de la web, es solamente una PoC. Lo importante aquí es que la consulta las hace también con el método GET, por lo que todo lo que pongamos en el cuadro de búsqueda, se reflejará en la barra de direcciones tal y como pasa con Google Contacts.

Que empiece la Guerra contra HTTPS

Aquí entra Atenea, diosa de la guerra, sabiduría y ciencias. De ahí el nombre de la tool. Antes de nada decir que he creado una nueva web por el tema de no exponer los números de teléfono de mis contactos, no por otra cosa.


La tool se divide en 2. Una es atenea_listening, que simplemente pone un netcat en el equipo del atacante a la escucha, el cual va a esperar hasta que reciba el número de teléfono que la propia ./atena va a tratar de obtener.


Como vemos, ./atenea_listening se queda a la espera de una conexión que le muestre por pantalla el número de teléfono. Es un entorno cliente-servidor de libro. Todo, como he dicho, es abrir un netcat y quedarse a la escucha. No hay más. Por esta razón, ./atenea_listening es prescindible, ya que podemos lanzar el netcat sin más, pero era por darle un poco de estilo.


La tool en sí, ./atenea, lo que hará será crear una shell en la que tenemos un catálogo de parámetros que nos ayudará a la hora de extraer los números de teléfono de los contactos de nuestra víctima. (Por cierto, me encantan las letras de Atenea, me gusta casi más eso que la tool en sí ;P ).


Con el parámetros brute=ON, lo que hacemos es decir que queremos que lance el ataque de fuerza bruta para extraer el número de teléfono. A continuación, nos pide que introduzcamos el nombre de un contacto si es que lo sabemos para agilizar la búsqueda. Lo ideal es que antes, hayamos hecho un trabajo previo de recolección de información de fuentes públicas con OSINT.

Este proceso es lento, sí. Tened en cuenta que tiene que generar todas las combinaciones de números de teléfono para después lanzar el ataque de fuerza bruta. Irá probando cada número en cada hueco del array hasta que termine todo el proceso (para el número tarda entre 2-3 minutos más o menos). Cuando termine, nos pide que introduzcamos un atacante válido.


Esto no es para otra cosa que para abrir también otro netcat y enviar a esa IP (la del atacante) el número de teléfono con el formato [Nombre Contacto]:[Número de teléfono].


Si volvemos a la terminal de ./atenea_listening, vemos que ya nos ha mandado el output con el número de teléfono y cierra el netcat rápidamente. Para ejemplificar mejor esto, he elaborado un vídeo.




Como vemos, esto toma su tiempo, y eso que estamos tratando de sacar "lo más fácil y rápido", que es el número de teléfono (Nota: El vídeo hay partes que he recortado ya que llegaba a los 10 minutos). Si quisiéramos hacer la operación contraria, llevaría mucho más. Hasta aquí, es lo mismo que José Selvi presentó. Mi herramienta tiene algunos cambios respecto a la suya, además consigo reducir un poco los tiempos al probar directamente con el número completo y no 1 a 1. No reduzco mucho, ya que lo que doy con una mano, lo quito con otra.En probar números de teléfonos tarda menos, pero ese tiempo se compensa con lo que tarda en generar todas las combinaciones.

Pero claro ¿Cómo mejoramos esto? ¿Cómo dominamos el tiempo para que la víctima no sospeche de lo que está ocurriendo? Aquí viene el cambio más grande con el ataque expuesto de José Selvi. Yo contesté esta pregunta con un "El usuario, lo que más tiene es tiempo; pero ¿cómo hago para que tenga ese tiempo que el usuario no sabe que tiene?". La respuesta a esa pregunta ya es tema de otro post.

¿Hackeamos el Mundo?

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...