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

miércoles, 25 de junio de 2014

Google Street Car, Malware y el Modo Monitor WiFi

Como ya conté en el post que escribí en mi blog personal de Hacking Ético en EFEFuturo, este verano tuve, gracias a mis padres, la oportunidad de hacer un fantástico viaje a bordo de un crucero por el Mar Báltico con toda mi familia. Como buen adicto que soy a la seguridad informática,  además de para conocer destinos increíbles y disfrutar de la compañía de mis seres queridos, aproveché el poco tiempo que me quedaba libre para continuar practicando con mis experimentos de inseguridad.

El planteamiento inicial de la prueba

En este caso particular, el rato del que dispuse fue concretamente de 1 minuto y 12 segundos, en los que aproveché para capturar el tráfico de la red con mi antena WiFi en modo monitor, desde la habitación de un hotel de Londres donde estuvimos los días previos a coger el barco. No hubo más tiempo porque mi mujer aguardaba para salir, y transcurrido ese minuto mi hija de 1 año se había encargado de recorrer el suelo de toda la habitación deshaciendo las maletas con su particular algoritmo de ordenación :)


Figura 1: Captura en modo monitor con WireShark

El objetivo del experimento era conseguir entender cuánta información era posible que el famoso coche de Google Street hubiera capturado, teniendo en cuenta que él hacia más o menos lo mismo: Capturar durante un breve espacio de tiempo el espectro WiFi en modo monitor.

Para los que no recuerden la historia, basta decir que durante un periodo de tiempo, el coche que tomaba las fotos para Google Street View, venía con unas antenas WiFi que capturaban tráfico en modo monitor. Eso no gustó a todo el mundo, y acabó con denuncias y redadas en muchos países del mundo. Solo eran unos segundos, pero el tráfico capturado... ¿podría ser muy sensible?


Figura 2: Bromas con el caso de la captura de tráfico WiFi del Google Street Car
Cuando se está capturando el tráfico de una red WiFi de un hotel, desde una habitación ubicada en una determinada habitación con una orientación particular, uno se limita a ver los paquetes que pasan cerca de los puntos de acceso que se encuentran a su alcance.

Los datos obtenidos en el experimento

Una captura tan corta, a priori no parece que debiera aportar mucha información para analizar, debido al escaso número de paquetes de datos obtenidos. De hecho, en mi caso concreto, a pesar de que existía algo de tráfico HTTP en la captura, no se podían identificar peticiones concretas:


Figura 3: Cero peticiones HTTP reconocidas en la captura

Del mismo modo, la herramienta NetworkMiner de la que tanto se aprende en el libro de Ataques en Redes de Datos IPv4 & IPv6, y que tan buenos resultados me ha dado en otras ocasiones, identifica los hosts en la captura y las tramas de datos, pero no es capaz de reconstruir por ejemplo imágenes, archivos o peticiones, lo cual es normal dada la extensión de la captura.


Figura 4: Análisis de imágenes con NetworkMiner

Sin embargo, si se utiliza la herramienta de análisis forense y file carving llamada Foremost, sí que es posible apreciar fragmentos de imágenes que se han transmitido por la red durante ese minuto y medio.


Figura 5: Fragmentos de imágenes obtenidos con data carving

Si nos fijamos con atención, se pueden observar fragmentos de imágenes que se corresponden con el popular movimiento en la red conocido como "memes". Es decir, imágenes divertidas con un mensaje gracioso, que numerosos usuarios intercambian constantemente a través de Whatsapp, Line, o cualquier otro sistema de mensajería. Puedo dar fe a ciencia cierta de esto, pues mis amigos se han pasado el verano enviándome estos famosos memes de Julio Iglesias, que tan de moda se han puesto últimamente.


Figura 6: Imagen parcialmente reconstruida

Es normal que al estar en Londres, los textos sean en inglés. En este meme concreto se puede leer la frase “Bumps into something...”. Para identificar la parte de la captura en la que se encuentra esta parte de la imagen transmitida existen diferentes alternativas. La más evidente, analizar el fichero reconstruido con un editor hexadecimal, y buscar los bytes que corresponden a la imagen en la captura. 


Figura 7: Análisis hex del fichero recuperado con BackTrack (aún no he migrado a Kali)

