|
Un equipo con Backtrack5, una antenaWiFiy la suite Aircrack, a escuchar el tráfico de red en modo monitor. El objetivo, intentar obtener algún dato que pudiese dar información
Descifrar el tráfico capturado con airdecrypt, analizar utilizando en primer lugar la versión gratuita de la herramienta Network Miner, que corre en sistema operativo Windows y es muy útil a la hora de obtener una visión a alto nivel de una captura de tráfico. Una vez cargada la captura,Network Miner identifica todos los hosts presentes en ella, y reconstruye a partir del tráfico tramas, archivos, imágenes, mensajes de chat, credenciales y sesiones si se han capturado, peticiones DNS, parámetros GET.. Además proporciona información interesante sobre los equipos presentes en la captura, que por otra parte puede obtenerse con cualquier otro analizador de tráfico tipo Wireshark, pero facilita bastante la tarea.
Figura 1: Información del equipo presente en la captura con NetworkMiner |
La primera lectura, se trata de un equipo con sistema operativo Windows, analizando las tramas y las conexiones establecidas, los sitios webs más visitados durante la sesión de navegación, 20 minutos:
http://www.vanitatis.com
http://www.elpais.com/gente
http://devilwearszara.com
http://www.fotoplatino.com
Figura 2: Imágenes presentes en la captura analizada con NetworkMiner |
Realizando un análisis más profundo con herramientas como CookieCadger oWireshark, información exacta del equipo para conectarse a Internet, identificando peticiones HTTP, correspondientes a la comprobación de actualizaciones disponibles para un Notebook Asus F50SL:
Figura 3: URL para comprobar las actualizaciones de Notebook Asus F50SL |
Siguiente paso, conseguir más información mediante un ataque man in the middle, para intentar obtener alguna credencial en algún sitio web donde tuviera que identificarse, pero para eso debería de estar en casa esperando justo en el momento en que fuese a utilizar la red para navegar. Para ello, utilizar Cain + Wireshark en entorno Windows, y tambiénarpsoof en entorno Linux.
Por supuesto, en aquellas ocasiones en que coincidía conectado antes de intentar un ataque MITM, me propuse escanear su máquina connmap, pero los puertos estaban filtrados por el Firewall de Windows.
Paralelamente a estos intentos, siempre mantener equipo capturando tráfico WiFien modo monitor, y analizar las capturas, además de las obtenidas con Cain + Wireshark. En estas nuevas capturas, información interesante para el análisis.
Figura 4: Peticiones de DNS a blogs relacionados con oposiciones a judicatura |
Analizando el nombre de los sitios web, así como el contenido que había en los mismos, me quedó claro que se trataba de una mujer, que estaba estudiando para oposiciones a judicatura. Es decir, que hablamos de una aspirante a juez robandoWiFi. ¡Así va este país!. Por otro lado, entre todas estas sesiones de navegación, en las que los sitios webs visitados eran los mismos especificados hasta ahora, se colaban algunas sesiones cortas en la que los sitios visitados eran:
http://www.sport.es (Además leía la sección “El balón Rosa” ;) )Estas sesiones, en principio parecía que correspondían más a “Rober1”, leyendo periódicos deportivos y echando un vistazo a las novias y mujeres de los futbolistas. En una de estas sesiones, concretamente un domingo, Rober1 consultó también la página de Yelmo Cines, pero al final parece que no se decidió a ir, porque más tarde presuntamente su pareja se volvió a conectar a ver vídeos de bebés, y leer un poco de prensa rosa, supongo que para desconectar de las arduas sesiones de estudio para la oposición.
http://www.marca.com
http://tenerifedeportivo.com
Por la información de la que disponía hasta el momento, se trataba de una pareja de vecinos que utilizaba mi red para conectarse a Internet y ahorrarse la tarifa del ISP, no de un hax0r con muchos conocimientos. Esto último me quedó más claro, cuando en una de las capturas recogidas escuchando en modo monitor, pude ver accesos a páginas de banca electrónica, algo que alguien con conocimientos de seguridad informática jamás haría desde una WiFi ajena.
Figura 5: Imágenes correspondientes a portal de banca electrónica |
Afortunadamente para los vecinos, dieron con alguien que no tenía malas intenciones, y en esta ocasión, incluso de haberlas tenido, no podría haber hecho ningún destrozo, ya que al tratarse de tráfico SSL las credenciales no habrían sido capturadas sin romper el cifrado.
En este punto ya tenía claro el perfil de los “atacantes”, así como su nivel de conocimientos, pero aún no los había identificado. Los ataques man in the middleno funcionaban siempre, así que se me ocurrieron varias alternativas. La primera de ellas, enchufarles un troyano haciendo DNS spooffing con alguna de las direcciones de los sitios webs más visitados. Pero en lugar de eso, decidí implementar un esquema “machine in the middle”, colocando una máquina a modo de router, para asegurar que todo el tráfico que generaban pasaba por la misma.
Para ello, habilité una máquina virtual Backtrack, a modo de puente con dos interfaces de red. Una de ellas conectada a la red en cuestión, 192.186.1.0, y la otra en una nueva red 192.168.2.0, con la dirección IP 192.168.2.1. Además de eso, deshabilité el servidor DCHP del router al que se conectaban los vecinos, y arranqué un servidor DHCP en la máquina virtual, que repartiera direcciones en la nueva red, especificando como puerta de enlace la dirección de esta máquina en la nueva red, la 192.168.2.1. El tráfico generado era redirigido de una interfaz a otra, en aras de poder llevar el tráfico hacia y desde Internet a través del router principal.
Por otra parte, también arranqué la herramienta SSLstrip, redirigiendo el tráficoSSL al puerto 10.000, para poder así interceptar sesiones de autenticación en algún sitio web que permitiese obtener alguna información para identificar a los malhechores. En este script de shell se puede observar la configuración final.
Figura 6: Configuración que arranca el esquema bridge en el mitm |
Con este nuevo esquema, los vecinos se conectaban a mi router vía WiFi, pero era la nueva máquina puente la que hacía de router para ellos, dándoles una nueva dirección IP en el rango 192.168.2.0 y ofreciéndoles salida a Internet. Bastaba con arrancar tcpdump, dsniff, y visualizar el log de sslstrip para poder controlar todo el tráfico generado por los vecinos.
El esquema no tardó en funcionar. La siguiente vez que se conectaron, todos los paquetes pasaban por la nueva máquina puente, y tras una o dos sesiones de navegación, el log de SSLstrip reveló su dirección de correo electrónico y su cuenta de Facebook:
Figura 7: Datos de cuenta Facebook capturados con SSLStrip |
No comments:
Post a Comment