Forzando la desconexión de los clientes WiFi

En el post anterior, vimos como podíamos forzar la desconexión de los clientes WiFi lanzando un broadcast de tramas de desconexión suplantando (spoofing) la dirección MAC del punto de acceso.

En este post vamos a ser más selectivos, vamos a hacer que se desconecte un cliente concreto (la Raspberry) de la red, mediante el envío de una trama de desconexión dirigida en concreto a ese cliente. Esto podría ser una forma de ataque de denegación de servicio, dirigido a ese cliente concreto.

En principio, lo que necesitaríamos conocer es:

  • Dirección MAC del punto de acceso.
  • Canal de conexión
  • Dirección MAC del cliente al que queremos desconectar.

Las dos primeras, como hemos visto, son fáciles de obtener y la tercera la obtendremos escuchando la red WiFi. Por lo tanto, vamos a poner la interface en modo monitor e iniciar la captura con Wireshark. Generaremos tráfico desde la Raspberry para capturarlo:

Screenshot from 2016-11-09 07-22-42

Imagen1

Tras una breve captura vemos las tramas ICMP correspondientes al ping:

Screenshot from 2016-11-09 17-39-41

Averiguamos que la estación a la que queremos forzar la desconexión tiene como dirección IP la 192.168.200.129 y, como dirección MAC la siguiente: 00:0f:60:06:6d:d7.

Lo que tenemos que hacer ahora es lanzar la trama de desconexión a la dirección MAC de la estación a la que queremos desconectar:

Screenshot from 2016-11-09 18-08-46

Vemos en Wireshark, las tramas de desconexión:

Imagen3

Y las tramas DHCP y ARP lo que nos permite ver la dirección IP asignada a la estación atacada:

Imagen6

Imagen5

Imagen7

Destapando SSIDs (en el lado salvaje)

En el anterior post descubríamos los SSIDs ocultos escuchando paciente y silenciosamente las peticiones de conexión enviadas desde las estaciones a los puntos de acceso. La ventaja de este mecanismo es que trabajamos escuchando, sin hacernos presentes en el entorno. Sin embargo, no en todos los casos, se tiene el tiempo o, simplemente escuchando, no conseguimos nada.

El objetivo de este post es presentar un método alternativo más rápido que consiste en inyectar paquetes de desconexión en la red para forzar la reconexión de los equipos al punto de acceso y, por lo tanto, forzar el revelado del SSID. La desventaja de este método es que puede hacer patente nuestra presencia a mecanismos de detección de intrusiones en la red inalámbrica.

Como puntos de partida, asumimos que conocemos la dirección MAC del punto de acceso y el canal empleado. Ya, en posts anteriores, vimos como obtenerlos (iwlist, iwconfig, etc.) por lo que no voy a volver a describirlo.

Para empezar, ponemos la interfaz wlan1 en modo monitor y la sintonizamos al canal del punto de acceso.

Screenshot from 2016-11-09 07-22-42

Para inyectar las tramas de desconexión, vamos a usar la herramienta aireplay-ng del conjunto de herramientas aircrack-ng. Arrancamos, en primer lugar Wireshark y lo ponemos a capturar paquetes. Desde una terminal, lanzamos el comando necesario para inyectar las tramas de desconexión:

Screenshot from 2016-11-09 07-36-41

Destripando el comando anterior:

  • La opción 0 indica que se trata de un ataque de desconexión forzada.
  • El número 5 es el número de tramas de desconexión lanzadas.
  • El parámetro –a establece la dirección MAC del punto de acceso a la que vamos a hacer spoofing.
  • El flag ignore-negative-one sirve para ignorar el error en caso de que no pueda determinarse el canal de la interfaz.
  • Por último se pasa la interfaz empleada para la inyección.

Poniendo el filtro adecuado en Wireshark, podemos ver las tramas de broadcast de desconexión enviadas:

Screenshot from 2016-11-09 07-48-44

Y, cambiando el filtro de nuevo para ver todas las tramas (que no sean tramas faro) emitidas o recibidas por nuestro punto de acceso, podemos ver como nuestra Raspberry se desconecta y vuelve a conectarse revelándonos el ESSID en la petición de conexión.

Screenshot from 2016-11-09 07-54-33

Simple y eficaz.