Haciendo esto podemos obtener mucha información, desde la dirección IP del servidor que está transmitiendo la imagen, la dirección IP del cliente en la red, así como la dirección MAC del mismo analizando las cabeceras IEEE 802.11. En este caso en concreto, se trataba de un dispositivo Apple. 


Figura 8: Paquete utilizado para recuperar un fragmento del meme

Lo curioso de esto es que, si hacemos algo de Hacking con Buscadores, para intentar obtener información acerca de esta dirección IP, podemos ver que es una dirección es sospechosa, y que ha sido detectada por el servicio VirusTotal como potencialmente dañina, ya que está continuamente resolviendo a diferentes dominios de dudosa reputación.


Figura 9: Análisis en Virus Total de la imagen descargada

Con los pocos datos de los que se disponen en la captura, no es posible determinar de qué web, o a través de qué aplicación el cliente conectado a la red se estaba descargando esta divertida imagen, pero lo que sí se puede afirmar es que nada bueno podía venir de allí.

Reflexión final

Con este experimento, es posible ver que a pesar de que el Google Street Car se conectara unos pocos segundos, puede obtenerse algo de información que podría ser sensible. Lógicamente, solo sería peligroso este tipo de capturas para aquellas redes WiFi que no se hubieran fortificado, ya que si por ejemplo hubieran puesto una medida de seguridad entonces habría que previamente crackear WPA/WPA2 .

Esta es también una pequeña reflexión más del peligro que entraña conectarse a redes WiFi públicas inseguras, en las que cualquiera puede monitorizar los datos que envías incluso sin estar conectado. En todo esto, no se tiene en cuenta los posibles vectores de ataque activos en los que se implementan esquemas tipo man in the middle en redes IPv4 o IPv6.


Figura 10: MacDefender para Mac OS X, un rogue AV, se distribuía usando envenenamiento de resultados de fotos de pirañas en Google Images

Además en este caso concreto la reflexión es doble, pues además de volver a incidir en la inseguridad de las redes WiFi públicas - y alertar a los no avisados de que los datos viajan libremente por el aire - se puede encontrar un nuevo ejemplo de la jungla en la que se ha convertido la red, donde hasta descargarse una aparentemente inocua imagen divertida para enviar a nuestros amigos puede convertirse en un problema, si lo haces desde el servidor equivocado, que pudiera estar haciendo envenenamiento de resultados de Google Images, por ejemplo, como forma de distribución de malware.

Autos: Deepak Daswani

http://deepakdaswani.es
http://twitter.com/dipudaswani

Fuente:
http://www.elladodelmal.com/2013/10/google-street-car-memes-malware-y-el.html

miércoles, 18 de junio de 2014

Auditar la WiFi del hotel con resaca y un jailbroken iPhone

Durante estas vacaciones de Semana Santa regresé a mi querida isla de Tenerife para disfrutar de unos días de vacaciones con la familia. Como el objetivo de estos días era desconectar de la frenética actividad a que nos lleva esta vida en el mundo de la seguridad informática, decidí dejar el ordenador portátil en casa, y disfrutar de estos días de playa, relax y algo de copas en alguno de los locales de moda de la isla.


Figura 1: Uno de los locales de moda en la isla de Tenerife.

Tras una noche de fiesta me desperté a eso de las 9:15 con la cabeza apunto de estallar, a causa del famoso Ron Arehucas de Canarias, pero mi insomnio crónico no me dejaba dormir, así que como no tenía ninguna computadora a mano, cogí el teléfono móvil y me puse a teclear para ver qué había pasado por Internet. Tras revisar los feeds RSS de seguridad y leer un post del blog del Maligno, reparé en que el hotel en el que me alojaba disponía de una red WiFi privada según nos habían dicho. Como no tenía mucho que hacer, me entretuve en saber cuál sería el nivel de seguridad que ellos entendían por privado.


Figura 2: Portal Cautivo WiFi del hotel.

Al abrir el navegador tras conectarme a la red inalámbrica, apareció el clásico portal cautivo en el que debía introducir mis credenciales. Lo primero que me llamó la atención fue el nombre del host que aparecía en la URL de login: “gateway.example.com”. Lo siguiente que hice fue consultar el direccionamiento de la red WiFi a la que me había conectado en el apartado de Ajustes de mi iPhone, para ver si el portal estaba aplicando aislamiento de clientes a nivel IP:


