ACTUALIZADO A DÍA 01/02/2021

Algo de lo que no se ha hablado en entradas anteriores es el concepto de Hidden SSID (SSID Oculto) que como su nombre lo indica, no hace publico el SSID del AP con el fin de que solamente determinados clientes (evidentemente aquellos que conozcan el AP) puedan realizar el procedimiento de autenticación y asociación correspondiente.

Este es un claro ejemplo de “Seguridad mediante la ofuscación” ya que la finalidad de ocultar el SSID es precisamente “esconder” el identificador de la red inalámbrica a usuarios que no deberían de conectarse. Se trata de una técnica que puede ser muy útil para evadir un atacante con pocos conocimientos y/o experiencia, sin embargo es un mecanismo poco eficiente para un atacante con unos conocimientos medios sobre redes inalámbricas. El primer paso para identificar si existe un AP cercano cuyo SSID se encuentra “oculto”, consiste en utilizar wireshark (o cualquier sniffer), con el fin de identificar los Beacon Frames que dicho AP emite, es decir, aunque el AP tenga oculto su SSID, este continuará enviando señales Broadcast, la única diferencia es que cuando estos Beacon Frames sean capturados por el sniffer dichos paquetes no tendrán la información relacionada con el nombre del SSID, en su lugar aparecerá algún carácter repetido o una secuencia de ceros donde frecuentemente aparece el SSID del AP.

Como puede apreciarse no aparece el identificador del AP (SSID), sin embargo sí que se puede ver el canal actual del AP que es el 3. Por otro lado, consultado las cabeceras del paquete puede verse claramente el BSSID del AP, tal como se aprecia en la siguiente imagen

Utilizando esta información se ejecuta la herramienta airodump-ng filtrando con dicho BSSID y el canal 3 de la siguiente forma

airodump-ng –channel 3 –bssid 64:68:0c:45:71:8b mon0

Con esto solamente aparece un único registro correspondiente al AP con SSID oculto, en la columna ESSID de un AP con SSID frecuentemente se suele ver algo como <length: #>

Ahora, con esta información como se puede saber cual es el SSID del AP que está enviando tales frecuencias?

Para descubrir un SSID oculto, pueden utilizarse dos mecanismos, por un lado, esta el mecanismo “pasivo” y por otro lado esta el mecanismo activo. A continuación se explican un poco más en detalle ambos métodos

Mecanismo Pasivo para descubrir un AP con SSID oculto

Como se ha indicado con anterioridad, cuando se inicia la conexión con un AP, se intercambian una serie de paquetes de reconocimiento, uno de dichos paquetes es el “Probe Request” al cual el AP responderá con un “Probe Response” en el contenido de dichos paquetes se incluye el SSID en texto claro, así de simple, lo único que se necesita es tener un sniffer como wireshark filtrando por el BSSID y esperar (utilizando, evidentemente una interfaz en modo monitor), de esta forma, cuando un cliente de dicho AP se conecte (que conoce cual es el SSID) los paquetes del proceso de asociación serán fácilmente capturados por wireshark, permitiendo de esta forma consultar posteriormente cual es el SSID.

Este mecanismo se le conoce como “pasivo” dado que depende de que un cliente del AP se conecte con el SSID oculto, lo busque y posteriormente el AP responda a dichas peticiones, tal como se muestra en la siguiente imagen, donde el AP envía paquetes “Probe Response”

Mecanismo Activo para descubrir un AP con SSID oculto