Destapando SSIDs

Las redes WiFi son inseguras por naturaleza, el medio de transmisión es abierto y accesible. A lo largo del tiempo se han ido implementando mecanismos de seguridad para proteger la información intercambiada sobre estas redes. Algunos de estos mecanismos no han sido efectivos.

Un ejemplo de una medida ineficaz, desde el punto de vista de la seguridad es ocultar el SSID de la red. Esta técnica consiste en ofuscar el SSID de forma que el punto de acceso no lo emita en claro (ejemplo claro de seguridad por oscuridad). Sin embargo, todas las estaciones que se conectan a la red deben conocerlo para poder conectarse. Ocultar el SSID es una medida orientada no a proteger sino a ocultar.

En la configuración por defecto de los puntos de acceso WiFi, éstos retransmiten el SSID en sus tramas de faro (beacon). Sin embargo, el punto de acceso se puede configurar para que no retransmita el SSID en claro. De esta forma, sólo los clientes que conozcan el SSID podrán conectarse a la red. Ocultar el SSID, como veremos, es un mecanismo de protección muy débil y no debe considerarse, bajo ningún concepto, como una medida de seguridad. Descubrir el SSID es relativamente fácil.

Con Wireshark podemos ver el SSID emitido en las tramas faro de los puntos de acceso (asumiendo que tenemos nuestra interfaz en modo captura). El SSID aparece en texto plano en el cuerpo de la trama:

Screenshot from 2016-11-05 07-28-37

La estructura de las tramas faro es como sigue:

Imagen5

Los dos primeros bytes del SSID son la longitud (¿?) (0x000a == 10) del SSID y, a continuación, aparece el propio SSID (HACKME_001).

Vamos a ocultar el SSID de nuestra red y vamos a ver cómo podemos obtener esta información. Para deshabilitar la emisión del SSID, entramos en la administración del punto de acceso y activamos la opción correspondiente. En cada equipo puede ser distinto:

Imagen3

Ponemos la interfaz en modo captura y lanzamos de nuevo Wireshark:

Screenshot from 2016-11-05 08-47-48

Imagen6

Vemos que, en lugar de los caracteres del SSID aparecen nulos (0x00) pero, aparentemente, la longitud del SSID (10) es la del SSID oculto.

Para descubrir el SSID oculto, lo único que tenemos que hacer es escuchar de forma pasiva y esperar a que se conecte un cliente legítimo a la red. La conexión del cliente generará dos tramas (probe request, probe response) de las que podemos sacar la información que nos falta.

Por ir paso a paso:

1. Obtenemos información de la WLAN a la que nos queremos conectar (comando iwlist).

Screenshot from 2016-11-05 09-04-54

Con el comando iwlist obtenemos la dirección MAC (nos va a servir para filtrar en Wireshark) y el canal.

2. Ponemos la interfaz en modo monitor:

Screenshot from 2016-11-05 09-07-49

3. Configuramos la interfaz para que escuche en el canal 9.

Screenshot from 2016-11-05 09-09-34

4. Lanzamos Wireshark y esperamos a que se conecte un cliente (Raspberry) quedándonos con las tramas Probe Request y Probe Response:

Screenshot from 2016-11-05 10-12-06

Éste es el filtro aplicado:

Imagen7

Ésta es la información de la trama Probe Request con el SSID:

Imagen8

Y ésta es la información de la trama Probe Response, asimismo con el SSID oculto:

Imagen9

Bueno, ya hemos visto cómo averiguar el SSID oculto.

Esnifando tramas 802.11

Con el entorno ya montado, lo primero que voy a hacer va a ser capturar información de las tramas 802.11 que circulan en el espacio radioléctrico de mi casa. Por supuesto, me voy a limitar a mis propios puntos de acceso (redes WLAN domésticas y la WLAN de lab) ya que, de otra forma, estaría incurriendo en una ilegalidad flagrante. Espero que si alguien lee esto, sea consciente de la responsabilidad que adquiere al montar un entorno como éste.

Por otra parte, dado que voy a estar jugando con estos temas un tiempo he decidido substituir la interfaz USB Belkin Wireless G F5D7050 por una más moderna Alfa AWUS036H con antena de 5dBi:

31vwECQvXoL