Figura 3: Direccionamiento de la red WiFi del hotel

Como se puede observar en la imagen, la máscara de subred que se aplica para esta red es “255.255.0.0”, por lo que hablamos de una red de clase B con direccionamiento “192.168.0.0” y no sólo el portal cautivo o la puerta de enlace son accesibles, sino también el resto de equipos.

Además del nombre del hotel, he tapado el nombre que aparece en el apartado de dominios de búsqueda, pues parece que corresponde al de la empresa que instaló y configuró esta red. No obstante, centré mi atención en el nombre de servidor del portal, “gateway.example.com”, así que abrí la aplicación Terminal instalada en mi dispositivo con jailbreak para realizar un ping al host:


Figura 4: Dirección del servidor gateway.example.com

La respuesta al comando ping situaba la dirección IP del portal en la “192.168.2.1”, así que el siguiente paso fue hacer una petición directamente al servidor sin utilizar el nombre de host, para ver si se veía algo diferente:


Figura 5: Portal de administración de Hotspot 4ipnet

Lo que se veía en el navegador ahora ya no era la página de inicio de sesión en el portal cautivo, sino la página de administración del dispositivo que implementaba dicho portal, y que como se puede observar era del fabricante “4ipnet”. No pude reprimirme, y el siguiente paso fue buscar rápidamente en Google las credenciales por defecto, que tanto juego dan en muchos casos, para el usuario administrador de estos dispositivos:


Figura 6: Manuales de dispositivos 4ipnet con credenciales por defecto

Quería comprobar, que en efecto los administradores habrían cambiado la clave por defecto. Y en efecto, afortunadamente la combinación “admin” “admin” que se puede observar en la mayoría de manuales para los productos de 4ipnet me devolvió un mensaje de “Contraseña incorrecta. Siga probando :( “

Como también tenía instalada en mi iPhone el escaner de red para iPhone Scanny, y como este tipo de dispositivos ofrece habitualmente más servicios además del HTTP para la administración de los mismos, decidí comprobar qué otros puertos estaban abiertos:


Figura 7: Escaneo de puertos del servidor con Scanny

Además de HTTP, HTTPs y PPTP, también se podía acceder al host mediante ssh. En ese momento recordé que al buscar la contraseña por defecto para los dispositivos de este fabricante, visualizando el avance del texto para el primero de los resultados se podía entrever que además del usuario admin, existía una cuenta de root.

Si el administrador de la red WiFi privada del hotel había cambiado la password de administrador, lo suyo es que hubiera hecho los deberes y cambiado también de la de root. Si no fuera así, para un posible atacante de esta red WiFi privada sería tan fácil como elegir él mismo cómo quiere configurarse la red. Volví a abrir el Terminal, para intentar conectarme por ssh al hotspot utilizando la cuenta de root, y la clave por defecto “admin”..... Owned! Cual fue mi sorpresa al ver que éste me recibía con los brazos abiertos:


Figura 8: La clave de root no estaba cambiada

En este instante me levanté sobresaltado, con el móvil en la mano y el post de El Lado del Mal que había comenzado a leer en la pantalla. La red WiFi privada había pasado a ser un entorno inseguro donde simplemente con el móvil desde la cama y en unos minutos, un atacante podría tener acceso completo a la consola del servidor que administra la red WiFi del hotel, para desde ahí poder hacer cualquier tipo de maldad: robar información, instalar una backdoor, saltar a otros servidores o clientes de la red... al estilo NSA. Nada de cosas "complicadas" como atacar WPA/WPA2, hacer cracking de las claves WPA/WPA2 o romper un hash MS-Chapv2 PPTP por diccionario o CloudCracker en una conexión PPTP.

No iba a conectarme a esa WiFi nunca, así que recopilé todos los datos y esperé a que una buena ducha luchara contra los efectos del alcohol para notificar en la recepción del hotel que deberían cambiar esa password

Autor: Deepak Daswani
http://deepakdaswani.es
http://twitter.com/dipudaswani

Fuente:
http://www.elladodelmal.com/2014/05/auditar-la-wifi-del-hotel-con-resaca-y.html

lunes, 16 de junio de 2014

Hacking WiFi: Cracking WPA/WPA2 con diccionario (Parte 12)

 Para realizar un proceso de crackeo de la contraseña de una red wireless WPA o WPA2 será tendremos que interceptar el 4 Way Handshake (los 4 paquetes que hemos visto que hacen falta para que se conecte un cliente con un AP). De esta manera ya tendríamos la información necesaria para lanzar un ataque de fuerza bruta con un diccionario. Lo que haremos será realizar todo el proceso de conexión entre cliente y AP por cada posible Passphrase (contraseña de la red wireless) y por ultimo el AP comprobará el valor MIC que es el que verifica si nuestro passphrase era correcto.
Pues vamos a probarlo. Para ello capturaré el handshake con Airodump-NG y para conseguir el Handshake necesito que alguien se conecte a la red, es decir, que lo más facil será echar a alguien de la red con un paquete de De-Autenticación, de esta forma conseguiremos que se vuelva a conectar de forma automatica.

# airodump-ng -c 11 -w cracking mon0 

# aireplay-ng --deauth 0 -a mon0



El siguiente paso será crearnos un diccionario, o coger uno de internet.



Y utilizaremos nuestro querido Aircrack-NG para realizar la prueba. 

# aircrack-ng -w dicc.txt cracking-01.cap 

Elegimos la red que queremos crackear y si la clave está incluida en el diccionario nos dirá cual es }:)




