Wireless Hacking – Evil Twin y Ataques MITM sobre SSL – Parte VI

En una entrada anterior de este blog se ha mencionado el uso de “airbase-ng” para crear un SoftAP que permitía a cualquier cliente conectarse a dicho AP como si se tratase de cualquier router, (ver el post aquí: https://thehackerway.com/2011/04/28/creando-un-fake-access-point-inalambrico-2/) la finalidad de crear un softAP desde el punto de vista de un atacante, es simplemente tener acceso al trafico de sus clientes, permitiéndole realizar ataques MITM. En este caso concreto, la técnica conocida como “Evil Twin” se basa en el hecho de que pueden existir dos AP con el mismo SSID y que utilizando utilidades como “aireplay-ng” se pueden enviar paquetes de “DeAuth” a todos los clientes conectados a un AP determinado, lo que al final puede desembocar en un ataque de denegación de servicio. Cuando un cliente se encuentra conectado en una red HotSpot, por ejemplo en un aeropuerto, un bar, un restaurante, un MacDonalds, normalmente no existen mecanismos de autenticación intermedios, es decir, son redes que normalmente se encuentran abiertas al publico en general, lo que facilita enormemente las cosas a un atacante.

Como ya se ha indicado anteriormente, cuando un cliente recibe un paquete de DeAuth por parte del AP (supuestamente del AP, pero que en realidad puede proceder de cualquier sitio) el cliente intenta realizar una “reasociación” con el AP, dado que este tipo de situaciones pueden ser el resultado de problemas con la señal, por esta razón el cliente intentará por un determinado periodo de tiempo establecer nuevamente la conexión con el AP, cuya única huella identificativa desde el punto de vista del cliente, es el SSID, si un atacante envía de manera continua e indefinida paquetes de “deautenticacion” a un cliente haciéndose pasar por el AP, el cliente finalmente tendrá que finalizar sus intentos de reasociación dado que los paquetes recibidos por parte del atacante indican que el AP no se encuentra en disposición de aceptar conexiones. En este punto el atacante perfectamente podrá crear su propio SoftAP (tal como se indicaba en el enlace anterior) estableciendo si lo desea, un servicio DHCP para la asignación automática de dirección IP a dicho cliente, si el atacante establece como SSID, el mismo nombre empleado por AP original, es posible que el cliente realice una conexión con el SoftAP del atacante en lugar de hacerlo con el AP original, no obstante, para que esto ocurra, la potencia de la señal del SoftAP debe ser mayor a la potencia del AP original (con lo cual, un atacante podrá utilizar mecanismos físicos para mejorar la potencia de la señal, como por ejemplo utilizando una antena dirigida), de esta forma, el cliente “encontrará” primero el SoftAP y creerá que se trata del AP original, en el caso de que esto no ocurra, el atacante tendrá siempre en ejecución su ataque de “DeAuthentication” contra el AP, lo que impedirá que el cliente consiga una asociación y lo que le obligará a seguir buscando hasta que el AP o cualquier dispositivo de software o hardware con el mismo SSID sea localizado. Este modelo es una falla de seguridad muy frecuente y fácilmente explotada por cualquier tipo de atacante sin necesidad de que cuente con un nivel de conocimientos profundo sobre redes.

Para demostrar esto con un ejemplo practico, seguir los siguientes puntos, asumiendo que WLAN_7188 en el SSID del AP original, 64:68:0C:45:71:BB es el BSSID (dirección MAC) del AP.

1. Con una interfaz en modo monitor, que en este caso es mon0 recibir Beacon frames del AP utilizando airodump-ng

   >airodump-ng –channel 3 –bssid 64:68:0C:45:71:BB mon0

   Se asume que el canal del AP es el 3.

2. Establecer las interfaces en dicho canal.

   >iwconfig wlan0 channel 3 >iwconfig mon0 channel 3

3. Iniciar el “Evil Twin” notar que es simplemente un Fake AP, tal como se ha comentado en una entrada anterior de este blog con el mismo SSID del AP real, una vez se inicia dicho Fake AP es necesario iniciar la interfaz virtual creada.

   >airbase-ng -a CA:CA:CA:CA:CA:CA -e WLAN_7188 mon0 >ifconfig at0 up

4. Iniciar el ataque de denegación de servicio contra el AP objetivo, para ello se enviarán paquetes DeAuth de forma indefinida contra todos los clientes de dicho AP (lo que posteriormente les obligará a intentar re-conectarse en múltiples ocasiones

   >aireplay-ng –deauth 0 -a 64:68:0C:45:71:BB mon0

5. Una vez establecidos los pasos anteriores, solamente es necesario esperar unos instantes y se podrá ver, como en la consola donde se ha iniciado el “Evil Twin” comenzarán a llegar las conexiones de los clientes que intentan asociarse nuevamente con el AP real, pero que al no poder, terminan asociándose con el Fake AP, que dado que tiene el mismo SSID, a efectos prácticos para el cliente son el mismo AP.

23:46:54 Client 44:A7:CF:47:82:88 reassociated (unencrypted) to ESSID: «WLAN_7188» 23:46:54 Client 44:A7:CF:47:82:88 reassociated (unencrypted) to ESSID: «WLAN_7188» 23:46:54 Client 44:A7:CF:47:82:88 reassociated (unencrypted) to ESSID: «WLAN_7188» 23:46:54 Client 44:A7:CF:47:82:88 reassociated (unencrypted) to ESSID: «WLAN_7188» 23:46:54 Client 44:A7:CF:47:82:88 reassociated (unencrypted) to ESSID: «WLAN_7188» 23:46:54 Client 44:A7:CF:47:82:88 reassociated (unencrypted) to ESSID: «WLAN_7188» 23:46:54 Client 44:A7:CF:47:82:88 reassociated (unencrypted) to ESSID: «WLAN_7188»

Por que ocurre esto? La respuesta es que los clientes, en ningún momento buscan “autenticarse” con el cliente, ellos solamente buscan un SSID que coincida con el están buscando, eso es todo, por esta razón no encuentra diferencia alguna entre un AP con cifrado a uno sin ningún tipo de seguridad, de igual forma intentará conectarse al AP que tenga el SSID de búsqueda y que tenga una intensidad en la frecuencia mayor, eso es todo lo que busca un cliente. Esto e un problema del protocolo de comunicaciones empleado ya que solamente existe autenticación por un lado (el AP) sin embargo el cliente nunca verifica que el AP es quien dice ser. Esto se solucionaría simplemente con un mecanismo de autenticación mutua entre cliente y AP.

Ahora bien, esta no es la única “falla” en el proceso que utilizan los clientes para acceder a redes inalámbricas, dependiendo del sistema operativo, muchos clientes almacenan localmente las conexiones que han realizado contra otros AP, almacenando en dichos repositorios el SSID y la clave del AP. Por defecto los clientes cuando tienen uno o varios AP almacenados en el repositorio de conexiones del sistema, intentan de forma automática (nuevamente dependiendo del sistema operativo del cliente y sus correspondiente configuración) realizar pruebas de conexión, enviando los paquetes que se han mencionado anteriormente para el descubrimiento de AP’s cercanos, estos paquetes son los PROBE REQUEST, de esta forma, un cliente de forma automática envía paquetes PROBE REQUEST a todos los AP que se encuentren almacenados en su repositorio de conexiones, de esta forma y en el caso de que algún AP responda a dicha prueba con un paquete PROBE RESPONSE, el cliente automáticamente intentará realizar una asociación con dicho AP, luego el AP será el que determine si el cliente se puede conectar o no dependiendo del esquema de autenticación establecido. Esto que significa? Pues ocurre lo mismo que con Evil Twin, en cualquier momento se puede iniciar un AP falso utilizando un SSID conocido por el cliente y este a su vez, intentará conectarse de forma automática y sin interacción con el usuario, con el AP que tenga el SSID solicitado, si dicho SSID es prestado por AP malicioso, el cliente puede estar corriendo un serio riesgo.

Además de lo anterior, también es importante resaltar que con herramientas como airbase-ng, se puede iniciar un Fake AP de tal modo que responda a TODOS los paquetes PROBE REQUEST que los clientes que se encuentran alrededor envían cuando se quieren conectar con un AP, el resultado de esto es que los clientes que tengan varias conexiones almacenadas enviarán paquetes PROBE REQUEST por el canal Broadcast y el Fake AP responderá a TODOS los paquetes, con lo cual el cliente tendrá la “sensación” de que ha realizado una conexión a todos los AP en su lista. Un cliente (una tarjeta wireless) solamente puede tener una conexión con un AP al mismo tiempo, del mismo modo que solamente puede estar en un único canal a la vez, por esta razón, lo más probable es que con un AP configurado para contestar a todas las peticiones, los clientes tendrán problemas para resolver a cual AP se deben conectar e intentará conectarse a todos de forma “intermitente”.

Para ejecutar el Fake AP en dicho modo y responder a todas las peticiones de SSID, se ejecuta el siguiente comando con airbase-ng

>airbase-ng -v -a AA:AA:AA:AA:AA:AA -P -C 15 mon0

En el comando anterior, puede apreciarse que en primer lugar no se ha establecido ningún SSID, esto es porque va a responder a las peticiones de cualquier cliente solicitando cualquier SSID, luego la opción -v es indicada precisamente para apreciar que es exactamente lo que esta pasando (cuales peticiones de SSID se han resuelto y por cual cliente)

ATAQUES MITM SOBRE CONEXIONES SSL

Tomando como punto de partida los ejemplos que se han indicado anteriormente sobre la creación de un SoftAP, utilizando la técnica de “Evil Twin” o simplemente dejando “abierta” la red sin ningún tipo de autenticación y esperando a que otros clientes se conecten. Tener a clientes que se conectan a una máquina controlada por un atacante, le da la oportunidad a este de realizar ataques interesantes que pueden llevar a comprometer completamente las comunicaciones que un usuario realiza de forma “segura” por internet, utilizando servicios tales como HTTS/SSL/TLS para realizar el cifrado end-to-end con el servidor web. Para ello se puede seguir la metodología de ataque que se indica a continuación

 

El principio fundamental de este tipo de ataque radica en la capacidad que adquiere el atacante sobre la navegación de sus víctimas, pudiendo controlar las peticiones DNS sobre servidores web y posteriormente haciendo entrega de certificados falsos a estos para que sea posible establecer la comunicación cifrada contra el servicio real en internet. En este caso concreto el flujo de los paquetes es el siguiente:

1. La víctima, que se encuentra conectada al AP del atacante, solicita la conexión con un sitio en internet (un sitio con Soporte SSL/TLS en este caso) para iniciar sesión de forma segura, dado que para ello es necesario resolver el nombre del dominio, es necesario que el cliente realice una consulta DNS, para ello el SoftAP tendrá un servidor DNS “falso” que retornará la dirección IP del atacante
2. El cliente recibe como respuesta una dirección IP que presumiblemente es la dirección del servicio en internet al que intenta conectarse, no obstante, en realidad es la dirección IP del atacante.
3. El atacante recibe una petición en el puerto 443 (HTTPS) la cual será controlada por Burp Suite (se hablará en mayor profundidad sobre Burp en próximas entradas sobre Web Hacking) el cual generará un certificado falso y lo enviará al cliente
4. La víctima, recibe una advertencia sobre un certificado del que no es posible verificar su identidad, si la víctima acepta el certificado de todas formas, la navegación hacia el sitio remoto será exactamente igual a como lo hace siempre, sin embargo todos los paquetes que envié (aunque utilice SSL) pasan por medio del atacante y son visualizados en texto claro, dado que el certificado utilizado por el cliente para la conexión es del atacante y este tiene la clave privada para descifrar dichos paquetes, con lo cual verá absolutamente todo (incluyendo passwords) en texto claro.

Esta es la metodología utilizada para realizar un ataque contra clientes que utilizan SSL en sus comunicaciones con otros servidores web, a continuación se indican los pasos que se deben llevar a cabo para implementar todo esto:

1. Iniciar un “Fake AP” el cual tendrá configurado un servicio DHCP para asignar a cada cliente una dirección IP, de tal forma que pueda continuar navegando sin problemas por internet utilizando la conexión a internet que tiene el atacante, para llevar a buen termino este paso se recomienda ver la entrada anterior en este blog donde se habla de como hacerlo aquí: https://thehackerway.com/2011/04/28/creando-un-fake-access-point-inalambrico-2/
2. Una vez iniciado el AP y establecido las reglas del firewall correspondientes al correcto enrutamiento de los paquetes por medio de la interfaz de salida a internet, se procede a iniciar el servicio de DNSSPOOF, el cual resolverá todas las peticiones DNS del cliente con la dirección IP del atacante, para ello es necesario tener instalada la suite DSNIFF la cual se puede obtener aquí: http://monkey.org/~dugsong/dsniff/ para conocer un poco más sobre esta suite, aquí hay un articulo introductorio https://thehackerway.com/2011/03/29/tecnicas-basicas-de-sniffing-y-mitm/Ahora bien, para iniciar DNSSpoof solamente es necesario iniciar una nueva consola y ejecutar esta utilidad, la cual en realidad es muy sencilla, las opciones que se incluyen son:
   

   >dnsspoof –help dnsspoof: invalid option — ‘-‘ Version: 2.4 Usage: dnsspoof [-i interface] [-f hostsfile] [expression]

   Como puede apreciarse, se debe indicar una interfaz de red y un fichero, el cual tendrá la misma forma que el fichero de hosts de Linux. En el caso de que no se especifique un fichero de host, todas las peticiones DNS serán resultas con la dirección IP del atacante.

   >dnsspoof -i at0 dnsspoof: listening on at0 [udp dst port 53 and not src 192.168.2.129]

   En este caso la interfaz de red “at0” es la interfaz del Fake AP.

3. Ahora es el momento de manipular e inyectar el trafico de la víctima utilizando Burp Suite, esta herramienta es una plataforma integrada para ejecutar pruebas de seguridad sobre aplicaciones web, contiene algunas opciones que permiten capturar, controlar y enrutar las peticiones realizadas por clientes utilizando HTTP/HTTPS. El objetivo de esta entrada no es profundizar sobre Burp Suite, esto es algo que se hará próximamente en este blog. En primer lugar es necesario descargar la versión libre de esta herramienta desde aquí: http://portswigger.net/burp/download.htmlPara utilizarla solamente es necesario descomprimirla y ejecutar el fichero JAR incluido en ella. Es necesario tener una versión de Java instalada que sea como mínimo la 1.5
   

   >java -jar burpsuite_v1.4.01.jar

4. Ahora es necesario comenzar a configurar el proxy que servirá para realizar el paso final del ataque, esto se hará desde Burp en la pestaña “Proxy → options” la configuración necesario puede apreciarse en la siguiente imagen
   Como puede verse, se han establecido los puertos 80 (HTTP) y 443 (HTTPS) para recibir peticiones de los clientes que se conecten a un sitio web seguro o no seguro, en todos los casos Burp interceptará las comunicaciones, por otro lado también se generan certificados autofirmados con el fin de establecer conexiones seguras con HTTPS pasando por la máquina del atacante y finalmente al sitio web “seguro”.
5. Cuando un cliente intente contactar con cualquier sitio web, la pestaña “Intercept” se activará automáticamente capturando los encabezados de la petición y todos los datos que se han ingresado, en el caso de un sitio con HTTPS todos los datos sensitivos como claves y nombres de usuarios se verán en texto claro.

Aunque en este vector de ataque se ha utilizado DNSSpoof, es perfectamente valido utilizar otras herramientas como por ejemplo Ettercap con su plugin “dns_spoof”, cualquiera de los dos mecanismos puede ser empleado con éxito para la manipulación de peticiones DNS.