Inyección de tráfico en chipsets Atheros

Hace mucho tiempo los usuarios de madwifi contábamos con un driver maravilloso que nos permitía hacer casi cualquier cosa con nuestra tarjeta WiFi. El driver pasó al mainstream de Linux y de repente, en una aciaga versión 2.6.18 (o por ahí) el driver dejó de inyectar. Muchos pensábamos que sería cuestión de tiempo que reparasen este bug... versión tras versión no hemos podido volver a inyectar y en los foros sobre el driver nadie parece haberse dado cuenta... y eso es porque el driver internamente nunca dejó de inyectar. Esta receta explica cómo hacer que el driver funcione como antaño, cuando todos éramos felices inyectando.

El problema

Bueno, como decíamos en la introducción, el driver nunca dejó de inyectar, sin embargo, las aplicaciones que hacen uso de esta feature no funcionan o dicen que el chipset no es capaz de inyectar. ¿Cómo es esto posible?. Para responder a esta pregunta quizás primero debamos saber qué características tiene el driver y el tráfico wifi.

Estructura del driver

El driver tiene dos partes bien diferenciadas: capa MAC80211 o interfaz con el sistema operativo y capa ATH_HAL o interfaz con el hardware. Ambas capas tienen colas de envío y recepción. Los frames o paquetes recibidos por ATH_HAL son procesados y pasados a las colas de la capa MAC80211 si es necesario. Los paquetes envíados a la capa MAC80211 son tratados y depositados en las colas de la capa ATH_HAL para ser envíados por el hardware.

La inyección es tratada por la capa MAC80211, sin embargo, ATH_HAL no marca ese tráfico como lo hacía antiguamente. Éste es el motivo por el que ahora parece que no inyectamos tráfico.

Tráfico normal vs. Tráfico inyectado

Bueno, cuando nuestro driver trabaja con tráfico normal, la cola de envío en la capa MAC80211 no realiza un marcaje especial de los frames, lo que implica que todos los paquetes envíados esperarán su correspondiente ACK. La capa MAC puede configurar su cola de envío de forma que marque los frames para que no esperen respuesta. Éste método es el que se debe usar cuando la cola de envío esté en modo inyección. Y ésto es lo que actualmente se ha eliminado del driver: cuando la cola de envío está en modo inyección, los paquetes en ATH_HAL son tratados como tráfico corriente, cuando en realidad deberían marcarse como NO_ACK.

Actualmente lo que sucede es que los paquetes inyectados esperan ACK, pero jamás lo recibirán puesto que son inyectados. Por este motivo son descartados por el propio ATH_HAL. Para que sean procesados y enviados por ATH_HAL sin importar si llegan o no los ACK hay que marcar el tráfico como NO_ACK.

Dónde se marca el tráfico

Bueno, aquí depende del módulo que use nuestro chipset:

  • ath5k: echamos un vistazo a base.c del código fuente:

    static int
    ath5k_txbuf_setup(struct ath5k_softc *sc, struct ath5k_buf *bf, struct ath5k_txq *txq)
    {
        ...
        flags = AR5K_TXDESC_INTREQ | AR5K_TXDESC_CLRDMASK;
        ...
        if (info->flags & IEEE80211_TX_CTL_NO_ACK)
            flags |= AR5K_TXDESC_NOACK;
        ...
    }

    La función ath5k_txbuf_setup() configura la cola de envío (como su propio nombre indica) y, efectivamente, vemos que si la cola se configura como IEEE80211_TX_CTL_NO_ACK, añade AR5K_TXDESC_NOACK a los flags de envío. Sin embargo, no hace ningún cambio si la cola está en modo INJECTED.

  • ath9k: veamos el fichero xmit.c (nueva versión del ath5k con un código bastante más limpio):

    static int
    setup_tx_flags(struct ath_softc *sc, struct sk_buff *skb, struct ath_txq *txq)
    {
        struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
        int flags = 0;
     
        flags |= ATH9K_TXDESC_CLRDMASK; /* needed for crypto errors */
        flags |= ATH9K_TXDESC_INTREQ;
     
        if (tx_info->flags & IEEE80211_TX_CTL_NO_ACK)
            flags |= ATH9K_TXDESC_NOACK;
     
        return flags;
    }

    Efectivamente, la función aquí es setup_tx_flags(), que retorna los flags que usará la capa ATH_HAL en su cola de envío. Al igual que antes, no hace nada especial si la cola de la capa MAC80211 se configuró como INJECTED.

Aplicar el parche (sin recompilar el Linux entero)

Ahora explicaremos como parchear el módulo en cuatro fáciles pasos, es un poco artesanal pero también más genérico (no voy a hacer parches para cada posible versión del driver :P).

Descarga del código fuente y preparación