La clave que aparece con el nombre Master Key es la PMK de la que hemos hablado antes. Otra herramienta para realizar lo mismo es Cowpatty:
A la hora de crackear WPA2-PSK se usan los mismos principios que en el cracking de WPA-PSK. Hay que capturar el Handshake y seguir el mismo proceso. Es decir, si tienes un Passpfrase debil estarás en el mismo problema. Para ver si una red es es WPA o WPA2 podemos verlo en los Beacon Frames o Probe Responses. Es decir que con las mismas herramientas y mismos comandos podriamos crackear la captura WPA2 y descifrarla luego. 


Autor: Roberto Lopez (@leurian)

Fuente: http://www.flu-project.com/2014/01/hacking-wifi-cracking-wpawpa2-con.html

WPA2 con WPS: analizando

 Hoy hablaremos de como tratar WPS y como conseguir que hackear una WPA sea algo más rápido. WPS es algo que ha facilitado la configuración de las redes WPA/2 en las casas, pero que en muchos casos compromete la seguridad de la red inalámbrica. Vamos a exponer un pequeño ejemplo, en un escenario, el cual es el siguiente:
  • Punto de acceso con WPA2 y WPS activo y vulnerable.
  • Utilizaremos la herramienta reaver.
  • ¿Cómo detectaremos el WPS? Lo haremos de manera algo especial, con Wireshark.
Se configura el modo monitor, por ejemplo utilizando airodump-ng, y se captura el tráfico que circula por el aire. El objetivo es obtener una muestra los beacons de los puntos de acceso. Analizando este tráfico con Wireshark podemos ver en los paquetes donde se indica el SSID que el apartado tagged hay un campo WPS. Si se encuentra este campo, se puede indicar que el punto de acceso está utilizando WPS. 
Ahora, vamos a probar si el dispositivo es vulnerable. Mediante el uso de la herramienta reaver se realizará fuerza bruta sobre el punto de acceso enviando distintos PIN hasta encontrar el que le devuelva la credencial de la red con cifrado WPA2. Hay que tener cuidado con las configuraciones por defecto ya que éstas pueden provocar que WPS esté activo y el responsable del punto de acceso sea consciente de ello.

Hay que revisar las configuraciones wireless por defecto, y verificar que WPS no se encuentra activo, si queremos evitar dar facilidades en nuestra red.

Fuente: http://www.flu-project.com/2014/03/wpa2-con-wps-analizando.html

jueves, 5 de junio de 2014

FuzzAP: una herramienta para ofuscar redes inalámbricas


FuzzAP es un script en Python que puede generar un montón de puntos de acceso (APs) falsos para "ocultar" redes inalámbricas. Es similar a otras herramientas como FakeAP o AirRaid pero no es tan dependiente de los drivers de hardware.
En lugar de crear APs falsos reconfigurando las tarjetas de red inalámbricas lo que hace es utilizar directamente las tarjetas que soportan inyección de paquetes. Esto mejora la velocidad (no es necesario resetear el dispositivo de red) y permite utilizar un mayor número de modelos de tarjetas y drivers: rtl8187, ath5k, ath9k, la mayoría de ralink, etc... y en definitiva cualquier dispositivo que pueda funcionar en modo monitor vía airmon-ng.

La lista SSID utilizada fue obtenida de https://wigle.net/gps/gps/Stat y la lista de OUI de fabricantes fue parseada de http://standards.ieee.org/develop/regauth/oui/oui.txt (netgear, cisco, linksys, d-link, atheros, ralink, apple).

Requiere python 2.7, Scapy 2.2.0 y, como comentamos, tarjetas de red inalámbricas con drivers que soporten inyeccción de paquetes.

Para utilizarlo previamente hay que activar el modo monitor con airmon-ng (suite aircrack-ng):

airmon-ng start [interface]

FuzzAP.py requiere dos argumentos: el primero el interfaz a usar y el segundo el número de puntos de acceso falsos a generar:

python fuzzap.py [interface] [number of APs]

Proyecto GitHub: https://github.com/lostincynicism/FuzzAP
Fuente: http://www.hackplayers.com/2014/05/fuzzap-para-ofuscar-redes-wifi.html

Ingenierí­a Social aplicada al crackeo de redes WPA/WPA2

NOTA: este metodo puede o no funcionar, en mi caso fue simplemente un razonamiento aplicado a esta red. Pueda que nunca crackies un WPA/WPA2 con este funcionamiento.

LA HISTORIA:

resulta que estando con un par de amigos encontramos una red con buena calidad que era de un bar cercano llamado "Viejo Correo" y todos los pibes como me conocen... -Che, hackiate la red esa asi tenemos internet...- tipico como si fuera tan facil y bueno lo primero que hice fue ver el cifrado, cuando vi que era WPA2 con PSK (CCMP) les dije que era gratamente imposible, ya que es un cifrado muy sofisticado. entonces me dicen -y bueno proba haber que onda...- y bueno lo hice....

PROCEDIMIENTOS:

1.- la red se llamaba "Viejo Correo", se llamaba asi porque esta enfrente de un Correo; entonces cree un diccionario con palabras clave como:

correo
correozona
zonacorreo
correoviejo
correobar
correoviejobar
correobarviejo


y asi fui pensando contraseíñas que le podrian haber puesto. desde ya que la lista era un poco mí¡s larga. despues con el SGen fui creando diccionarios pero agregandole a cada palabra numeros; tome como referencia 4 numeros fue pura casualidad; enconces genere un diccionario con cada palabra + numero de 4 cifras. ejemplo:

correo0000 -> correo9999
correozona0000 -> correozona9999
correobarviejo0000 -> correobarviejo9999


aun asi sin saber el rango de digitos de la contraseíña pence que tendria que ser chica para que los clientes puedan escribirla ellos mismos. Enconces junte todo en un diccionario y me fui al AirUbuntu 10.04.

CRACKEO:

primero lance un airodump-ng para ver la informacion de la red.

Código: [Seleccionar]
airodump-ng -w cap mon0


luego hice:

Código: [Seleccionar]
airodump-ng -c 11 -w viejocorreo --bssid 54:E6:FC:AB:0B:48 mon0

ya ahora estaba capturando los #Datas. Espere a ver todos los users y seleccione el user con mayor transferencia de Paquetes.

Luego lance el Aireplay:

Código: [Seleccionar]
aireplay-ng -0 5 -a 54:E6:FC:AB:0B:48 -c 1C:4B:D6:68:92:2B mon0

sale handshake en airodump-ng y continuo con el crack:

Código: [Seleccionar]
aircrack-ng -w /home/diccionario.lst -b 54:E6:FC:AB:0B:48 viejocorreo-01.cap

y comenzo a crackear y a los pocos segundos ya la tenia crackeada, me quede duro de saber que la crackie sin ningun diccionario de 30GB que talves ni siquiera tenga la contraseíña. lo raro fue que las key que probí, figuran 8 pero probo como 3000... jjeje fue mí¡s pura suerte, los pibes se quedaron re contentos... jajaj  :'(



Comprobando la contraseíña:


TIPS PARA TENER EN CUENTA:
* nombre o nombres posibles de personas.
* ver el nombre de la red y preguntarnos ¿Que password le pondria?
* agragarle numero com referencia.

Fuente: http://www.arg-wireless.com.ar/index.php?topic=382.0

martes, 27 de mayo de 2014

Hackeando al vecino que me roba la WiFi

Buena entrada del maligno:

_________________________________________________________________________________

Hace unos meses, realizando pruebas de diferentes tipos de ataques sobre redes WiFi, dejé habilitada una red en casa con cifrado WEP, (eso sí, sin el SSID del operador con la contraseña por defecto predecible mediante las clásicas herramientas como Liberad a WiFi). Pasó el tiempo y dejé la red tal y como estaba, consciente evidentemente de que alguien podría querer invitarse algún día a la fiesta sin haber pagado la entrada, en cuyo caso ya mandaría yo a los de seguridad.

Pues bien, hace unos días, echando un vistazo a los Logs del servicio DHCP de mi router, cuál fue mi sorpresa al ver que además de la información de mis equipos, había una fila más con el nombre de host “Rober1”. En efecto, algún vecino estaba intentando utilizar mi red, y considerando que como poco había tenido que utilizar alguna herramienta para obtener la contraseña, podría tratarse de un vecino con conocimientos sobre hacking, aunque lo de poner su nombre en el hostname indicaba lo contrario (siempre y cuando no se tratara de un cebo). Por lo pronto, no conocía a ningún vecino llamado Rober o Roberto.

El primer impulso de cualquiera ante una situación así, podría ser el de cambiar el cifrado de la red a WPA2 con una clave robusta, y cortarle el grifo al vecino, pero los que nos dedicamos a esto de la seguridad, lo vemos como una excelente oportunidad para realizar una práctica con fuego real de hacking en redes de datos, al fin de todo, la red es mía y él es el intruso.

Como no disponía de mucho tiempo, pues esto me cogió justo antes de salir de casa a un compromiso ineludible, además de desconectar todos mis equipos de la red, y dejarle así todo el ancho de banda a “Rober1” para que se sintiese como en casa, mi primer paso fue poner rápidamente uno de mis equipos con Backtrack5, una antena WiFiy la suite Aircrack, a escuchar el tráfico de mi propia red en modo monitor. El objetivo era intentar obtener algún dato que me pudiese dar información acerca del vecino para conocer  sus intenciones, pues podría pretender simplemente utilizarme como ISP y ahorrarse la cuota mensual con esto de la crisis y los recortes, o “auditar” mis equipos, en cuyo caso debía prepararme para la batalla.

Al llegar a casa, y descifrar el tráfico capturado con airdecrypt, me dispuse a analizarlo 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 podría 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 que podía realizar es que se trataba de un equipo con sistema operativo Windows, de nombre “Rober1”, que estaba utilizando mi red para navegar por Internet. Analizando las tramas y las conexiones establecidas, los sitios webs más visitados durante la sesión de navegación, que duró cerca de 20 minutos, eran los siguientes:

http://www.vanitatis.com
http://www.elpais.com/gente
http://devilwearszara.com
http://www.fotoplatino.com
En la siguiente imagen se pueden observar algunas de las imágenes descargadas durante la sesión de navegación:


Figura 2: Imágenes presentes en la captura analizada con NetworkMiner

Sin querer entrar en un debate y limitándome a relatar en este artículo cuáles fueron mis suposiciones y el proceso mental seguido, mi primera impresión fue que más que tratarse de un hacker, se trataba de o bien una hacker o bien la amiga, novia, madre, hermana o esposa de “Rober1”, pues eran todas páginas de  lo que yo considero “marujeo”, orientadas más a un público femenino.

Realizando un análisis más profundo con herramientas como CookieCadger o Wireshark, también di con información exacta del equipo que estaba utilizando 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