Una vez conectada y realizada la configuración básica de red con la interfaz instalada como wlan1, tenemos lo siguiente:

Screenshot from 2016-11-01 13-08-34

Voy a probar las capacidades de escaneo de la nueva interfaz mediante el comando iwlist. Lo que veo es que capta muchas redes WiFi próximas:

Screenshot from 2016-11-01 13-13-24

Por último, antes de meternos en mayores profundidades, conviene recordar los detalles de las tramas 802.11 que vamos a capturar. El estándar 802.11 define tres tipos de tramas (más detalles aquí):

a) Tramas de gestión

Se encargan de la gestión de la comunicación entre los puntos de acceso y los clientes. Existen distintos tipos de tramas para controlar aspectos tales como la autenticación, las solicitudes de asociación y desasociación de puntos de acceso, tramas de faro (beacon) de los puntos de acceso, etc. En estas es en las que vamos a estar, en general, más interesados para la penetración en la red.

b) Tramas de control

Se encargan de asegurar el intercambio apropiado de datos entre los clientes y los puntos de acceso, permitiendo arbitrar el acceso al medio compartido.

c) Tramas de datos

Son las que transportan los datos intercambiados por los clientes.

La estructura de campos de las tramas 802.11 se presenta en la siguiente imagen:

802dot11_frame

Para empezar a capturar tramas, vamos a poner la interface (wlan1) en modo monitor. Para ello vamos a utilizar el script airmon-ng de la suite de herramientas aircrack-ng. En, primer lugar, vamos a comprobar si la interfaz que vamos a utilizar para captura es visible para airmon-ng ejecutando el script sin argumentos:

Screenshot from 2016-11-01 19-54-15

Vemos que aparece la interfaz wlan1, vamos a ponerla en modo monitor. Para ello, lanzamos el comando airmon-ng start wlan1:

Screenshot from 2016-11-01 19-56-57

El script crea una nueva interface en modo monitor (wlan1mon), esto se puede ver volviendo a ejecutar el script airmon-ng sin argumentos y, por supuesto, mediante el comando iwconfig.

Screenshot from 2016-11-01 19-59-48

Bien, ya tenemos la interface configurada en modo monitor, ahora, lo que tenemos que hacer es empezar a capturar los paquetes para analizarlos.

Para hacer la captura voy a utilizar el archiconocido programa Wireshark. Lanzamos desde la línea de comandos la ejecución del programa en segundo plano (wireshark &) y nos aparece la ventana principal del programa:

Screenshot from 2016-11-02 07-44-39

Seleccionamos la interface a través de la que se van a capturar los paquetes (wlan1mon) y pulsamos la aleta de tiburón azul de la parte superior izquierda para empezar la captura:

Screenshot from 2016-11-02 07-44-59

En pocos momentos, se puede capturar una gran cantidad de paquetes, sobre todo si hay distintas WLAN y éstas tienen una gran cantidad de tráfico. Vamos a emplear la funcionalidad de filtrado de Wireshark para ver sólo los paquetes de nuestro punto de acceso (BSSID = 00:11:50:86:64:ab):

Screenshot from 2016-11-02 08-09-29

Ahora vamos a ver sólo las tramas de gestión. Las tramas de gestión tienen el subcampo campo ‘type’ del campo Frame Control (fc) a 0:

Screenshot from 2016-11-02 08-13-25

Modificando el filtro podemos ir viendo los distintos tipos de tramas.

Ahora vamos a iniciar el ejercicio de capturar las tramas de la WLAN lab. Voy a asumir que, lo único que conozco es el SSID de la red (que es “HACKME_001”). Para capturar las tramas de esa WLAN necesito dos cosas:

  • El BSSID de la red (dirección MAC del punto de acceso).
  • El canal radio que emplea.

Lo primero que hago es poner la tarjeta en modo monitor:

Screenshot from 2016-11-04 15-37-50

A continuación lanzo el comando airodump-ng wlan1mon para ver las redes que detecta mi tarjeta y obtener la información precisa de la red cuyas tramas quiero capturar:

Screenshot from 2016-11-04 15-40-06

De la salida del comando puedo obtener el BSSID y el canal (9 en mi caso). Ahora sintonizo la monitorización a ese canal:

Screenshot from 2016-11-04 15-50-46

Lanzo una serie de pings desde la raspberry para generar tráfico en la red y lanzo Wireshark:

Screenshot from 2016-11-04 16-03-46

Ahora puedo ver las tramas que el punto de acceso devuelve a otros clientes de la red (en este caso la Raspberry) puedo obtener información interesante como las direcciones IP y direcciones MAC de los clientes y todo esto de forma silenciosa, sin hacer notar mi presencia. Esto era fácil porque el punto de acceso está completamente abierto y no emplea cifrado.

Empleando a fondo las capacidades de Wireshark, podríamos reconstruir conversaciones TCP y capturar información relevante intercambiada.

Preparando un lab para pen-testing WiFi

Tras haber conseguido que la Raspberry Pi consiga hablar con una máquina virtual Kali y sea capaz de capturar las tramas 802.11 y enviarlas para su análisis al Kali, voy a empezar a auto-educarme en pruebas de penetración en redes inalámbricas. Para ello, voy a montar un entorno de lab sobre la base de la cacharrería que tengo por casa.

En primer lugar, como punto de acceso WiFi voy a utilizar mi viejo router Belkin F5D7632-4. El router lo he reseteado a los settings por defecto y lo configuraré para que haga de punto de acceso inalámbrico.

DCP_1498

Como máquina atacante voy a emplear un viejo Dell Latitude E6400 con la batería estropeada al que le he añadido una interfaz wireless adicional USB que tenía por casa (una Belkin Wireless G F5D7050) ésta la voy a usar para comunicarme con el equipo y la tarjeta wireless interna (PCI) la usaré para monitorizar la red. Al equipo le voy a montar un Kali Linux que arranque desde un pincho USB en el que grabé la imagen con Rufus.

dell-e6400

Belkin_F5D7050_Wireless_G_USB_Network_470079

Finalmente, la máquina atacada va a ser la Raspberry Pi Model B:

Pi2ModB1GB_-comp

Voy a ir relatando los pasos que voy a seguir para configurar el entorno de pruebas para que cuando tenga que volver a hacerlo, poder emplear este post como referencia.

1. Configuración del Router

Empecemos con el router. Para arrancar limpiamente, he reseteado el router al estado inicial de fábrica , me conecto con un cable ethernet y arranco la interfaz de administración (en el caso del Belkin hay que conectarse a la IP 192.168.2.1).

Lo primero que hago es establecer una contraseña de administrador y, a continuación, configuro los parámetros de la LAN incluyendo la configuración de DHCP. Para el lab, voy a emplear la clase C privada 192.168.200.0/24.

Imagen4b

Al aplicar los cambios necesito volver a conectarme (he cambiado la red y la dirección del router). Hago login con mi nueva contraseña y paso a configurar la WiFi. Establezco el SSID (HACKME_001) y el canal (9) de forma que no haya conflictos con otras WiFis de los alrededores:

Imagen2b

Inicialmente quito la seguridad:

Imagen3b

2. Configuración del PC

Voy a configurar ahora el PC. Como ya comenté antes, mediante el programa Rufus, cree una imagen arrancable de Kali (version 2016-2) en un pincho USB. Los pasos que sigo son:

  1. Configurar la BIOS para que el PC arranque desde un puerto USB
  2. Conectar el pincho con la imagen arrancable a un puerto USB.
  3. Conectar, a otro puerto USB, la tarjeta WLAN.

Una vez completado esto, pulso el botón de ON y, el PC arranca y aparece el desktop de Kali.

Imagen5a

A continuación, voy a ver qué interfaces tiene el PC. Debería tener dos interfaces wireless LAN. Para verlo, lanzo el comando ifconfig.

Screenshot from 2016-07-25 19-59-34

Efectivamente, aparecen dos interfaces: wlan0 y wlan1 pero ahora necesito saber cuál es cuál. Empleando los comandos lsusb y lspci averiguo que la interfaz interna es una Intel Corporation WiFi Link y que la conectada en el puerto USB es una Belkin F5D7050 Wireless G Adapter pero sigo sin saber cuál es wlan0 y cual wlan1. Otros comandos (iwconfig, dmesg) siguen sin aclararme las dudas pero, finalmente, yendo al directorio /sys/class/net consigo aclararme, parece que wlan0 es la interfaz PCI y wlan1 la interfaz USB.