El mecanismo anterior requiere que existan clientes que deseen “localizar” y/o conectarse con el AP y posteriormente esperar, pero qué pasa si no se cuenta con el tiempo o la paciencia necesaria? Es aquí donde se puede emplear un mecanismo activo para descubrir el SSID oculto de un AP. La intención en este caso es forzar al AP a enviar paquetes “Probe” y “Association” y posteriormente capturar el SSID del AP, esto se hace siguiendo una metodología muy simple, que se basa en la comunicación que tienen los clientes con el AP. Cuando un cliente intercambia datos con un AP, tiene un canal establecido que es reconocido por el AP como “asociación” del cliente, esto quiere decir que el AP entiende que los paquetes recibidos por dicha entidad inalámbrica (cliente) deben ser procesados ya que cumple con las normas impuestas (autenticación y asociación), ahora bien, cuando la conexión entre un AP y un cliente se interrumpe, el cliente frecuentemente intenta volver a conectarse con el AP enviando paquetes de “Re-Asociación” lo que conlleva a que se inicie nuevamente el proceso de intercambio de paquetes del tipo “Probe Request” y “Probe Response”, a partir de esto, el uso de un sniffer como wireshark hará el resto del trabajo capturando los paquetes de respuesta del AP.

La pregunta natural en este caso es, como interrumpir la conexión entre un cliente un AP?
Para cumplir con este objetivo se puede utilizar la utilidad “aireplay-ng” la cual se encuentra incluida en el paquete aircrack-ng. Esta utilidad permite enviar de forma constante paquetes del tipo “DeAuth” a todos los clientes o a un cliente en concreto del AP, este paquete es un subtipo de los paquetes Management y permiten interrumpir la conexión entre cliente(s) y AP. El comando ejecutado sería en este caso el siguiente

>aireplay-ng –deauth 0 -a 64:68:0c:45:71:8b mon0

En el comando anterior, se crean paquetes deauth con la opción –deauth, posteriormente el número indica que se van a enviar paquetes de este tipo de forma indefinida, aunque se puede especificar un valor mayor a 0 para indicar un número fijo de paquetes a enviar, la opción «-a» indica el BSSID del AP y finalmente se establece la interfaz en modo monitor utilizada para llevar a cabo el envío del paquete.

Cuando se termine el ataque, (es decir, cuando se considere oportuno terminar la ejecución del bucle de paquetes de deautenticacion) el procedimiento de autenticación y re-asociacion se volverá a llevar cabo tal y como se enseña en la siguiente imagen, donde se puede ver claramente, como uno de los clientes conectados a dicho AP, ha tenido que volver a iniciar todo el proceso de conexión con el AP, incluyendo el envío de paquetes de autenticación.

La imagen anterior, ha enseñado que además de forzar a uno o varios clientes a comenzar nuevamente el procedimiento de autenticación y asociación con el AP, también se ha obtenido el SSID del AP de forma correcta, sin necesidad de esperar a que un cliente por cuenta propia iniciará la conexión con el AP.

EVADIENDO MAC FILTERS

Los filtros por MAC son una característica bastante utilizada en las redes wireless, tal como su nombre lo indica, su finalidad es establecer una restricción de acceso a una red inalámbrica determinada solamente a aquellos frames cuyo origen contenga una dirección MAC en la lista de direcciones admitidas, evidentemente en el caso de que dicha MAC no coincida, cualquier intento de conexión es rechazado de forma automática.

Este modelo no es “nuevo” ni mucho menos propio de las redes inalámbricas, es un mecanismo de seguridad heredado de las redes cableadas que normalmente se ha implementado por seguridad contra ataques de ARP Spoofing, definiendo listados de direcciones MAC – IP de forma permanente, de modo que se dificultan ataques del estilo MITM. Por otro lado este tipo de soluciones también se han implementado en Firewalls a nivel de puertos, donde solamente un listado determinado de direcciones MAC/IP puede realizar conexiones a determinados puertos.

Este mecanismo en el mundo de las redes cableadas tiene sus dificultades y para un hacker armado con suficiente información sobre el segmento de red en el que se encuentra, evadir este tipo de filtros puede ser una tarea más o menos simple dado que las direcciones MAC son fáciles de spoofear. Por otro lado, aunque en las redes cableadas tipo Ethernet o Token Ring crean “whitelists” y filtros por MAC que son relativamente seguros, en el mundo de las redes inalámbricas no lo es tanto, la principal razón es debido a que los MAC filters no son parte del protocolo IEEE 802.11 lo que quiere decir que es una característica que debe ser implementada directamente en el AP, además de esto, como se ha visto anteriormente con el uso de wireshark (o cualquier tipo de sniffer), los frames inalámbricos contienen dentro en sus cabeceras, información relacionada con las direcciones MAC de clientes y APs, por lo tanto, es realmente sencillo saber cuales MAC de clientes son legítimos para un determinado AP.

