Cada día son más los dispositivos que conectamos a Internet mediante una conexión WiFi, prácticamente las conexiones de red cableadas tipo Ehernet han quedado relegadas a ordenadores de sobremesa que no tengan una antena WiFi o servidores que exijan un rendimiento superior o aislamiento físico. El resto de equipos informáticos que tenemos en nuestra casa o empresa, probablemente se conectan a la red mediante WiFi. Un ejemplo de ello son los smartphone, dispositivos IoT, televisiones inteligentes, electrodomésticos, robots de cocina, aspiradores, ordenadores portátiles que ya no incluyen conector RJ45, cámaras IP o alarmas de casa…

En este artículo de GLIDER voy a centrarme en realizar un “review” sobre las capacidades de auditoría WiFi de un dispositivo Flipper Zero con su correspondiente placa de ampliación WiFI dev. Si todavía no sabéis lo que es capaz de hacer un Flipper Zero, os dejo Este Artículo titulado: “Desmitificando un Flipper Zero” dónde explico de forma pormenorizada todas las capacidades o discapacidades de un Flipper Zero.

Antes de comenzar vamos a explicar los distintos protocoles con los que pueden operar las redes WiFi:

Existen varios protocolos de redes WiFi, entre los más comunes se encuentran: 802.11a que opera en la banda de frecuencia de 5 GHz y tiene una velocidad máxima de 54 Mbps. El 802.11b opera en la banda de frecuencia de 2.4 GHz y tiene una velocidad máxima de 11 Mbps y el 802.11g opera en la banda de frecuencia de 2.4 GHz con una velocidad máxima de 54 Mbps. Estos tres estándares de la IEEE (Institute of Electrical and Electronics Engineers) están prácticamente en desuso, ya que se trata de tecnología desfasada.

El 802.11n opera en las bandas de frecuencia de 2.4 GHz y 5 GHz y tiene una velocidad máxima de 600 Mbps. Normalmente utilizado a nivel doméstico para lanzar redes WiFi a 2.4 GHz.

El estándar 802.11ac opera en la banda de frecuencia de 5 GHz y tiene una velocidad máxima de varios gigabits por segundo. Hoy en día es el estándar más utilizado en redes de 5 GHz

Finalmente, el 802.11ax (también conocido como WiFi 6) es la última versión del protocolo WiFi y opera en las bandas de frecuencia de 2.4 GHz y 5 GHz. Ofrece una velocidad máxima teórica de 10 Gbps mejorando la eficiencia del espectro y la gestión de dispositivos. Hoy en día es uno de los estándares que todavía se está desplegando, por lo tanto, su uso está bastante limitado.

Es importante tener en cuenta que para que los dispositivos se comuniquen correctamente, deben ser compatibles y usar el mismo protocolo WiFi, es decir, si nuestro Access Point (emisor) opera como máximo con el estándar 802.11g, no se podrá utilizar en redes de 5GHz. ¿Para qué explico todo esto?, muy sencillo, el ESP 32 que utiliza la placa WiFi Dev del Flipper Zero solamente puede operar en la frecuencia de 2.4GHz, lo que significa que cualquier red que funcione en la frecuencia de los 5 GHz no podrá ser auditada con este dispositivo, es decir, las redes exclusivas de 5GHZ no son compatibles con este módulo WiFi.

¿Y qué podemos hacer en los 2.4GHz con el Flipper Zero y su modulo WiFi?, vamos a verlo:

En primer lugar, es necesario explicar que el Flipper Zero solamente hace las funciones de pantalla y teclado del módulo WiFi, toda la carga de procesamiento se ejecutará en el ESP32 integrado en el módulo WiFi que se conecta al Flipper Zero mediante sus GPIOS.

Una vez ya le hemos cargado el correspondiente firmware al módulo WiFI, podemos manejarlo si queremos desde un ordenador. Para esto conectaremos un cable USB-C desde el Flipper Zero a nuestro ordenador, y activaremos el modo que simula una interfaz COM (puerto serie) para controlar el módulo mediante una consola de telnet remota en nuestro PC.