Screenshot from 2016-07-25 20-05-04

Screenshot from 2016-07-25 20-05-33

Screenshot from 2016-07-25 20-23-25

Le echo un ojo a lo que dice iwconfig. Voy a usar wlan0 para hacer de monitor y wlan1 para conectarme a la red doméstica y, por lo tanto, a Internet.

Screenshot from 2016-07-25 20-25-36

Ahora toca configurar las interfaces de red. Esto lo hago a través de la interfaz gráfica. La interfaz wlan1 (la que voy a usar para conectarme al mundo) la configuro con una dirección IP estática (me facilita la vida para conectarme al equipo por SSH) y la interfaz wlan0 usará una dirección IP dinámica obtenida del router Belkin:

Imagen6

Pruebo que haya conexión a todos lados:

Imagen7

Instalo el servidor open-ssh para poder acceder en remoto, lo configuro y compruebo que accedo:

Screenshot from 2016-07-25 21-16-34

Imagen5b

Rearranco y … ¡cagada!, arranqué la imagen como Live (amd64) y debería haberla arrancado como Live USB Persistence (amd64), toda la configuración realizada se fue al garete. ¡Suerte que tengo todos los pasos documentados!, no tengo más que repetir lo que acabo de hacer.

Segunda cagada, necesito seguir las instrucciones que dicen como crear una imagen persistente de Kali así que, de nuevo, a repetir todo el proceso.

Finalmente, a la tercera fue la vencida, ya se mantienen los settings entre arranques aunque queda por configurar que pida contraseña al arrancar y cambiar la contraseña de root. Para hacer esto, sigo los pasos que se identifican aquí y me pide usuario y contraseña para entrar.

El último aspecto que dejo para más adelante es el de la fecha y hora. El portátil no la mantiene y es un rollo tener fecha de hace seis meses.

Conseguida la configuración de la máquina atacante.

3. Configuración de la Raspberry Pi

Aquí la configuración a realizar debería ser, simplemente, la relacionada con la tarjeta WiFi. Como esto no parece muy complicado, empiezo intentando encontrar una forma de cambiar de conectarme a distintas redes WiFi sin necesidad de tocar ficheros de configuración ni rearrancar el aparato. En casa tengo dos puntos de acceso (router de banda ancha y repetidor WLAN) y, además, los de los routers que utilizo para pruebas y si salgo fuera, necesito poder configurar las WiFi de forma fácil.

Hay bastantes respuestas en Internet para cambiar de WiFi automáticamente pero no consigo encontrar una que me permita hacerlo de forma manual. Lo que consigo es liarme y perder tres días jugando con los ficheros de configuración. Finalmente he decidido mantener distintos juegos de ficheros de configuración y reemplazarlos y rearrancar cuando sea necesario. Sin embargo, me queda buscar una solución para esto y lo anoto como una tarea a futuro.

He configurado que la Rasp tenga una dirección IP estática dentro del rango de la clase C del lab. En concreto, la 192.168.200.2. A continuación pongo los fragmentos de los ficheros de configuración que he tenido que tocar:

  • Fichero: /etc/network/interfaces

Imagen8

  • Fichero /etc/dhcpcd.conf

Imagen9

  • Fichero /etc/wpa_supplicant/wpa_supplicant.conf

Imagen10

Rearranco la Rasp y vamos a ver qué configuración tiene y si hay conectividad con los restantes elementos de la WiFi:

Imagen11

Imagen12

Imagen13

Vamos a probar que hay conectividad desde el Kali a la Rasp:

Imagen14

¡Conseguido!

Creando un WIDS casero (y IV)

En el post anterior de la serie, detallé cómo configuré la Raspberry Pi para actuar de sonda en la captura de paquetes 802.11 empleando Kismet (en modo drone). El objetivo es analizar esos paquetes para detectar la presencia de puntos de acceso inalámbricos no autorizados.

En este post, último de la serie, voy a describir como configuro el drone de Kismet en la Rasp y el servidor y el cliente en una máquina virtual para comprobar que puedo capturar los paquetes inalámbricos. En futuros posts iré viendo qué capacidades tiene esta solución.

