Sunday, December 16, 2007

Troubeshooting wireless

Con la llegada de WPA a mi red las cosas se han complicado bastante. Lo ultimo ha sido reunir las 4 foneras. Lo cierto es que una de ellas esta fuera de combate: contraseña cambiada y olvidada, ssh habilitado, ejecución de actualizaciones de fon quitada y redboot capado. O accedo al redboot por puerto serie, o la fonera pasa a mejor vida. He intentado cualquier combinacion de arranques + pulsaciones de reset, pero no ha funcionado nada, asi q toca soldar... un día de estos me pondré a ello. Mientras tanto, sigo con las otras 3 foneras, una de ellas conectada habitualmente en un sitio remoto, pero temporalmente en casa para su configuración. Y con las nuevas configuraciones, vienen los experimentos y se acaban rompiendo las cosas. Si bien hay un dicho "si funciona, no lo toques" es habitual entre alguna gente (entre los que me incluyo) cambiarlo por "si funciona, abrelo y arreglalo".
El problema empezo con la fonera que sirve de AP WPA para las videoconsolas. Parecía que era un problema de estabilidad: con el hostapd arrancado, no duraba mas de 1 dia sin colgarse. Pues bien, tras reflashearla por si acaso, decido cambiar la instalacion, ya que no habia ninguna otra version de hostapd mas nueva que la 0.57.1 en el repositorio de openwrt. En la pagina ipkg.k1k2.de parece que tienen el hostapd 0.58.1, aparte del kernel 2.6.23 para chipset Atheros. Tras consultar a "uname -a" veo q el que tenía era 2.6.19, asi que decido cambiar. Resultado: sin WPA. Ya no se cuelga, pero principalmente es porque no funciona. Todo se configura perfecto pero a la hora conectarse, el AP rechaza a los clientes. Tras una primera parte de la asociación correcta:
State: SCANNING -> ASSOCIATING
wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
WEXT: Operstate: linkmode=-1, operstate=5
wpa_driver_wext_associate

Setting authentication timeout: 10 sec 0 usec

EAPOL: External notification - EAP success=0

EAPOL: External notification - EAP fail=0

EAPOL: External notification - portControl=Auto

RTM_NEWLINK: operstate=0 ifi_flags=0x3 ([UP])

Wireless event: cmd=0x8b06 len=8

RTM_NEWLINK: operstate=0 ifi_flags=0x3 ([UP])

Wireless event: cmd=0x8b04 len=12

RTM_NEWLINK: operstate=0 ifi_flags=0x3 ([UP])
En lugar de aparecer el handshake:
Wireless event: cmd=0x8b1a len=15
RX EAPOL from 00:18:84:1f:d1:4a

Setting authentication timeout: 10 sec 0 usec

IEEE 802.1X RX: version=2 type=3 length=95

EAPOL-Key type=254

key_info 0x89 (ver=1 keyidx=0 rsvd=0 Pairwise Ack)

key_length=32 key_data_length=0

replay_counter - hexdump(len=8): 00 00 00 00 00 00 00 01

key_nonce - hexdump(len=32): XX XX XX 6a dd cf cf 87 a3 0f 2b e6 de cd 8e XX ad 18 ff b8 aa 21 6a ca 76 7e f2 d2 03 XX XX XX

key_iv - hexdump(len=16): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

key_rsc - hexdump(len=8): 00 00 00 00 00 00 00 00

key_id (reserved) - hexdump(len=8): 00 00 00 00 00 00 00 00

key_mic - hexdump(len=16): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

State: ASSOCIATING -> 4WAY_HANDSHAKE

WPA: RX message 1 of 4-Way Handshake from...

Aparece esto otro:
Wireless event: cmd=0x8b1a len=16
RTM_NEWLINK: operstate=0 ifi_flags=0x3 ([UP])

Wireless event: cmd=0x8b15 len=20

Wireless event: new AP: 00:00:00:00:00:00

Added BSSID 06:18:84:XX:XX:XX into blacklist

CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys

wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0

wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0

wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0

wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0

wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0

State: ASSOCIATING -> DISCONNECTED

wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)

WEXT: Operstate: linkmode=-1, operstate=5

EAPOL: External notification - portEnabled=0

EAPOL: External notification - portValid=0

EAPOL: External notification - EAP success=0

Authentication with 00:00:00:00:00:00 timed out.

Added BSSID 00:00:00:00:00:00 into blacklist

State: DISCONNECTED -> DISCONNECTED

wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)

WEXT: Operstate: linkmode=-1, operstate=5

No keys have been configured - skip key clearing

EAPOL: External notification - portEnabled=0

EAPOL: External notification - portValid=0

Setting scan request: 0 sec 0 usec

State: DISCONNECTED -> SCANNING
Ojala tuviera tiempo para ver qué es lo que falla, pero en estas fechas prenavideñas llenas de entregas de practicas, no hay tiempo para mucho. Lo mas fácil, sencillo y rápido será probar otro firmaware donde el hostapd funcione, pero no mate a la fonera.

Y ya que estaba tocando cosas, me puse a tocar más. El portatil-server-AP tenía el cifrado WEP puesto a restricted (shared key). Aunque en un escenario ideal, con WEP siendo seguro, esto sería una mala idea; hoy en día, nadie en su sano juicio atacaría por ahí.
En pocas palabras: en modo abierto el AP deja asociarse a cuaquiera. En modo restringido, el AP manda unos datos que el ciente tiene que encriptar con la calve WEP y devolverlos al AP para comprobar si tiene la clave. Dado que todo viaja por el aire, un atacante podría capturar el mensaje en claro y cifrado y por fuerza bruta sacar la calve WEP, sin más datos. Esto es un trabajo de meses diría yo, y hoy en día teniendo ataques de minutos, es una pérdida de tiempo siquiera pensarlo.
Lo bueno del modo restricted es que es un obstáculo muy grande para romper una wifi con WEP. Por supuesto, no digo que no se pueda, de hecho con el propio aircrack-ng es posible sin más que leer la página del manual. El quid de la cuestión radica en que los miles de tutoriales online siempre explican el proceso de sacar claves WEP de redes abiertas, esto es, que cualquiera se puede asociar y "autenticar". Aunque en el manual de aircrack explique como atacar redes en restricted, no hay "tutoriales para HOYGANs" que lo expliquen, dado lo escaso de su aplicación. Basta que en el paso 14.c.II del mega-hiper-tutorial-para-dummies algo salga mal, para que un atacante de estos se vaya a una esquina a llorar y deje tu red en paz.
Lo que pasa detrás del escenario es que en una red abierta, la seguridad reside en que los clientes con la clave correcta mandarán tramas cifradas y el AP las entenderá y procesará. Los clientes que no tengan la clave, se podrán asociar y enviar tramas al AP, pero este las intentará descifrar con su clave WEP y al no poder, las dará por corruptas y las tirará. Esto se explota haciendo un ataque "fakeauth" para asociarse al AP y un "replay" para reenviar tramas ARP que circulen por la red y ya han sido encriptadas por el autor original. El atancante no las entenderá, pero el AP sí, y mandará las contestaciones generando así el tráfico necesario. Con una red restricted, el paso previo de "fakeauth" fallará al no poder asociarse el atacante al AP, y todas las tramas, incluídas las repeticiones de las ARP capturadas, serán rechazadas. Si no habeis entendido esto ultimo, la version corta es: el modo restricted te protege de noobs con manuales "bajaos de la güeb", pero no de gente que sabe lo que hace (sigue siendo WEP al fin y al cabo).
Bien, dado que anteriormente mi red estaba protegida sólo contra atacantes-dummies, usaba el modo restricted. Pero con la nueva configuración con VPN, no era necesario el modo restricted y decidi quitarlo, ya que los clientes por defecto intentas asociarse con modo open y para poner el restricted hay que rebuscar entre las opciones o hacerlo via consola. Pues cambie la linea wireless_key en el archivo interfaces de debian de "clave_WEP" a "clave_WEP" key open (no permita definirlo en dos lineas wireless_key, se queja de valores duplicados). Resultado: la ipw3945 del portatil no se conecta. Ya me da problemas con el dhcp y ahora esto. Puedo usar cualquier wifi abierta, WEP open/restricted o WPA a mi alcance excepto esa en concreto. Y al reves, cualquier otra tarjeta que he probado se asociaba perfectamente con el AP en modo open, excepto la intel.
Tras mucho tiempo investigando, me di cuenta de que el AP se anunciaba como "sin cifrado" y es lo que salia al escanear. Ninguna otra tarjeta/dispositivocon wifi se veía afectado por esto, pero la intel3945 sí. Los demás simplemetne se asociaban como si no tuviera clave y luego al poner la calve y se podía usar el AP.
El problema radicaba, curiosamente en la configuracion del prism54 del portatil-AP. Al poner la clave de la wifi y luego el modo open, la prism54 anunciaba el parámetro encryption como off, aunque para que los clientes se comunicaran con el AP sí que hacia falta la clave. Bastaba volver a poner la clave o cambiar el modo a restricted, para que se anunciara bien el cifrado. La solución fue tan simple como cambiar el orden y dejar la linea tal que: wireless_key open key "clave_WEP". Y todo volvio a funcionar perfecto como con el modo restricted. Y que rompan la clave si quieren, para lo que les va a servir... :D