El siguiente paso consistiría en intentar 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 mi vecino/a fuese a utilizar mi red para navegar. Para ello, utilicé Cain + Wireshark en entorno Windows, y también arpsoof en entorno Linux. Coincidimos un par de veces a la misma hora, pero resultó que en esas ocasiones el único tráfico que generaba mi vecino, era el correspondiente a visualizar vídeos en Youtube de bebés. Esto alimentó aún más mi sospecha de que se tratara de una mujer.

Por supuesto, en aquellas ocasiones en que coincidía conectado a la vez que mi vecino/a, antes de intentar un ataque MITM, me propuse escanear su máquina con nmap, pero los puertos estaban filtrados por el Firewall de Windows.

Seguía sin poder identificar al vecino, pues a pesar de tener acceso al tráfico que generaba, no existía ningún rastro de sitios donde se autenticara con credenciales. Ni correo, ni Facebook, ni nada en un principio. Los días fueron pasando, y cada vez era más difícil coincidir en horarios para realizar un MITM. Entre el trabajo y mi reciente estrenada paternidad, complicado cuadrar con el vecino/a.

Por otra parte, este tipo de ataque, no siempre funcionaba del todo bien, hecho que podía achacar también a la distancia del equipo a mi router, pero no penséis ni por un instante que lo iba a dejar así, ¡qué me estaba hackeando la WiFi!

Paralelamente a estos intentos, siempre mantenía mi equipo capturando tráfico WiFi en modo monitor, y analizaba las capturas, además de las que obtenía con Cain + Wireshark. En estas nuevas capturas, obtuve información interesante para el análisis.

Mi vecino/a se conectaba dos o tres veces al día, alrededor de 15 minutos cada sesión. Las páginas webs más visitadas seguían siendo de marujeo, como las comentadas en los párrafos anteriores, pero además habían accesos a las siguientes páginas:

http://elimperiodelaley.blogspot.com
http://quieroserjuez.blogspot.com
http://vidadeunaopositora.blogspot.com
http://sufridroaenejercicio.blogspot.com
http://quenovoyaserlasecretariadeunjuez.blogspot.com
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 robando WiFi. ¡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” ;) )
http://www.marca.com
http://tenerifedeportivo.com
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.

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 middle no 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áfico SSL 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

En este punto había completado mi análisis, y con un poco de Google Hacking a partir de su dirección de correo pude averiguar quiénes eran los vecinos, y confirmar que en efecto, se trataba de una pareja de abogados, ella estudiando para presentarse a una oposición de juez. Podría haberles hecho alguna trastada, como publicar algo en su muro, o cosas por el estilo, pero simplemente me limité a enviarles un correo informándoles de que estaba al corriente de lo que habían hecho, dándoles algunos detalles que les mostraran que efectivamente tenía conocimiento de sus sesiones de navegación, y advertirle de los peligros que corrían realizando este tipo de prácticas.

Me contestaron ofreciendo sus disculpas, comentándome que estaban avergonzados de su comportamiento y que no tenían mucha idea de lo que estaban haciendo, ya que fue “un amigo informático” el que les consiguió la conexión a Internet gratis.

Como ya todos sabemos, es impresionante toda la información que se puede obtener de una persona simplemente echando un vistazo a los sitios que visita en Internet, pero si además resulta que no sólo navega por páginas de información, sino que utiliza servicios de correo electrónico, redes sociales, o banca electrónica desde una conexión “robada”, el destrozo podría ser de dimensiones considerables.

Por motivos de protección de datos se ha sustituido el nombre real del equipo vecino por “Rober1”, pero el host original sigue la misma nomenclatura. Por otro lado quiero deciros que este artículo está hecho por si alguno de los lectores de este blog tiene una pareja de amigos que un día le piden que le robe la WiFi a algún vecino para conectarse gratis a Internet. Tened cuidado que, como decía Chema, la víctima del robo puede que también tenga también un amigo informático y les metas en un verdadero problema a tus amigos.

