++++++ IMPORTANTE ++++++
++++++ IMPORTANTE ++++++
++++++ IMPORTANTE ++++++
Esta funcionalidad estará disponible en una versión futura. NO está disponible actualmente.
++++++ IMPORTANTE ++++++
++++++ IMPORTANTE ++++++
++++++ IMPORTANTE ++++++
Esta documentación y manuales se encuentran todavía en desarrollo. Es necesario trabajar más. Por favor, publica cualquier comentario o sugerencia en este post de el Foro en inglés.
Airbase-ng es una utilidad “multi-propósito” dirigida a atacar a los clientes conectados a un Punto de Acceso (AP). Como es tan versatil y flexible, no es fácil realizar un resumen o sumario. De todos modos las funciones más importantes que se pueden realizar son:
La idea principal de esta utilidad es que los clientes se podrían asociar a un AP falso (fake AP), y no pueden preveer que están accediendo al Punto de Acceso real.
Una interface (atX) se crea cuando airbase-ng se ejecuta. Esta se puede usar para recibir paquetes desencriptados o enviar paquetes encriptados.
Como los clientes reales probablemente enviaran “probe requests”, estos paquetes son importantes para hacer picar a un cliente hacía nuestro Punto de Acceso “softAP”. En este caso, el AP responderá a cualquier paquete “probe request” con el correspondiente “probe response”, el cual le dice al cliente que se encuentra autenticado al BSSID de airbase-ng. Hay que decir que esto podría distorsionar el funcionamiento correcto de otros APs que se encuentren en el mismo canal.
PELIGRO: airbase-ng puede muy fácilmente corromper y distorsionar el funcionamiento de los Puntos de Acceso de los alrededores. Por lo tanto, usa filtros para minimizar esta posibilidad. Actua siempre con responsabilidad y no impidas el funcionamiento de las redes que se encuentran alrededor de la tuya.
uso: airbase-ng <opciones> <replay interface>
Opciones:
Opciones de filtro:
Ayuda:
Si no se especifica explicitamente un BSSID usando la opción “-a <BSSID>”, entonces se usa la dirección MAC actual de la interface especificada.
Si especificas una interface con esta opción los paquetes son también capturados y procesados desde esta interface además de la “replay interface”.
Si la encriptación usada es WEP, entonces el parámetro “-w <WEP key>” sirve para fijar la clave. Esto es suficiente para permitir a airbase-ng añadir todo el resto de parámetros por si mismo.
Si el “softAP” opera con encriptación WEP, el cliente puede escoger usar el sitema de autenticación abierta (open system authentication) o compartida (shared key authentication). Ambos métodos de autenticación están soportados por airbase-ng. Pero para conseguir un “keystream”, el usuario puede probar a forzar al cliente a usar “shared key authentication”. “-s” fuerza una autenticación compartida (shared key auth.) y “-S <len>” fija la longitud del preámbulo.
Esta es la dirección MAC origen para el ataque “man-in-the-middle” (hombre en el medio). También hay que especificar la opción “-M”.
Si no se incluye esta opción, por defecto se usa “-f allow”. Lo que significa que los filtros MAC (-d y -D) definen que clientes se aceptan.
Usando la opción “-f disallow” puede causar que airbase ignore los clientes especificados por los filtros.
Esto fija la “WEP flag” o bandera del paquete baliza o “beacon”. Recuerda que los clientes solo conectaran a los APs que tengan las mismas opciones. Por ejemplo WEP a WEP, red abierta a red abierta.
La opción “auto” permite a airbase-ng fijar automáticamente la opción (bandera o flag) a partir del resto de opciones especificadas. Por ejemplo, si fijas una clave WEP con el parámetro -w, entonces la bandera (beacon flag) será fijada a WEP.
Otro uso de “auto” es permitir conectarse a los clientes que pueden ajustar automáticamente su tipo de conexión. Aunque, esto funciona en raras ocasiones.
En la práctica, es mejor fijar el valor adecuado según el tipo de red en la que estemos trabajando.
Esta opción todavía no está disponible. Es un ataque “hombre en el medio” (man-in-the-middle), es decir nos colocamos entre los clientes especificados y los BSSIDs.
Esto provoca que airbase-ng actue como un cliente ad-hoc en lugar de un punto de acceso normal.
En el modo ad-hoc airbase-ng también envía balizas o beacons, pero no necesita ninguna autenticación/asociación. Puede activarse usando “-A”. El “soft AP” ajustará automáticamente todas las banderas y opciones necesarias para simular una tarjeta en modo ad-hoc y generará una dirección MAC, que se usará como AD-HOC MAC en lugar de el BSSID. Esta puede ser fijada con la opción “-a <BSSID>”. La dirección MAC se usará como mac origen, que puede ser cambiada con “-h <MAC origen>”.
La opción “-Y” activa el modo de “proceso externo”. Esto crea una segunda interface “atX”, que se usa para reenviar/modificar/capturar o inyectar paquetes también. Esta interface hay que levantarla con ifconfig y una utilidad externa es necesaria para crear y utilizar esta interface.
La estructura del paquete es bastante simple: el encabezado ethernet (14 bytes) es ignorado y a continuación el frame ieee80211 es procesado por airbase-ng (para los paquetes entrantes) o antes de que los paquetes sean enviados (paquetes salientes). Este modo intercepta todos los paquetes de datos y circulan a través de una aplicación externa, que decide que es lo que hay que hacer con ellos. La dirección MAC e IP de la segunda interface tap no tienen importancia, como una tarjeta ethernet real los frames de esta interface se lanzan a todas partes.
Hay 3 argumentos para “-Y”: “in”, “out” y “both”, que especifican la dirección de los frames que circulan a través de la aplicación externa. Obviamente “in” redirecciona solo los frames entrantes (a través del NIC wireless), mientras los frames salientes no se tocan. “out” hace todo lo contrario, solo circulan paquetes salientes y “both” envía en todas las direcciones a través de la segunda interface tap.
Hay una pequeño y simple utilidad que sirve de ejemplo para reenviar todos los frames a través de la segunda interface. La utilidad se denomina “replay.py” y se encuentra en la carpeta “./test”. Está escrita en python, pero el lenguaje de programación no importa. Usa pcapy para leer los frames y scapy posibilita alterar/mostrar y reinyectar los frames. La utilidad simplemente reenvía todos los frames y muestra un corto resumen de los paquetes recividos. La variable “packet” contiene el paquete ieee80211 completo, que puede fácilmente ser diseccionado y modificado usando scapy.
Esto se puede comparar con los filtros de ettercap, pero es mucho más poderoso, ya que como un lenguaje real de programación puede ser usado para construir paquetes complejos. La desventaja de usar python es, que tendremos un pequeño retardo de alrededor de 100ms y la utilización de la cpu es mucho mayor en una red a alta velocidad, pero es perfecto para una demostración con solo unas pocas lineas de código.
Cuando lo especifiquemos, esto fuerza una autenticación para todos los clientes con clave compartida (shared key).
El “soft AP” enviará una reinyección “authentication method unsupported” a cualquier sistema abierto (open system) si se especifica la opción “-s”.
“-S <len>” fija la longitud del preámbulo, y puede ser cualquier número comprendido entre 16 a 1480. Por defecto se usa 128 bytes. Es el número de bytes usados en el preámbulo previo a la conexión. Como una etiqueta o “tag” puede contener un máximo de 255 bytes, cualquier valor superior a 255 crea varias etiquetas o “tags” hasta que se escriban todos los bytes especificados. Algunos clientes ignoran valores diferentes a los de 128 bytes, por lo que esta opción puede no funcionar siempre.
Airbase-ng tambien contiene el nuevo ataque “caffe-latte”, que está implementado también en aireplay-ng como ataque “-6”. Puede ser usado con “-L” o “–caffe-latte”. Este ataque funciona especificamente contra los clientes, mientras están esperando por una petición arp dirigida a todos (broadcast arp request). Mira esta documentación en inglés para ver una explicación de lo que es gratuitous arp. El cliente contestará a la petición arp y enviará unos pocos bits con su MAC y dirección IP, con el valor correcto del ICV (crc32). La razón por la que este ataque funciona habitualmente en la práctica es, porqué al menos en windows se envían “gratuitous arps” despues de que una conexión se realiza y se concede una dirección ip estática, y si el dhcp falla windows asigna una IP del rango 169.254.X.X.
“-x <pps>” fija el número de paquetes por segundo a enviar con el ataque caffe-latte. Actualmente, este ataque no se para, y envía continuamente peticiones arp. Airodump-ng es necesario para capturar las respuestas.
Este ataque escucha y espera por una petición ARP o paquete IP desde el cliente. Cuando se recibe uno, se extrae una pequeña cantidad de PRGA y se usa para crear un paquete de petición arp (ARP request) dirigido al cliente. Esta petición ARP se construye actualmente a partir de múltiplies fragmentos cuando son recividos, y el cliente responderá.
Este ataque funciona especialmente muy bien contra redes ad-hoc. También se puede usar contra clientes de “softAP” y clientes de AP normales.
La baliza denominada en inglés “beacon frame” contiene el nombre del ESSID en caso de que se haya especificado uno. Si se fijan varios, el ESSID estará oculto en la “beacon frame” con longitud de 1. Si no se fija el ESSID, la “beacon frame” contendrá “default” como ESSID, pero se aceptarán todos los ESSIDs en las peticiones de asociación. Si el ESSID debería estar oculto en la baliza todo el tiempo (para un ESSID no especificado), se puede usar la opción “-X”.
Las tramas de control (en inglés “Control frames”) (ack/rts/cts) nunca son enviadas por el código, pero a veces las lee (el firmware debería manejar esto). Los paqutes y tramas de datos se pueden enviar siempre, y no se necesita autenticarse antes de la asociación o incluso antes de enviar tramas de datos. Los paquetes de datos pueden enviarse en todas las direcciones. Los clientes reales autenticados y asociados al softAP deberían enviar las respuestas correctas, pero airbase-ng no se preocupa de comprobar las propiedades de los clientes y simplemente permite a todos los clientes conectarse (teniendo en cuenta los filtros de ESSIDs y direcciones MACs especificados). Por lo tanto una autenticacion no puede fallar (excepto si se fuerza SKA), y tampoco puede fallar la asociación. El AP nunca enviará deautenticaciones o desasociaciones en modo de operación normal.
Ha sido desarrolllado de tal forma que se maximiza la compatibilidad y las oportunidades de conseguir que un cliente se conecte.
Hay capacidades de filtrado variadas.
Para limitar los ESSIDs soportados, puedes especificar “-e <ESSID>” para añadir un ESSID a la lista de ESSIDs permitidos, o usar “-E <ESSIDarchivo>” para leer una lista de ESSIDs permitidos (el archivo tiene que contener un ESSID por linea).
Lo mismo se puede hacer para las direcciones MACs de los clientes (usar un filtrado de MAC). “-d <MAC>” añade una dirección MAC a la lista, “-D <MACarchivo>” añade todas las MACs del archivo a la lista (recuerda que tiene que haber una MAC por linea).
La lista de MACs puede ser usada para permitir solo acceder a los clientes en esa lista y bloquear a todos los otros (opción por defecto), o bloquear a los especificados en la lista y permitir el acceso al resto. Esto se controla con la opción “-f allow” o “-f disallow”. “allow” crea una lista “blanca” (activado por defecto en caso de no usar “-f”), y “disallow” crea una lista “negra” (el segundo caso relatado con anterioridad).
Cada vez que se ejecuta airbase, se crea una hinterface tap (atX). Para usarla, ejecuta “ifconfig atX up” donde X es el número actual de la interface.
Esta interface tiene usos variados:
A continuación puedes ver unos ejemplos de uso. Solo necesitas una tarjeta wireless aunque en algunos ejemplos se usan dos tarjetas.
Usar “airbase-ng <iface>” es suficiente para un AP sin ningún tipo de encriptación. Aceptará conexiones desde cualquier MAC para cada ESSID, ya que la autentication y la asociación es directa al BSSID.
Realmente no podrás hacer demasiado en esta situación. Aunque, podrás ver una lista de clientes que se encuentran conectados además del método de encriptación y los SSIDs.
Este ataque obtiene la clave wep de un cliente. Depende de recibir al menos un paquete de petición ARP o un paquete IP desde el cliente despues de que se asocie con el falso AP.
Escribe:
airbase-ng -c 9 -e teddy -N -W 1 rausb0
Donde:
El sistema responderá:
18:57:54 Created tap interface at0 18:57:55 Client 00:0F:B5:AB:CB:9D associated (WEP) to ESSID: "teddy"
En otra ventana o consola ejecutar:
airodump-ng -c 9 -d 00:06:62:F8:1E:2C -w cfrag wlan0
Donde:
A continuación se puede ver que ocurre cuando airbase-ng ha recibido un paquete de un cliente y se ha iniciado satisfactoriamente el ataque:
CH 9 ][ Elapsed: 8 mins ][ 2008-03-20 19:06
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
00:06:62:F8:1E:2C 100 29 970 14398 33 9 54 WEP WEP teddy
BSSID STATION PWR Rate Lost Packets Probes
00:06:62:F8:1E:2C 00:0F:B5:AB:CB:9D 89 2-48 0 134362
Ahora puedes ejecutar aircrack-ng en otra ventana para obtener la clave wep.
Este ataque obtiene la clave wep de un cliente. Depende de recivir al menos una petición ARP o un paquete IP desde el cliente despues de que está asociado con el falso AP.
Escribe:
airbase-ng -c 9 -e teddy -N -W 1 -A rausb0
Donde:
El resto será lo mismo que en el modo AP.
Este ataque obtiene la clave WEP de un cliente. Depende de recibir al menos una petición “gratutitous ARP” de un cliente despues de asociarse con el falso AP.
Escribe:
airbase-ng -c 9 -e teddy -L -W 1 rausb0
Donde:
El resto es lo mismo que en el ataque Hirte.
Este es un ejemplo de una captura de PRGA de un cliente asociado con clave compartida.
Escribe:
airbase-ng -c 9 -e teddy -s -W 1 wlan0
Donde:
El sistema responderá:
15:08:31 Created tap interface at0 15:13:38 Got 140 bytes keystream: 00:0F:B5:88:AC:82 15:13:38 SKA from 00:0F:B5:88:AC:82 15:13:38 Client 00:0F:B5:88:AC:82 associated to ESSID: "teddy"
Las últimas tres lineas solo aparecen cuando el cliente se asocia con el falso AP.
En otra ventana o consola ejecuta:
airodump-ng -c 9 wlan0
Donde:
A continuación puedes ver el aspecto de una captura SKA satisfactoria. Date cuenta de este dato “140 bytes keystream: 00:C0:CA:19:F9:65” en la esquina superior-derecha:
CH 9 ][ Elapsed: 9 mins ][ 2008-03-12 15:13 ][ 140 bytes keystream: 00:C0:CA:19:F9:65
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
00:C0:CA:19:F9:65 87 92 5310 0 0 9 54 WEP WEP SKA teddy
BSSID STATION PWR Rate Lost Packets Probes
00:C0:CA:19:F9:65 00:0F:B5:88:AC:82 83 0- 1 0 4096 teddy
Este es un ejemplo de como capturar el handshake WPA.
Escribe:
airbase-ng -c 9 -e teddy -z 2 rausb0
Donde:
La opción -z tendrá que ser modificada dependiendo del tipo de encriptación que creas que está usando el cliente. TKIP es lo típico y habitual para WPA.
El sistema responderá:
10:17:24 Created tap interface at0 10:22:13 Client 00:0F:B5:AB:CB:9D associated (WPA1;TKIP) to ESSID: "teddy"
La última linea solo aparece cuando el cliente se asocia.
En otra shell ejecuta:
airodump-ng -c 9 -d 00:C0:C6:94:F4:87 -w cfrag wlan0
Cuando el cliente se conecta, verás el “WPA handshake: 00:C0:C6:94:F4:87” en la esquina superior-derecha de la pantalla:
CH 9 ][ Elapsed: 5 mins ][ 2008-03-21 10:26 ][ WPA handshake: 00:C0:C6:94:F4:87
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID 00:C0:C6:94:F4:87 100 70 1602 14 0 9 54 WPA TKIP PSK teddy BSSID STATION PWR Rate Lost Packets Probes 00:C0:C6:94:F4:87 00:0F:B5:AB:CB:9D 86 2- 1 0 75
Ejecutando “aircrack-ng cfrag-01.cap” comprueba que lo capturado es un handshake WPA válido:
Opening cfrag-01.cap Read 114392 packets. # BSSID ESSID Encryption 1 00:C0:C6:94:F4:87 teddy WPA (1 handshake)
Capturar un handshake en WPA2 es básicamente idéntico al ejemplo anterior a través de WPA. La única diferencia es especificar -Z 4 (CCMP cipher) en lugar de -z 2.
Escribe:
airbase-ng -c 9 -e teddy -Z 4 rausb0
SOLO USUARIOS EXPERTOS: Esta funcionalidad requiere conocimientos extremadamente avanzados sobre linux y redes. No publiques preguntas en el foro acerca de esta sección. Si no puedes hacer funcionar esto por ti mismo entonces no deberías ni intentar usarlo!
Una nueva interface “atX” será creada, la cual actua como la “wired side” al AP. Para usar el AP, esta nueva interface debe levantarse con ifconfig y necesita una IP. La MAC asignada es automáticamente fijada al BSSID [por defecto la dirección MAC de la interface wireless]. Una vez que es asignada una IP y el cliente usa una IP estática de la misma subred, tendremos funcionando una conexión Ethernet entre el AP y el cliente. Algún daemon puede ser asignado a esa interface, por ejemplo un servidor dhcp o servidor dns. Además con “ip_forwarding” y una regla apropiada “iptable” para enmasacarar, el softAP actúa como un router wireless. Cualquier utilidad, que funcione en redes ethernet puede ser usada con esta interface.
Algunos links en inglés:
Además de lo que se dice en las anteriores descripciones, airbase-ng envía 100 paquetes 100 veces para intentar incrementar la efectividad de este ataque.
Este es un ataque a un cliente en el que se puede usar un paquete IP o un paquete ARP. A continuación se describe el ataque de forma detallada.
La idea principal es generar una petición ARP para enviarsela al cliente y que este responda.
Este ataque necesita un paquete ARP o un paquete IP desde el cliente. A partir de esto, tendremos que generar una petición ARP o “ARP request”. La petición ARP debe dirigirse a la IP (IP del cliente), colocandola en la posición del byte 33 y la dirección MAC deben ser todos ceros. Aunque en la práctica como dirección MAC podríamos poner cualquier valor.
La dirección IP de origen se encuentra en el paquete recibido del cliente en una posición conocida - posición 23 para paquetes ARP o 21 para IP -. Paquete ARP se presupone si el tamaño del mismo es de 68 o 86 bytes. Si no es así se presupone que se trata de un paquete IP.
Para poder enviar una petición ARP válida de vuelta al cliente, necesitamos mover la IP de origen a la posición 33. Por supuesto que no podemos simplemente mover los bytes, ya que sería un paquete inválido. Por lo tanto, usamos el concepto de “paquete fragmentado” para conseguir esto. La petición ARP se envía al cliente en dos fragmentos. El primer fragmento se construye seleccionando la longitud que nos queda al mover la dirección IP de origen a la posición 33. El segundo fragmento es el paquete original recivido desde el cliente.
En el caso de que se trate de un paquete IP, la técnica usada es similar. Aunque es más limitada la cantidad de PRGA disponible, por lo que habrá que construir tres fragmentos a partir del paquete original.
En todos los casos, se usa “bit flipping” para asegurarnos que el CRC es correcto. Además, “bit flipping” se usa para cerciorarnos que la dirección MAC de origen de un ARP en el paquete fragmentado no es de multiredifusión.
Algunos drivers como el rtl8187 no capturan paquetes por si mismos. La implicación de esto es que el softAP no se mostrará en airodump-ng. Puedes solventar este problema usando dos tarjetas wireless, una para inyectar y la otra para capturar.
El driver madwifi-ng actualmente no soporta los ataques Caffe-Latte o Hirte. Este driver no sincroniza de forma correcta las velocidades con el cliente y por lo tanto el cliente nunca recive los paquetes.
Recives el mensaje “Broken SKA: <dirección MAC> (expected: ??, got ?? bytes)” o similar. Usando la opción “-S” con valores diferentes a 128, algunos clientes fallan. Este mensaje indica que el número de bytes actualmente recibidos es diferente al número de bytes solicitados. Prueba a no usar esta opción o utiliza diferentes valores para el parámetro “-S” y mira si se elimina el error.
Como esta versión no se ha publicado oficialmente, la documentación de aireplay-ng no refleja las nuevas funciones relacionadas con airbase-ng. Por eso esta sección contiene alguna información sobre esto.
“-D” es una nueva opción que se ha añadido a aireplay-ng. Por defecto, aireplay-ng escucha las beacons o balizas de un AP especificado y dá fallo si no recibe ninguna beacon. La opción “-D” desactva esta funcionalidad.
Ejemplo: aireplay-ng -6 -h 00:0E:D2:8D:7D:0A -D rausb0
Ejemplo: aireplay-ng -7 -h 00:0E:D2:8D:7D:0A -D rausb0