En fin, basta de rollos por hoy. En caso de duda consulte con su farmaceutico o deje un cometario. Espero que hayais aprendido alguna cosa nueva, como hago yo al pelearme con las wifis y... ¡hasta la proxima!
*****

update 5:00am:
Ya he descubierto el fallo que no permite autenticarse por WPA en la fonera. Tal como sospechaba, es culpa del kernel puesto que bajar el hostapd de 0.58 a 0.57 no ha resuelto el problema. Esto es la salida de una asociación WPA (en concreto, de la psp), pero por parte del server:

root@hostnameXXX:/lib/modules/2.6.23.1# hostapd -dd /var/run/hostapd-ath1.conf
Configuration file: /var/run/hostapd-ath1.conf
madwifi_set_privacy: enabled=0
BSS count 1, BSSID mask ff:ff:ff:ff:ff:ff (0 bits)
SIOCGIWRANGE: WE(compiled)=22 WE(source)=18 enc_capa=0xf
ath1: IEEE 802.11 Fetching hardware channel/rate support not supported.
Flushing old station entries
Deauthenticate all stations
madwifi_del_key: addr=00:00:00:00:00:00 key_idx=0
madwifi_del_key: addr=00:00:00:00:00:00 key_idx=1
madwifi_del_key: addr=00:00:00:00:00:00 key_idx=2
madwifi_del_key: addr=00:00:00:00:00:00 key_idx=3
Using interface ath1 with hwaddr 06:18:84:XX:XX:XX and ssid 'XXXXXXX'
SSID - hexdump_ascii(len=8):
XX XX XX XX XX XX XX XX XXXXXX
PSK (ASCII passphrase) - hexdump_ascii(len=21):
XXXXXXXXX... ...XXX XXX... ...XXX
PSK (from passphrase) - hexdump(len=32): XX XX XX ... ... XX XX XX
madwifi_set_ieee8021x: enabled=1
madwifi_configure_wpa: group key cipher=1
madwifi_configure_wpa: pairwise key ciphers=0x2
madwifi_configure_wpa: key management algorithms=0x2
madwifi_configure_wpa: rsn capabilities=0x0
madwifi_configure_wpa: enable WPA=0x1
madwifi_set_privacy: enabled=0
WPA: group state machine entering state GTK_INIT (VLAN-ID 0)
GMK - hexdump(len=32): [REMOVED]
GTK - hexdump(len=32): [REMOVED]
WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0)
madwifi_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1
madwifi_set_privacy: enabled=1
madwifi_set_iface_flags: dev_up=1
ath1: Setup of interface done.
Wireless event: cmd=0x8b1a len=17
Wireless event: cmd=0x8c03 len=20
ath1: STA 00:1c:26:XX:XX:XX IEEE 802.11: associated
New STA
ath1: STA 00:1c:26:XX:XX:XX WPA: event 1 notification
madwifi_del_key: addr=00:1c:26:XX:XX:XX key_idx=0
ath1: STA 00:1c:26:
XX:XX:XX WPA: start authentication
WPA: 00:1c:26:
XX:XX:XX WPA_PTK entering state INITIALIZE
madwifi_del_key: addr=00:1c:26:
XX:XX:XX key_idx=0
madwifi_set_sta_authorized: addr=00:1c:26:
XX:XX:XX authorized=0
ath1: STA 00:1c:26:
XX:XX:XX IEEE 802.1X: unauthorizing port
WPA: 00:1c:26:
XX:XX:XX WPA_PTK_GROUP entering state IDLE
WPA:
00:1c:26:XX:XX:XX WPA_PTK entering state AUTHENTICATION
WPA:
00:1c:26:XX:XX:XX WPA_PTK entering state AUTHENTICATION2
WPA:
00:1c:26:XX:XX:XX WPA_PTK entering state INITPSK
WPA:
00:1c:26:XX:XX:XX WPA_PTK entering state PTKSTART
ath1: STA
00:1c:26:XX:XX:XX WPA: sending 1/4 msg of 4-Way Handshake
WPA: Send EAPOL(secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0)
TX EAPOL - hexdump(len=113): XX XX XX ... ... XX XX XX
IEEE 802.1X: 32 bytes from
00:1c:26:XX:XX:XX
IEEE 802.1X: version=1 type=1 length=0
ignoring 28 extra octets after IEEE 802.1X packet
IEEE 802.1X: 123 bytes from
00:1c:26:XX:XX:XX
IEEE 802.1X: version=1 type=3 length=119
ath1: STA
00:1c:26:XX:XX:XX WPA: received EAPOL-Key frame (2/4 Pairwise)
WPA:
00:1c:26:XX:XX:XX WPA_PTK entering state PTKCALCNEGOTIATING
PMK - hexdump(len=32): [REMOVED]
PTK - hexdump(len=64): [REMOVED]
WPA:
00:1c:26:XX:XX:XX WPA_PTK entering state PTKCALCNEGOTIATING2
WPA:
00:1c:26:XX:XX:XX WPA_PTK entering state PTKINITNEGOTIATING
madwifi_get_seqnum: addr=00:00:00:00:00:00 idx=1
ath1: STA
00:1c:26:XX:XX:XX WPA: sending 3/4 msg of 4-Way Handshake
WPA: Send EAPOL(secure=0 mic=1 ack=1 install=1 pairwise=8 kde_len=24 keyidx=0 encr=0)
TX EAPOL - hexdump(len=137): XX XX XX ... ... XX XX XX
IEEE 802.1X: 99 bytes from
00:1c:26:XX:XX:XX
IEEE 802.1X: version=1 type=3 length=95
ath1: STA
00:1c:26:XX:XX:XX WPA: received EAPOL-Key frame (4/4 Pairwise)
WPA:
00:1c:26:XX:XX:XX WPA_PTK entering state PTKINITDONE
madwifi_set_key: alg=TKIP
00:1c:26:XX:XX:XX key_idx=0
ioctl[IEEE80211_IOCTL_SETKEY]: Invalid argument
madwifi_set_key: Failed to set key (addr 00:1c:26:0e:5f:f6 key_idx 0 alg 'TKIP' key_len 32 txkey 1)

hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA
00:1c:26:XX:XX:XX reason 2
madwifi_sta_deauth:
00:1c:26:XX:XX:XX reason_code=2
ath1: STA
00:1c:26:XX:XX:XX IEEE 802.11: deauthenticated due to local deauth request
Wireless event: cmd=0x8c02 len=99
Custom wireless event: 'STA-TRAFFIC-STAT
00:1c:26:XX:XX:XX
rx_packets=3
rx_bytes=296
tx_packets=2
tx_bytes=238
'
Wireless event: cmd=0x8c04 len=20
ath1: STA
00:1c:26:XX:XX:XX IEEE 802.11: disassociated

Pues nada, ¡a flashear de nuevo!

No comments: