CTS Frame Attack es un ataque destinado a la denegación de servicio que puede dejar inoperativa una red inalámbrica durante un largo periodo de tiempo. Para entender cómo funciona el ataque y que es un paquete CTS deberemos profundizar en la base del Networking.
Modelo OSI
El modelo OSI (Open Systems Interconnection Model) es un marco conceptual usado para describir las funciones de un sistema de redes. Estas funciones se caracterizan en un conjunto universal de reglas y requisitos para respaldar la interoperabilidad entre diferentes productos y software. Las comunicaciones entre un sistema informático se dividen en siete capas abstractas:
 |
| OSI Model |
En este artículo vamos a ver la capa física y profundizar en la capa de enlace para entender y ejecutar con éxito nuestro CTS Frame Attack.
Capa Física (Physical Layer)
La capa física es la capa más baja del modelo OSI y se preocupa por el medio que se utiliza para la transmisión de la información, ya sea a través de electricidad, óptico o ya sea por radiofrecuencia. Contienen bits de datos no estructurados sin procesar.
En esta capa es donde se define la señalización y la codificación, es decir la transformación de un medio óptico, eléctrico o de radiofrecuencia a bits.
En el caso de la Wifi, el medio de transmisión es por radiofrecuencia.
Capa de Enlace (Data Link)
En la capa de Enlace, los nodos conectados directamente se utilizan para realizar transferencias de datos donde los datos se empaquetan en tramas.
La capa de enlace tiene la habilidad de poder detectar y corregir los errores que puedan haber ocurro en la capa física. Sus principales funciones son el control de enlace y el control de acceso múltiple.
Data Link Control
Data Link Control o control de enlace de datos es el responsable de que las transmisiones por el canal de transmisión sean confiables, utilizará técnicas como framing, error control y flow control. En esta capa aparecerá el término Stop & Wait ARQ.
Stop & Wait ARQ es el protocolo que consiste en no enviar el siguiente hasta recibir la confirmación de recepción del paquete previamente enviado, en caso de no recibir el ACK se volverá a retransmitir el paquete.
Multiple Access Control
En el caso que haya un enlace dedicado entre el remitente y el receptor, como podría ser el caso de un cable ethernet entre dos dispositivos el control de acceso múltiple no sería necesario, sin embargo, si no hay un enlace dedicado, es decir que varias estaciones pueden acceder al canal simultáneamente, como es el caso de cualquier comunicación wireless, donde todos los clientes intentan enviar datos en el mismo medio (aire), se requieren múltiples protocolos de acceso para disminuir las colisiones y evitar el solapamiento.
Los protocoles de acceso múltiple se dividen en:
Protocolos de Acceso Aleatorio
Este tipo de protocolos, todas las estaciones tienen la misma prioridad y cualquier estación puede enviar datos según el estado del medio ya sea inactivo o ocupado. Los protocolos de acceso al medio aleatorio tienen dos características, que no hay un tiempo fijo para enviar datos y que no hay una secuencia fija de estaciones que envían datos, es decir, no hay ni prioridad ni orden de envío.
ALOHA, CSMA, CSMA/CD y CSMA/CA son algunos de este tipo de protocolos.
Protocolos de Acceso Controlado
En protocolos de acceso controlados, los datos se envían mediante una selección que es aprobada por todas las demás estaciones. Aquí aparece el significado de "Token".
Reservation, Polling y Token Passing son algunos de los protocolos de acceso controlados.
Protocolos de Canalización
Finalmente, el último tipo de protocolos, son aquellos que el medio de transmisión se divide en slots o trozos y se reparte equitativamente entre las estaciones disponibles. Se puede dividir el canal en frecuencia, en tiempo o incluso en codificación.
Introducción al CSMA/CA
Carrier Senser Multiple Access with Collision Avoidance (CSMA/CA) es un protocolo de acceso aleatorio que se desarrolló para disminuir las posibilidades de colisiones cuando dos o más estaciones comenzaban a enviar sus tramas a través de la capa de enlace.
CSMA requiere que cada estación verifique el estado del medio (ocupado o libre) antes de enviar una sola trama.
La idea básica detrás de CSMA es que la estación debería poder recibir tramas mientras transmite para detectar una colisión de diferentes estaciones. En redes cableadas, en el caso de producirse una colisión, la energía de la señal recibida sería aproximadamente el doble que la transmitida, por lo que se podría detectar una colisión.
En el caso de redes inalámbricas, simplemente aumenta un 5-10% de la señal, por lo que no es posible detectar la colisión. Por ese mismo motivo CSMA/CA ha sido especialmente diseñado para redes inalámbricas.
El problema del nodo oculto
El problema del nodo oculto aparece cuando se empiezan a diseñar redes inalámbricas. Imaginemos que tenemos dos estaciones situadas dentro de un punto de acceso, estas estaciones o clientes tienen un alcance limitado, por lo que puede provocar que varios nodos dentro de una misma red no tengan visión entre ellos.
 | |
| Problema del nodo oculto |
¿Entonces, como podemos disminuir las colisiones si no podemos detectar quien hay transmitiendo?
Por si solo CSMA/CA no puede, por lo que se utilizará otro protocolo. Aquí aparece la idea de Request to Send y Clear to Send (RTS/CTS). Este protocolo es aplicado antes de que tenga lugar una transmisión.
Una vez comprobado que el medio está libre y no hay nadie transmitiendo, que la propia base detecte claro está, preguntará a la estación base su deseo de transmitir (RTS). El receptor, que sería la estación base o punto de acceso envía la respuesta (CTS) donde transmite a todos los miembros de la estación que el medio va a estar ocupado por la estación solicitada. De esta forma gracias al RTS/CTS el problema de los nodos ocultos desaparece, ya que es la propia estación base la encargada de controlar y avisar a todos los miembros de la red que el medio va a estar ocupado.
 |