Desde este modo podremos ir ejecutando todos los ataques disponibles, pero en realidad esta configuración no tiene mucho sentido, ya que el verdadero potencial del Flipper Zero es su autonomía e independencia de cualquier otro dispositivo. Si que es cierto que para hacer un escaneo de redes WiFi desde el propio Flipper Zero es bastante complicado, ya que si existen muchas redes WiFi en la zona será prácticamente imposible verlas correctamente en la pequeña pantalla del Flipper Zero. Una opción intermedia sería simular el puerto serie a través de una conexión bluetooth y conectarnos al telnet desde nuestro teléfono móvil, pudiendo utilizar de este modo una pantalla más grande y manteniendo el sistema autónomo e independiente. Por ejemplo, podremos ver todas las redes WiFi disponibles en nuestra zona junto con sus parámetros técnicos en una pantalla grande, como se puede mostrar a continuación:

La imagen anterior muestra la potencia de señal de cada Access Point WiFi, su BSSID (Dirección MAC) y SSID (Nombre de Wifi), así como los beacon: unas balizas que utilizan las redes WiFi para poder coordinarse con sus clientes (dispositivos que se conectarán al WiFi). Esta información es muy similar a la que podemos obtener utilizando la herramienta Airodump-NG en Linux, con la diferencia de que aquí ya está todo automatizado y listo para funcionar. Eso sí, el Flipper no muestra tanta información como Airodump-NG, por ejemplo, los “probe request” (emisiones del SSID que hace el cliente) o los clientes no asociados (no conectados a un WiFi), no los muestra. En caso de Airodump-NG muestra más información técnica sobre las redes WiFi que un Flipper Zero con su modulo WiFi, como se puede observar en la siguiente imagen:

Este “ataque/scan”, nos puede servir para ver todas las redes que tenemos a nuestro alcance y obtener una serie de parámetros técnicos sobre ellas, nada que sea critico o especialmente peligroso para la seguridad de los clientes o los Access Point.

Operando desde el propio Flipper Zero, también se puede obtener la misma información, lo que ocurre es que es bastante más difícil ver los datos en su minúscula pantalla. En este caso, solamente tenemos que entrar en el menú de “WiFi Marauder” como se muestra en la siguiente imagen:

Ya dentro del menú WiFi Marauder, la primera de las opciones será la de “Scan AP”, que nos mostrará la misma información que en el punto anterior, pero a través de la pantalla del Flipper Zero. En este caso, la red WiFi de una impresora multifunción marca HP modelo ENVY.

Al analizar las redes WiFi cercanas (Access Point), el WiFI Marauder del Flipper Zero, asignará automáticamente un identificador único a cada una de las redes, esto nos servirá posteriormente para poder seleccionar el objetivo que queremos atacar. Normalmente esto se hace seleccionando la dirección MAC del emisor WiFi, en este caso para evitar tener que escribir una dirección MAC utilizando solamente los cinco botones del teclado del Flipper Zero, nos facilita la tarea permitiendo escribir solo el número (identificador único) asignado a la red WiFi en cuestión. Por ejemplo, en la siguiente imagen se muestra la red 5 y la 6 para auditar, las anteriores (1, 2, 3 y 4) y las siguientes (7, 8, 9…), las podremos visualizar subiendo y bajando el cursor del Flipper Zero.

Si lo que queremos es seleccionar un cliente y no un AP como target (objetivo), también lo podremos hacer, ya que, con esta opción, nos listará todos los AP disponibles y los clientes que están conectados a cada uno de ellos. Esto sirve para afinar la puntería y no realizar un ataque contra todos los clientes conectados a esa red, pudiendo seleccionar uno solo, dejando el resto de clientes operar normalmente. En la siguiente imagen se muestra los AP en la primera línea (AP: 5 y 6) y los clientes conectados a los AP con una tabulación respecto a los AP (clientes: 0; 1 y 22)

Una vez que ya sabemos cuál será nuestro objetivo, un AP o varios clientes, desde la opción “select” tendremos que indicar si lo que vamos a seleccionar es un AP o un cliente.

Para seleccionar el objetivo solamente indicaremos el número o identificador que he comentado anteriormente, en realidad lo que estamos haciendo es escribir el comando: “select –a IDENTIFICADOR”, pero como el select –a ya está escrito, solamente nos preocuparemos de poner correctamente el Identificador.

Si, por ejemplo, comparamos un Flipper Zero, con la ancestral WiFI Pinneapple (la Piña WiFi es otra herramienta de hardware hacking orientada a la auditoria de redes WiFi, que también funciona únicamente en redes de 2,4GHz), la información que muestra y los módulos que permite ejecutar son bastante más potentes, por contra, la Piña WiFi no tiene batería, ni pantalla, ni teclado, por lo que siempre se necesitará un ordenador o teléfono móvil para poder usarla. En la siguiente imagen se muestra el interfaz de uso de la WiFi Pinneapple en modo scan.

Y ahora es cuando viene lo de hablar de los ataques que es capaz de realizar el Flipper Zero con el módulo WiFi Dev. ¿Será un “bluf” como el caso del Artículo anterior de GLIDER dónde comentaba los ataques de radio que podía hacer un Flipper Zero?, vamos a verlo para que podáis valorar por vosotros mismos:

El primero de los ataques que vamos a realizar se llama “Deauth Atack”, básicamente un ataque que intentará desautenticar un cliente de su AP o todos los clientes de un AP, es decir, desconectar un dispositivo de la red WiFI a la que está conectada. ¡OJO! No hay que olvidar que realizar este tipo de pruebas o ataques sin consentimiento de los usuarios puede ser constitutivo de un delito de daños informáticos, dentro del epígrafe de denegaciones de servicio. Ya que en realidad lo que hace esta herramienta, es saturar de tal modo el AP, que al final no tiene la capacidad de poder mantener la conexión estable con su cliente, terminando por desconectarlo de la red.

Para poder ejecutar este ataque, tuvimos que haber seleccionado previamente el AP o los clientes a desautenticar mediante el comando “select –a IDENTIFICADOR”. En la siguiente imagen se muestra el ataque ejecutándose, mientras se muestre por pantalla, se estará enviando de forma continua los paquetes de desautenticación al cliente a mayor velocidad que el AP trate de conectar al cliente, de este modo se podrá lograr desconectar a los clientes seleccionados por un tiempo determinado.

Como este ataque se basa en un estándar del paquete legítimo de desautenticación del IEE 802.11, es complicado protegerse de él, una de la formas más optimas, es disponer de una red WiFi con roaming de varios AP, así cuando nos desautentiquen de uno, el cliente se irá automáticamente al otro AP más cercano. No es una solución infalible, ni barata, pero permitirá mitigar en gran medida este tipo de ataques.

Otra forma de protegernos de un ataque tipo deauth, es activando los PMF en el Access Point (Protected Management Frames). Los PMF se utilizan para proteger los mensajes de gestión que se envían en las redes Wi-Fi, como los mensajes de asociación, autenticación y desautenticación, de la interceptación y manipulación por parte de posibles atacantes. Esto se logra mediante la adición de un cifrado adicional a los mensajes de gestión que se envían entre dispositivos inalámbricos y puntos de acceso. Los PMF descritos en el estándar 802.11w están disponibles en las redes Wi-Fi más recientes, como el estandar 802.11ac. Sin embargo, no todos los dispositivos inalámbricos y puntos de acceso son compatibles con los PMF, por lo que es importante verificar la compatibilidad antes de implementarlos en una red Wi-Fi. En redes WiFi con seguridad WPA-2 son opcionales, sin embargo si utilizamos la tecnología WPA-3 ya vienen implementados por defecto y no se pueden desactivar. Gracias a @Sergio_deLuz Director de @redeszone por la pista de las tramas PMF.

Si os estáis preguntando a quien se le ha ocurrido meter dentro un estándar como el IEE 802.11 un paquete tan “peligroso” como el “deauth”, pensad que es peligroso si se utiliza para hacer el mal, pero en condiciones normales de uso, es un paquete necesario cuando un AP tenga que impedir que se conecte un cliente por ejemplo por haber introducido incorrectamente la contraseña de la WiFi o si ya hay demasiados clientes conectados y han superado el límite de capacidad del AP.

En la imagen anterior, se muestra un paquete de desautenticación estándar, otra forma de mitigar este ataque sería aceptando solo paquetes deauth de una lista blanca de direcciones MAC, pero al existir herramientas que permiten suplantar una dirección MAC o la problemática de gestionar estas listas blancas al querer aumentar el número de estaciones, al final es complicado bloquear paquetes malintencionados de este tipo.

De los tres tipos de tramas que se pueden generar con el estándar IEE 802.11, la de desautenticación se encuentra dentro del grupo de Gestión (Control y Datos son las otras dos). Esta trama está dividida en ocho campos, que son los siguientes:

• Campo 1: Es dónde se indica que tipo de trama de las existentes se está transmitiendo. Por ejemplo, la trama de desautenticación es del tipo gestión (00) y subtipo 1100 o 0x000C (desautenticación). Si fuese de autenticación el valor del subtipo sería de 1011.

• Campo 2: Un valor en microsegundos para declarar el tiempo de vida que tendrá la trama.

• Campo 3: La dirección MAC de destino.

• Campo 4: La dirección MAC de origen.

• Campo 5: El BSSID, normalmente es el mismo que el campo 3, salvo en entornos de redes complejas.

• Campo 6: Indica el número de orden en la secuencia de tramas, se usa para ordenarlas en caso de que lleguen al destinatario sin el orden correcto.

• Campo 7: El código que indica la razón para la desautenticación, es un dato meramente informativo, podríamos escribir de motivo: “PARA HACKEARTE”, y el cliente se seguiría desconectado igual, cosas de los protocolos… Antes de que algún ingeniero de teleco o de sistemas se asuste, en realidad no podríamos hacer esto, en informática se suele utilizar códigos para definir situaciones, ya que pensad que transmitir el mensaje: “PARA HACKEARTE”, ocupa 14 bytes, mientras que asignar un código hexadecimal de dos cifras a un mensaje predefinido solamente ocupa unos pocos bits, y los datagramas en redes no están precisamente para derrochar “bits”. En realidad, este campo solo acepta un número limitado de códigos predefinidos, por ejemplo, el código 4 significa: desautenticado por inactividad o el 23 significa: autenticación fallida. En Esta Tabla tenéis el listado de CISCO de códigos con el motivo para desautenticar un cliente de un AP (si no recuerdo mal, en total existen un poco menos de 60 códigos distintos).

• Campo 8: (FCS o Frame Check Sequence) Una suma de verificación para realizar el control de la integridad de la trama y descartarla si este valor no concuerda con el esperado. Es decir, si algún dato se ha corrompido, esta suma de verificación no corresponderá con el cálculo que hace el destinatario y el paquete se rechaza.

Por ejemplo, si quisiéramos lanzar un ataque de desautenticación contra el cliente con dirección MAC: AA:AA:AA:AA:AA:AA haciéndonos pasar el AP con dirección MAC: 55:55:55:55:55:55, la trama que tendríamos que lanzar sería algo parecido a esto: 00-1100-100-AAAAAAAAAAAA-555555555555-AAAAAAAAAAAA-1-23 (los guiones los he insertado para marcar visualmente el límite de cada campo, en la vida real no se transmiten). ¿Y cómo hemos podido averiguar las direcciones MAC del cliente y del AP para poder lanzar el ataque?. Estos datos por definición del propio protocolo son públicos y no se envían cifrados, por lo tanto con cualquier receptor WiFi configurado en modo monitor podemos recibir todas las tramas de gestión que están lanzando al aire los AP y los clientes, extrayendo las direcciones MAC y utilizándolas para ejecutar este tipo de ataques. Así de sencillo.

Un riesgo de este estándar, es que al fin y al cabo las direcciones MAC se asignan públicamente a fabricantes concretos, luego el fabricante dentro del rango asignado las va asociando a los componentes que fabrica. ¿Qué riesgo puede suponer esto?, por ejemplo, permite saber la disposición y capacidades de la alarma de una casa. Un ejemplo es el de una conocida compañía de alarmas española que tiene asignada un encabezado de direcciones MAC fijo y por lo tanto, cualquier dispositivo que comience con esta dirección MAC sabremos que se trata de un sensor de alarma de esta compañía de seguridad y como son datos que se envían por radio al aire, cualquier persona desde la calle los puede ver.

Y así es como funciona un ataque de desautenticación a bajo nivel, ya veis que no es magia, simplemente es utilizar una tecnología existente para un uso en el que en un primer momento no se había pensado (o sí).

Otro ataque que se puede realizar con un Flipper Zero y su placa WiFI Dev, es el “RICK ROLL ATACK”, posiblemente uno de los ataques más peligrosos y complejos que he visto en mi vida ( << imaginad aquí el emoticono del hombre golpeando su frente >> ). Si no sabéis cómo funciona este ataque, os recomiendo que veáis primero el siguiente tutorial de YouTube dónde se explica su funcionamiento a bajo nivel:

Si os habéis quedado como estabais después de escuchar la canción de: Rick Astley – Never Gonna Give You Up, no os preocupéis, es totalmente normal. ¿En qué consiste este ataque entonces?, pues ni más ni menos, que en crear puntos de acceso WiFi falsos con la letra de esta famosa canción de Rick Astley , o mejor dicho, lanzar al aire tramas WiFi publicando la existencia de varias redes WiFi que sus SSID (Nombre de la red) coincide con la letra de la canción. Por ejemplo:

• SSID de la WiFI 1: “We’re no strangers to love”

• SSID de la WiFI 2: “You know the rules and so do I (do I)”

• SSID de la WiFI 3: “A full commitment’s what I’m thinking of”

• SSID de la WiFI 4: “You wouldn’t get this from any other guy”

• SSID de la WiFI 5: “I just wanna tell you how I’m feeling”

• SSID de la WiFI 6: “Gotta make you understand”

Este tipo de ataque no influye en el funcionamiento del resto de redes publicadas en la zona, simplemente muestra 10 o 12 nombres de WiFi a mayores, que como mucho molestarán a la hora de seleccionar en el móvil a la que verdaderamente nos queremos conectar. Como podéis comprobar, más que ataque, se debería llamar broma o vacilada delante de los amigos, poco más que añadir.

El siguiente tipo de ataque que vamos a analizar es el de tipo «probe«. En este tipo de ataques se intenta descubrir redes Wi-Fi que están en modo oculto. Una red Wi-Fi oculta es la que no emite su nombre de red (SSID) públicamente, lo que significa que la red no aparece en la lista de redes disponibles en el dispositivo del cliente y por lo tanto (en principio) para poder conectarnos a ella, es necesario conocer y escribir previamente el nombre de la red (SSID) y después su contraseña.

Para descubrir una red oculta, una técnica que se puede utilizar es enviar paquetes de solicitud de sondas (probes) a la dirección de broadcast de la red (Calculada normalmente con la máscara de subred y la dirección IP, por ejemplo, para una red /24 con IP 192.168.1.5 la dirección de broadcast es la 192.168.1.255). Estos paquetes se envían de forma maliciosa en busca de una respuesta del punto de acceso de la red. Si el punto de acceso responde, se podrá averiguar el SSID de la red.

Los ataques de tipo «probe» son especialmente peligrosos, ya que cuando pregunto en mis conferencias de ciberseguridad sobre quien oculta el SSID de la red para aumentar su seguridad, siempre hay alguien que levanta la mano, explicando que lo hace para evitar que ningún cibercriminal se pueda conectar a esa red de forma maliciosa, ya que, si supuestamente la red “no se ve”, es imposible atacarla al no poder vulnerar lo que no se ve. En realidad, esto no es así del todo, es más, dependiendo de si queremos evitar ataques de script kiddies o de alguien más profesional, ocultar el SSID de la red no es para nada recomendable. Si lo que queremos evitar es que el vecino del cuarto nos robe el WiFi, vecino que los únicos conocimientos de hacking que tiene es un par de videos de YouTube que ha visto, no es mala idea ocultar el SSID, pero hoy en día esta técnica de “seguridad por oscuridad”, ya no resulta tan interesante como hace unos años. Ocultar el SSID de una red WiFi, puede hacer que los clientes que se han conectado a ella con anterioridad, tengan que estar continuamente lanzando tramas para localizarla, lo que permitirá localizar más fácilmente tanto a los clientes como a los AP con esta configuración.

Hasta aquí la descripción de funcionalidades que se pueden llevar a cabo con Flipper Zero y su placa WiFi dev, no hay que olvidar que el WiFi dev no deja de ser un ESP32, por lo que se podrán programar otras herramientas con unas funcionalidades más prometedoras, pero de momento, al menos en las versiones de firmware por defecto o el avanzado llamado “unleashed”, las funcionalidades son bastante limitadas, más allá de presumir delante de los amigos al ser capaces de desconectar una televisión o un teléfono del WiFi al que estaba conectado.

¿Te ha gustado este artículo? Si quieres, puedes ayudarme a escribir el siguiente artículo de GLIDER invitándonme a un rico café.

 

Pulsa Aquí para invitarme a un café con hielo.

  Salu2.