Deepak Daswani
(dipu.daswani@gmail.com)
(http://twitter.com/dipudaswani)

Fuente: http://www.elladodelmal.com/2013/04/hackeando-al-vecino-hax0r-que-me-roba_5.html

Un día de viaje: El blues (de la WiFi) del autobús

Muy buena entrada del maligno y sus colaboradores:

_______________________________________________________________________________

La disponibilidad de tecnologías WiFi “abiertas” cara al público que provén de Internet de forma gratuita, se ha convertido en una de las mayores facilidades que se le puede ofrecer a un usuario malintencionado para que lleve a cabo cualquier tipo de ataque sin dejar rastro de la identidad del mismo. Lugares como universidades, bibliotecas, restaurantes, bares, aeropuertos, etcétera, ofrecen conexión a los usuarios para que naveguen a sus anchas.

No hace mucho tiempo, volviendo en autobús de un viaje que tuve que realizar por motivos de trabajo, me dio por ojear el servicio WiFi que ofrecía la empresa para conectarse a Internet durante la duración del trayecto (que no era poco). Y como era de esperar existían multitud de direcciones IP (usuarios) que estaban utilizando dicho servicio.

Dejando de lado la multitud de ataques que se podrían realizar a los usuarios que están utilizando el servicio, ya que se supone que la WiFi precisamente se encuentra “abierta” para que todos los usuarios del autobús puedan conectarse y navegar sin ningún problema, decidí mirar qué “cacharro” era el que nos estaba ofreciendo el servicio y qué medidas de seguridad implementaba.


Figura 1: Portal del Router de Internet Móvil

Al primer intento de una de las contraseñas por defecto, ya me di cuenta que la respuesta se ofrecía por JavaScript y sin realizar ninguna petición a otra página, por lo que, la contraseña debería estar “incrustada” en el propio código de la página de acceso.


Figura 2: Alerta de contraseña incorrecta por Javascript

Con la ayuda de Firebug y un par de búsquedas vamos a intentar localizar la cadena exacta que nos interesa. Identificamos cómo existen varios tags “iframe” que están apuntando a distintos portales, los cuales pueden contener la cadena que estamos buscando. Entre ellos existe el fichero “/en/logo_idx.asp” que es el que contiene toda la parte de login.


Figura 3: Inclusión del iframe de autenticación

Cargamos el portal “/en/logo_idx.asp” dentro de nuestro navegador y visualizamos dónde se encuentra la cadena “Introduce tu contra..”, ya que se encontrará cerca de la zona del botón de submit, del que nos interesa saber qué función está realizando con la contraseña que introducimos nosotros en el “textbox”.


Figura 4: Función que se ejecuta cuando se envía la contraseña

Como se puede observar en la imagen anterior, al realizar el evento “onclick” del botón “Entrar” se está ejecutando a una función JavaScript llamada “LoginForm()”. Si buscamos dicha función en la pestaña de Scripts de Firebug, nos encontraremos con el siguiente código.


Figura 5: Contenido de la función JavaScript "LoginForm()"

Vemos que se está validando mediante la función “IF” el valor del elemento “password” con una variable llamada “admin_passwd”, la cual se encontrará inicializada en alguna parte del código. Mediante una simple búsqueda del nombre de la variable, damos con el valor que se inicializa la misma y con el correspondiente password del router.


Figura 6: Inicialización de la variable "admin_passwd"

A partir de aquí ya podemos acceder al portal del router y visualizar y/o modificar los parámetros de configuración.


Figura 7: Configuración Avanzada del Router Internet Móvil de Huawei

Y seguro que con toda esta información a muchos de vosotros se os ocurren muchos ataques man in the middle que se pueden realizar a los compañeros de viaje, pero ya bastante cansado es un viaje en autobús, como para que encima te roben la cuenta de Twitter, Tuenti o Facebook.


Figura 8: Usuarios conectados al servicio, potenciales víctimas

Como ya habréis leído y/o escuchado centenares de veces, la seguridad de las redes WiFi “abiertas” que ofrecen servicio a cualquier usuario sin ningún tipo de protección son de alto riesgo para los usuarios, pero quedan mucho más en entredicho si ni el propio fabricante del dispositivo utilizado para motarlas se preocupa de con qué grado de seguridad se están desarrollando sus dispositivos.

Un Saludo!! ;)

Autor: Daniel Romero, consultor de seguridad en Informática64

Fuente: http://www.elladodelmal.com/2011/12/un-dia-de-viaje-el-blues-de-la-wifi-del.html