| RTS/CTS Message Exchange |
DIFS y SIFS son tiempos de espera entre paquetes que no entraremos en detalle. Para la realización del ataque nos enfocaremos en la creación de las tramas CTS.
CTS Frame Attack
¿Qué pasaría si una estación quisiera comunicarse continuamente con la estación base, es decir un envío continuo de tramas RTS? En el caso que estuviera solo en el canal, tendría acceso continuo. ¿Pero si hay dos o más?, como el acceso es de forma aleatoria se repartiría el canal de forma aleatoria entre las estaciones, por lo que bajaríamos la tasa de transferencia (throughput) pero sin llegar a crear una denegación de servicio.
¿Pero, que pasaría si suplantamos la identidad de la estación base y enviamos continuamente tramas CTS, diciendo que una estación X (obviamente una estación no existente dentro de la base) tiene permiso para transmitir? Pues que ninguna estación dentro de la red podrá transmitir un solo paquete hasta que la estación base les de permiso, es decir mientras estemos realizando el ataque nunca.
De esta forma podríamos conseguir dejar inutilizado o sin funcionamiento una red inalámbrica entera.
 |
| CTS Frame Attack Message Exchange |
Paquete CTS
Vamos a inspeccionar al detalle el paquete CTS con Wireshark. La tipología de paquetes al igual que en cualquier otro protocolo, está diferenciado por un identificador en la cabecera del paquete. Para los paquetes de tipo Clear-to-send (CTS) pertenece al tipo 28 (0x001c), aplicando un filtro de visualización en Wireshark nos permitirá filtrar nuestra captura.
wlan.fc.type_subtype==28
 |
| Paquetes Clear-to-send (CTS) |
El paquete CTS está formado por 14 Bytes.
 |
| Paquete CTS |
Los primeros 2 Bytes corresponden al Frame Control, donde se especificará la versión, tipo de trama y el subtipo. Esta primera cabecera lo contienen todos los paquetes de tipo IEE 802.11.
Los siguientes 2 Bytes corresponden a la duración de la reserva del canal, es decir durante cuánto tiempo el canal está reservado y no se podrá utilizar. Tiene como valor máximo 30.000 microsegundos (hex: 0x7530 - bin: 0111 0101 0011 0000).
Los siguientes 6 Bytes se destinan a la dirección MAC de la estación que recibirá el paquete, es decir la estación que tendrá permiso para transmitir.
Y finalmente los últimos 4 Bytes corresponden al Frame Check Sequence (FCS), se utiliza para comprobar la integridad de la trama, también se le puede conocer como Checksum o CRC.
Vamos a ver un ejemplo de la trama CTS previamente capturada:
 |
| Paquete CTS capturado |
Destacar que la trama es de tipo Control y corresponde a las tramas que se utilizan para controlar el acceso al medio, y es una trama Clear-to-send ya que es del subtipo 12 (0x001c).
También podemos observar la duración de la reserva, en este caso se ha reservado por el tiempo máximo el canal (30000us), y la MAC de la estación receptora es un dispositivo Xiaomi (4c:63:71:b7:74:3c) y por último el Frame Check Sequence.
Realizando el Ataque
Una vez visto en profundidad la composición del paquete, modificaremos uno a nuestro antojo para la realización del ataque. Para ello exportaremos con Wireshark un paquete a modo de ejemplo.
En el menú de Wireshark “File -> Export Specified Packets” seleccionaremos la exportación de los paquetes seleccionados, que en este caso solo habremos seleccionado uno y lo exportaremos en formato PCAP.
 |
| Exportación de nuestro paquete CTS |
Con hexeditor podemos ver, modificar e identificar los siguientes campos. Remarcar que al tratarse de Little Endian los Bytes van girados al revés.
 |
| Nuestro paquete CTS abierto en hexeditor |
Lo modificaremos a nuestro antojo para crear una trama Clear-to-Send con el máximo tiempo permitido de reserva de canal (30000us) y indicando una MAC de un cliente que no esté conectado, una buena forma es seleccionando la BSSID de la estación base. Remarcar que al estar tratando con un sistema Little Endian, los valores en hexadecimales hay que girarlos.
Con airodump-ng observaremos la información necesaria de la red víctima:
 |
| Redes Wi-Fi disponibles con airodump-ng |
Por lo que quedarían los siguientes valores:
- Frame Control: c4 00 (0x00c4 Control Frame - Subtype CTS)
- Duration: 30 75 (0x7530 30000 us)
- RA: 00 22 b0 cc 35 fd (00:22:B0:CC:35:FD)
- FCS: Este parámetro de checksum no lo vamos a modificar ahora, lo veremos más adelante, pero no lo indicará el propio Wireshark.
 |
| Paquete modificado con hexeditor |
Una vez modificado, abrimos el paquete con Wireshark, en el caso que el FCS esté incorrecto el propio Wireshark sugerirá un nuevo FCS que debernos modificar con hexeditor antes de lanzar el ataque para que este paquete sea válido, en este caso no ha sido necesario.
 |
| Paquete modificado abierto con Wireshark |
Finalmente teniendo un paquete válido, simplemente tendremos que inyectar cientos o miles de estos paquetes en la red con la finalidad de inutilizar el canal un cierto tiempo.
 |
| Inyectando nuestro paquete múltiples veces |
En el ataque que acabamos de realizar, se han inyectado 10.000 paquetes los cuales cada uno reserva 30.000 microsegundos, en total se ha reservado el canal 30 segundos. Especificando el parametro “–topspeed” nos permite enviar los paquetes uno tras otro sin esperar a la finalización de la transmisión de éstos.
Autor: Mario Valiente
Dpto. Auditoría