Como ya dijeramos, los drivers madwifi pertenecen al mainstream de linux por lo que obtener los fuentes de forma separa puede no ser tan fácil como parece. En nuestro caso tenemos suerte y podemos descargar el paquete compat-wireless de Linux Wireless. Nos bajamos aquel cuya versión sea la más cercana a la de nuestro núcleo, en mi caso la 2.6.32:

$ wget http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.32/compat-wireless-2.6.32.3.tar.bz2
$ unp compat-wireless-2.6.32.3.tar.bz2
$ cd compat-wireless-2.6.32.3
$ sudo aptitude install module-assistant
$ sudo m-a prepare

Con esto habremos instalado los programas y paquetes necesarios para compilar módulos para nuestro núcleo.

Parcheado

ATENCIÓN: estas modificaciones parecen ser motivos de cuelgues en núcleos con versiones 2.6.27 y similares.

Antes disponíamos de parches oficiales de madwifi pero ahora no hay (o no los encuentro) así que a manita... según el módulo que use nuestro chipset (con lsmod podemos ver cuál es):

  • ath5k Modificamos la siguiente línea del fichero drivers/net/wireless/ath/ath5k/base.c:
    if (info->flags & IEEE80211_TX_CTL_NO_ACK)
         flags |= AR5K_TXDESC_NOACK;

    por:
    if (info->flags & IEEE80211_TX_CTL_NO_ACK ||
      (info->flags & IEEE80211_TX_CTL_INJECTED &&
      !(ieee80211_has_morefrags(((struct ieee80211_hdr *)skb->data)->frame_control))))
         flags |= AR5K_TXDESC_NOACK;
  • ath9k Modificamos la siguiente línea del fichero drivers/net/wireless/ath/ath9k/xmit.c:
    if (tx_info->flags & IEEE80211_TX_CTL_NO_ACK)
         flags |= ATH9K_TXDESC_NOACK;

    por:
    if (tx_info->flags & IEEE80211_TX_CTL_NO_ACK ||
     (tx_info->flags & IEEE80211_TX_CTL_INJECTED &&
     !(ieee80211_has_morefrags(((struct ieee80211_hdr *)skb->data)->frame_control))))
         flags |= ATH9K_TXDESC_NOACK;

Como véis, lo único que hacemos es añadir una condición más al if para marcar el tráfico como NO_ACK, y es que la cola esté configurada como INJECTED.

Compilación

Si todo lo anterio lo hicimos correctamente, la compilación es lo más sencillo:

  • ath5k:
    $ ./scripts/driver-select ath5k
    $ make
  • ath9k:
    $ ./scripts/driver-select ath9k
    $ make

Instalación

Bueno, el Makefile tiene el target install con lo que:
$ sudo make install
debería funcionar a la perfección, sin embargo, yo he hecho la instalación manual que consiste básicamente (esto es para ath9k, para el módulo ath5k se hará igual... solo cambia un fichero...):

  1. Descargar los modulos ath9k, ath, mac80211 y cfg80211 de memoria:
    # rmmod cfg80211 mac80211 ath ath9k
  2. Renombrar los ficheros:
    # mv /lib/modules/$(uname -r)/kernel/net/mac80211/mac80211.ko /lib/modules/$(uname -r)/kernel/net/mac80211/mac80211.ko.disabled
    # mv /lib/modules/$(uname -r)/kernel/net/wireless/cfg80211.ko /lib/modules/$(uname -r)/kernel/net/wireless/cfg80211.ko.disabled
    # mv /lib/modules/$(uname -r)/kernel/drivers/net/wireless/ath/ath.ko /lib/modules/$(uname -r)/kernel/drivers/net/wireless/ath/ath.ko.disabled
    # mv /lib/modules/$(uname -r)/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko /lib/modules/$(uname -r)/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko.disabled

    Con esto tendremos una copia de seguridad de los módulos originales.
  3. Copiar ficheros creados:
    # cp net/wireless/cfg80211.ko /lib/modules/$(uname -r)/kernel/net/wireless/
    # cp net/mac80211/mac80211.ko /lib/modules/$(uname -r)/kernel/net/mac80211/
    # cp drivers/net/wireless/ath/ath.ko /lib/modules/$(uname -r)/kernel/drivers/net/wireless/ath/
    # cp drivers/net/wireless/ath/ath9k.ko /lib/modules/$(uname -r)/kernel/drivers/net/wireless/ath/ath9k/

    Con esto tenemos nuestros módulos en el árbol del núcleo.
  4. Actualizar dependencias:
    # depmod -ae
  5. Volvemos a cargar nuestro módulo..,
    # modprobe ath9k

¡Y listo! :D

Referencias

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.

No funciona

No se porqué, pero no me funciona, he estado probándolo, y no me funciona, si teneis alguna idea de porque no podria funcionar, o algo para que os de mas datos...

Me sigue sin inyectar

Tengo el kernel 2.6.32 y me he instalado el driver ath5k (modificado), pero sigo sin poder inyectar. Recivo ACKs, pero no inyecta paquetes.

Estoy haciendo la prueba atacando un router mio (co seguridad WEP habilitada), sin conexion a internet, y sin ningún oredenador conectado.

Os adjunto la lista de pasos seguidos:

1º- Instalar Kernel 2.6.32 (reiniciar): OK
2º- Descargar compat-wireless-2.6.3-2.8, modificar base.c, compilar e instalar: OK
3º- Seleccionar red a atacar e inyectar:
my laptop: 00:15:af:xx:xx:xx

Step 1 - Start wireless interface in monitor mode according to AP channel
sudo airmon-ng start wlan0 11
mi red a craquear:
00:16:E3:XX:XX:XX -88 0 7 0 0 11 54e WEP WEP OSCVER_TEST

Step 2 - Use airodump to capture packet
sudo airodump-ng -c 11 --bssid 00:16:E3:XX:XX:XX -w wifi mon0

Step 3 - Do aireplay to deauthenticate/associate with AP
sudo aireplay-ng -1 6000 -o 1 -q 10 -e OSCVER_TEST -a 00:16:E3:XX:XX:XX -h 00:15:AF:XX:XX:XX mon0

Step 4 - Start aireplay in ARP request replay mode
sudo aireplay-ng -3 -b 00:16:E3:XX:XX:XX -h 00:15:AF:XX:XX:XX mon0

Y no consiguo inyectar....

00:38:25 Waiting for beacon frame (BSSID: 00:16:E3:XX:XX:XX) on channel 11
Saving ARP requests in replay_arp-0402-003825.cap
You should also start airodump-ng to capture replies.
Read 68650 packets (got 0 ARP requests and 1985 ACKs), sent 0 packets...(0 pps)

Lo he intentado todo y nada ¿Alguien puede ayudarme? ¿Que puedo estar haciendo mal?
Gracias.

Imagen de int-0

...veamos...

...cuando creas la interfaz en modo monitor, no hace falta que especifiques el canal y después prueba con wesside-ng a ver qué te dice ese programa, ok?

------------------------------------------------------------
$ python -c "print 'VG9udG8gZWwgcXVlIGxvIGxlYSA6KQ==\n'.decode('base64')"
------------------------------------------------------------

Problema compilando

Hola a Tod@s!!

Estoy siguiendo este tuto pero me quedo en el paso de la compilación, ya he modificado el drivers/net/wireless/ath/ath9k/xmit.c
pero a la hora de compilar, en el directorio scripts, no hay ningún "driver-select", por tanto no puedo decir que driver quiero seleccionar para luego hacer el make.

estoy con la versión: compat-wireless-2.6.31-rc7, pues uso ubuntu karmic remix (para netbooks, el mio es un aspire one d250 con una ath9k) y este ubuntu tiene el kernel 2.6.31-20

tengo que usar otro compat-wireless que si lleve ese script??

Gracias y un saludo

Imagen de int-0

Vaya...

...pues quizás la receta se haya quedado obsoleta... tendré que echar un vistazo a las nuevas versiones... ¡gracias!

------------------------------------------------------------
$ python -c "print 'VG9udG8gZWwgcXVlIGxvIGxlYSA6KQ==\n'.decode('base64')"
------------------------------------------------------------

Imagen de Lk2

Perfecto

Todo hecho al pie de la letra y módulos cargadas y funcionando... eso si, me queda probar la inyección Sticking out tongue

¡Por cierto! No estaría de más, aunque parezca obvio, que se necesitan tener los "headers" del kernel para poder compilar el módulo.

Saludos

Imagen de int-0

Corregido

Gracias por el aporte! Sticking out tongue

------------------------------------------------------------
$ python -c "print 'VG9udG8gZWwgcXVlIGxvIGxlYSA6KQ==\n'.decode('base64')"
------------------------------------------------------------

Genial...

muy útil. Gracias

Imagen de david.villa

habrá que probarlo...

habrá que probarlo... Smiling

No soy portavoz de ningún colectivo, grupo o facción. Mi opinión es personal e intransferible.

problema ubuntu 10.04

un saludo que tal, desde que actualice a ubuntu 10.04 no puedo auditar redes.

antes del tuto no podia aociarme ahora ya puedo pero como muestra al final no recibo ni envio paquetes y por ende no consigo las ivs para completar mi auditoria alguien me puede ayudar??? salu2

20:26:43 Sending Authentication Request (Open System) [ACK]
20:26:43 Authentication successful
20:26:43 Sending Association Request [ACK]
20:26:43 Association successful Smiling (AID: 1)

root@the-orgy-:/home/theorgy# aireplay-ng -3 -b 00:31:40:D2:8D:32 -h 00:11:22:33:44:55 mon0
20:26:49 Waiting for beacon frame (BSSID: 00:15:D0:42:8D:32) on channel 11
Saving ARP requests in replay_arp-0729-202649.cap
You should also start airodump-ng to capture replies.
^Cad 12097 packets (got 0 ARP requests and 95 ACKs), sent 0 packets...(0 pps)