Para probar los conceptos anteriores, se pueden seguir los siguientes pasos:

1. Habilitar los filtros por direcciones MAC directamente en el AP, prácticamente todos los AP inalámbricos modernos tienen esta característica implementada en su correspondiente interfaz administrativa. Una vez realizada esta configuración, solamente los clientes con una dirección MAC valida para el AP, podrán llegar hasta la etapa de asociación con el mismo. Para probar que el filtro funciona adecuadamente, basta con intentar realizar una conexión con dicho AP desde cualquier máquina con una MAC no admitida.
   Ahora bien, también se puede realizar un intento de autenticación/asociación falsa con aircrack-ng, en tal caso, el mensaje de error será el siguiente

aireplay-ng –fakeauth 10 -e WLAN_7188 mon0 No source MAC (-h) specified. Using the device MAC (4C:0F:6E:E9:7F:16) 21:08:18 Waiting for beacon frame (ESSID: WLAN_7188) on channel 3 Found BSSID «64:68:0C:45:71:8B» to given ESSID «WLAN_7188». 21:08:19 Sending Authentication Request (Open System) [ACK] 21:08:19 AP rejects the source MAC address (4C:0F:6E:E9:7F:16) ? Authentication failed (code 1) 21:08:22 Sending Authentication Request (Open System) [ACK] 21:08:22 AP rejects the source MAC address (4C:0F:6E:E9:7F:16) ? Authentication failed (code 1) ^C

• Hasta este punto se ha visto que en efecto, los filtros establecidos en el AP funcionan, para evadir dichos filtros, se cuenta con la opción de “sniffear” la red, capturar paquetes de usuarios ya asociados con dicho AP y simplemente utilizar dicha MAC, en el caso de que se encuentren clientes asociados, para buscar dichos clientes “airodump-ng” es perfecto, ya que enseña la dirección MAC del AP y la dirección MAC del cliente asociado en un formato sencillo, por ejemplo:
  

  >airodump-ng –bssid 64:68:0c:45:71:8b –channel 3 mon0 CH 3 ][ Elapsed: 24 s ][ 2011-10-21 21:47 BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID 64:68:0C:45:71:8B -33 100 232 0 0 3 54 WPA CCMP PSK WLAN_7188 BSSID STATION PWR Rate Lost Packets Probes 64:68:0C:45:71:8B 44:A7:CF:47:82:88 0 0 – 1 0 8

Una vez obtenida una dirección MAC asociada con un AP, usarla es tan sencillo como ejecutar lo siguiente:

>aireplay-ng –fakeauth 10 -e WLAN_7188 -h 44:a7:cf:47:82:88 mon0 The interface MAC (4C:0F:6E:E9:7F:16) doesn’t match the specified MAC (-h). ifconfig mon0 hw ether 44:A7:CF:47:82:88 21:27:24 Waiting for beacon frame (ESSID: WLAN_7188) on channel 3 Found BSSID «64:68:0C:45:71:8B» to given ESSID «WLAN_7188». 21:27:24 Sending Authentication Request (Open System) [ACK] 21:27:24 Authentication successful 21:27:24 Sending Association Request [ACK] 21:27:24 Association successful 🙂 (AID: 1)

Se puede apreciar el uso de la opción “-h” indica que el paquete que se construirá para enviar la falsa autenticación al AP, tendrá en el campo de «Source» la dirección MAC valida, lo que posteriormente será aceptado por dicho AP.

Como puede verse, los filtros MAC no son una medida de seguridad fuerte, de hecho, son una medida de seguridad útil si no existe ningún cliente asociado. La implementación de medidas de seguridad más serias, se verán en las próximas entradas de esta serie.

 

Un saludo y Happy Hack!
Adastra.