En la arquitectura de Kismet, el drone captura los paquetes a través de la interfaz inalámbrica y el servidor se conecta al drone para procesar los paquetes que van a ser presentados a través de una aplicación cliente.  En mi entorno, servidor y cliente se ejecutarán en una una máquina virtual sobre Kali Linux, conectada a la DMZ de mi laboratorio virtual. Voy a obviar los detalles de la instalación de Kali para centrarme en el WIDS. La dirección IP de la máquina donde se encuentra el server será 10.1.4.9.

Lo primero que voy a hacer es comprobar que existe conectividad entre la rasp y Kali:

Imagen27

Imagen28

Hasta ahora todo bien, voy a configurar ahora el drone en la Rasp. Lo que voy a hacer es poner, bajo control de versiones, los ficheros de configuración de kismet para poder editarlos cómodamente en el PC.

En la Raspberry edito el fichero /usr/local/etc/kismet_drone.conf y configuro la conectividad del drone:

Imagen29

En kali, edito el fichero /etc/kismet/kismet.conf y configuro, como fuente de paquetes el drone:

Imagen30

Arranco el drone en la Rasp en modo daemon y compruebo que esté a la escucha en el puerto 2502:

Imagen31

Imagen32

Ahora toca el turno al cliente y al server en Kali. En una consola introduzco el comando kismet y, despues de un par de cuestiones relacionadas con el arranque del server veo algo así:

Imagen33

Esto está conseguido.

Creando un WIDS casero (III)

Tras el fracaso con el viejo router D-Link he decidido no darme por derrotado e intentarlo con la Raspberry Pi. Ya comente en otra parte que tengo una Raspberry Pi Model B con una instalación fresca de Raspbian que utilizo, fundamentalmente, para jugar con sensores. Bien, ahora voy a emplearla como sensor de tramas de 802.11.

El viejo router lo voy a emplear para que haga de punto de acceso falso y para otras pruebas de penetración que tengo en mente.

La única duda que me surge es si la tarjeta WiFi USB que tengo es de las soportadas por Kismet. Si no lo fuera, ya veríamos que rumbo tomamos a futuro pero lo que tengo claro es que se me ha metido en la cabeza construir el maldito WIDS.

Lo primero que voy a hacer es actualizar el Raspbian:

Imagen14

Después de un buen rato tengo mi dispositivo actualizado.

El siguiente paso es comprobar si la interfaz WiFi que tengo está soportada por Kismet. Fundamentalmente, lo que importa es ver si se puede poner en modo monitor.

El dispositivo WiFi que tengo en mi Rasp es un dispositivo USB como éste:

Imagen16

Le echo un ojo, en primer lugar, a la configuración de las interfaces de red (comando ifconfig):

Imagen15

La interfaz wireless, como no podía ser de otra forma, es la wlan0. Voy a mirar ahora en los dispositivos USB (comando lsusb):

Imagen17

El dispositivo es el número 004 y es del fabricante Ralink Technology y se trata de un adaptador inalámbrico modelo RT5370. Si quisiéramos obtener información más detallada podríamos usar el comando:

lsusb –D /dev/bus/usb/001/004

Miramos los parámetros del dispositivo inalámbrico con iwconfig:

Imagen18

Por último, comprobamos si el adaptador puede ponerse en modo monitor lo que permite capturar los paquetes:

Imagen19

Todo parece OK así que voy a instalar Kismet. La instalación de Kismet voy a hacerla por el camino largo, esto es, tal y como se describe en la documentación de Kismet: me voy a descargar el código fuente, realizar la configuración previa, compilarlo y, por último, instalar el producto.

Para empezar instalo algunas dependencias:

Imagen20

Ahora me voy a descargar, desde la web de Kismet la última versión estable de código fuente que, en el momento de escribir esto, es la 2016-07-R1. Una vez descargada, voy a usar WinSCP para copiarla a la Raspberry.

Imagen21

Extraemos y configuramos:

Imagen22

Imagen23

Todo parece correcto así que puedo lanzar el make y esperar (la compilación se tomará su tiempo).

Imagen24

A continuación lanzo la instalación. Kismet debe estar instalado en /usr/local/bin

Imagen25

Imagen26

Por último, para completar la instalación, voy a añadir el usuario pi al grupo kismet.

sudo usermod -a -G kismet pi

Rearranco la pi y me meto con la configuración.