Crazy Google - PPPd - SSL BAD MAC error

UPDATE: follow up

Hi all. Long time no see. Just didn't have much to say lately. But now I do. So hi :)

A lot has actually changed lately, both at personal and professional level, but the relevant part is: I have a new ISP.  I moved and the awesome 50/10Mbit 1&1.de VDSL was no longer available, so now I have a much crappier 16/1Mbit ADSL by O2/Alice (after several months of borrowing the neighbor's WiFi). Also, instead of the fantasboulous FritzBox7390 I got a crappy Alice IAD 4412, or something whatever the thing it's called. It's 2.4Ghz only and 150 Mbit. And on top of that O2/Alice is soooo worried for some reason that I would sell the router on ebay to buy a yacht, that I have to return the damn thing at the end of the 24 month contract.

Of course the first thing I did was to disable everything internet related on the router, enable PPPoE passthrough and set up PPPoE on my linux box to act as a Torrent / Router / Firewall / Apache / Misc server. Since I had the same setup with 1&1 everything went pretty smoothly and all was fine. The End.

No, of course not. Everything did go smoothly, until I tried to use GMail. I got a nice SSL error page with the following message:

Secure Connection Failed
An error occurred during a connection to accounts.google.com.
SSL peer reports incorrect Message Authentication Code.

(Error code: ssl_error_bad_mac_alert)

I tried to google it, but since I use google with https by default, it happened for www.google.com too! After a F5 it would work again.

I thought it might be an iptables problem but the usual clamp-tcpmss-to-pmtu did no good. Trying to debug I wrote the following crude script:

C=0 E=0; while [ $E = 0 ]; do curl 'https://www.google.com' --no-sessionid -v -1; E=$?; C=$((C+1)); echo $C; done

I ran it in multiple configurations of destination servers, hosts and connections. Since I still have access to the borrowed neighbor's wifi I also ran it there. It's worth mentioning that the neighbor uses the same ISP and a traceroute shows that the second router down the road is already the same, so basically what's different is the ppp method (me - pppd through crappy router, he - crappy router directly).

Result: it fails ONLY when:

• I use my connection (pppd though router), doesn't matter if it's a NATed machine or the server itself. Ran over 11k times from other connections, no problem.
• I connect to google servers (accounts.google.com, www.google.com). Ran over 2k connections to other https servers from same connection: no problem.

So who is to blame?

• Google: no, it works fine from my work maciine and the neighbor's WiFi.
• pppd: no, it worked before with 1&1.
• Alice ADSL: no, the neighbor has Alice as well.
• Crappy router: no, it works fine when connecting to facebook, yahoo, deutsche bank, etc.
• Combination of all of the above: well, it works sometimes.

Solution? Sadly, I have none. I have a packet capture that shows exactly when the problem happens most often:

• Client Hello
• Server Hello
• Server Certificate, Server Key Exchange, Server Hello Done
• Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message (encrypted MAC of handshake).
• Server issues SSL Alert: Bad Record MAC.

Googling did not help either. Some suggest changing the clock would help, but same client fails only on a specific connection. Anyway, I synced all clocks of all involved machines: no joy. Clearing the cache: curl doesn't even have cache. Anyway, it didn't help. The closest online discussion of the problem is this thread. On other threads, some people hint that the problem is dependent on the particular connection, but nobody offers a decent solution.

I know it's a long shot, but: does anybody out there have an idea on how to fix this? Even a hint towards a method to further debug it would be greately appreciated. Problems for a good debug method:

• MAC is over random numbers: any comparison with different server/connection handshakes is useless.
• Since it is connection dependent client side errors are rather impossible.
• The sent MAC is encrypted, it's hard to analyze with wireshark.

The last ideas I have is to capture the ppp packets and compare if contents change over wlan0 contents (unlikely, since only google complains (only google checks?? unlikely...)), or try a different router/set the router in gateway mode instead of pppoe modem...

As said before, any idea will be appreciated!

Wifi 5GHz en Linux

Hace poco comenté sobre un problema con la wifi en linux, en el "nuevo" kernel 2.6.29. Pues parece que el problema es la configuración de país de la tarjeta. Cada país tiene una lista de frecuencias en las que se permite emitir sin licencia, y que se usan para (entre otros) las redes inalámbricas. Pues bien, entre las versiones 28 y 29 del kernel, cambió el modo de administrar este ajuste y as cosas dejaron de funcionar, hasta el punto de que ni me detectaba la red 5GHz del punto de acceso.

La solución: decirle que estamos en España (o el país que sea... ¡yo no me hago responsable!):

# iw reg set ES

Y voilá! Problema arreglado, ya funciona con normalidad. Para que sea permanente, lo mejor es añadirlo a "/etc/rc.local", para que se ejectue cada vez que se enciende el ordenador.

UPDATE: por desgracia, esto sólo resuelve el problema de no ver los puntos de acceso. El problema de "semiconexion" sigue presente. A ver cuendo sale el 2.6.30.

Regresiones en el kernel de linux: iwlagn

No sé si mi caso es especial, porque no he encontrado nada parecido por Internet, pero con el kernel 2.6.29 he dejado de poder conectarme a la wifi, en concreto a la de 5GHz. Hay algún bug relacionado con WPA2, pero en mi caso da igual el cifrado, depende únicamente de la frecuencia. Tanto con el 2.6.28 como con Windows, el tema funciona, así que definitivamente no es culpa del AP. Lo más gracioso de todo es que sólo falla parcialmente: es capaz de solicitar y recibir una IP por DHCP e incluso responder peticiones ARP, pero no es capaz de ver las respuestas a las peticiones ARP propias. Los dejo aqui por si alguien más tiene este problema, que no se rompa la cabeza buscando qué es lo que hace mal. Más tarde abriré un bug en el bugzila del kernel, a ver que me dicen.

Actualización (2009 May 20): La solución no es difícil.

Wireless en Linux y Windows

Algo que ya he comentado en alguna ocasión es mi profundo odio hacia NetworkManager y su forma GNOME de hacer las cosas. Ahora uso wicd en todos mis equipos y la verdad es que comparado con NM funciona estupendo, pero en general sigue teniendo muchos fallos. Al menos usa ficheros de configuración en texto plano en "/etc/wicd/*.conf" y permite el uso de scripting, con lo que a las malas es posible ignorar la lógica de wicd y usarlo como una gui para scripts propios.

Lo que mejor funciona suele ser la línea de comandos, y por tanto los scripts suelen ser bastante fiables, pero parece ser que el progreso de la tecnología no lo llevan demasiado bien.

Hace unas semanas me compré un modem/router con soporte para 802.11n, en concreto el Belkin F5D8635. Aparte de que el modelo sin modem tiene switch gigabit y este no, mi portatil no conseguía conectarse a la wifi si se dejaba el modo N activado, sólo si desde la interfaz web se ponía "802.11g only" o "b/g". Temiendo que fuera un tema de drivers, ya que era mi primer contacto con una wifi N, me puse a indagar.

El comando "iwconfig" no ayuda mucho ya que muestra un bitrate de 54Mb/s o como mucho 60Mb/s. Un escaneo con iwlist scan tampoco ayuda, ya que no muestra por ningún lado que la wifi sea N o que llegue a los 270/300 Mb/s anunciados. Buscando más, resulta que hay un nuevo comando, "iw", que parece que va a ser el nuevo estándar, como el comando "ip" para la gestión de red. Igual que ip sustituye a ifconfig, route, etc, iw sustituirá a iwconfig, iwlist, iwpriv, etc. Para el caso da lo mismo ya que "iw list" tampoco muestra más de 60Mb/s. Desde luego algo raro es, ya que es más de los 54mbits de 11g, pero no deja muy claro qué es lo que significa.

Tras intentar todo lo que se me ocurrió, decidí devolver el router como defectuoso y comprar otro. Esta vez busqué por internet alguno que tuviera de todo:

• 802.11n (indispensable)
• Radio de 5GHz (importante, para evitar interferencias de hornos microondas, walkies, bluetooths, las mil wifis de los vecinos....)
• Posibilidad de meterle Linux (importante)
• Modem ADSL
• Puerto USB para discos
• Switch gigabit

Dado que ninguno cumplía con todos los requisitos acbaé comprando en pixmania el Linksys WRT610N, que tiene de todo menos modem ADSL, pero además puede usar las bandas de 2,4GHz y 5GHz a la vez, dado que tiene 2 radios.

Con el WRT610N sí que me pude conectar a la wifi en modo N, tanto en 2,4 como en 5 GHz, pero con resultados un tanto decepcionantes. Pra las pruebas conecté el X200s a la wifi a 5 GHz, para evitar cualquier tipo de interferencia de la banda de 2,4. Ejecutando como root "ping -f -s 20000 192.168.1.1" me daba una velocidad por debajo de 3,5MB/s. Teniendo en cuenta que con 802.11g me daba por debajo de 2MB/s, supone un rendimiento de apenas el 170%, cuando supuestamente debería dar un 600%.

Dejando el ping a un lado, ya que peude estar limitado por la CPU del router, conecté mi AspireOne por cable y me baje un fichero grande del servidor web en la wifi. Nada, los mismos 3,5MB/s. Para descartar un posible cuello de botella en la ethernet del Acer, conecté el server al switch, esta vez gigabit (el Acer es 10/100). Repetí la prueba y dió unos más que decentes 11,2MB/s, casi el límite teórico de una ethernet 100Mbps, así que la tarjeta del Acer estaba perfectamente.

Tras esta decepción pensé durante un rato alguna otra soulción, puesto uqe había leído por internet que la gente le sacaba 110Mbps al router y yo no llegaba ni a 35. Probé en el otro sentido, ya me sonaba que podía ser asimétrico, aunque no debería. El problema es que no estaba por la labor de instalar un apache o ftpd en el Acer sólo por probar, así que tocaba recurrir al ingenio:

# dd if=/dev/urandom of=/tmp/test bs=1M count=80
# pacman -S netcat
# nc -l -p 8080 -e "cat /tmp/test"

Y problema solucionado, ya tenía un servidor escuchando en el puerto 8080. Elegí usar urandom y no zero por evitar el uso de cualquier compresión a cualquier nivel, por si acaso. Y dado que el AspireOne tiene discos SSD que parece que son tirando a lentillos, /tmp era una punto de montaje tmpfs, es decir, en RAM.

Resultado: unos consistentes 7MB/s, oscilando entre 6,85 y 7,1. Ya era una gran mejora, aproximadamente un 400% del rendimiento de una wifi 802.11g. Pero por un lado no llegaba ni a 70Mbps y por otro seguía siendo asimétrico, como si en la subida no se usara canales de 40MHz.

Como no perdía nada, arranqué Windows Vista. Sí, sigo quieriendo demostrarme a mi mismo que no es tan malo. Y esta vez el Windows se portó bastante mejor que Linux. Para empezar, tanto Windows como la herremienta de Lenovo detectaron y listaron la wifi como 802.11n, sin lugar a dudas. Luego, tras conectarse sin problemas ni "glitches", me bajé el wget para windows para uniformizar el software y repetí la prueba. El resultado fue agridulce, pero dificilmente por culpa de Windows: la transferencia superaba los 10MB/s, llegando en ocasiones a medias de 11MB/s, pero a veces la conexión se caía por varios segundos o incluso una vez por minuto y medio, como si algo por el camino se saturase. Y dada la cercanía con los 100Mbps podía ser bien el Acer o bien el router. En todo caso, el rendimiento de la wifi en Windows parece ser sensiblemente mejor que en Linux.

Deberes para casa: echarle un vistazo a compat-wireless y repetir el benchmark de la wifi a ver si mejora el rendimiento con drivers "experimentales", aparte de buscar el culpable de la inestabilidad de la la wifi a altas velocidades.

Intel 3945, KNetworkManager y Gentoo

Dado los problemas de NetworkManager con los drivers ipw3945 decidi borrarlo todo y reinstalarlo con iwlwifi (si hasta la web en más bonita, dónde va a parar).
Bajar e instalar iwlwifi (v 1.0.0.1) + ucode(v 2.14.1.5) no da muchos problemas, aunque al cargar el modulo el nombre de la interfaz es incorrecto, con un "_rename" pegado. Basta con comentar la linea de la tarjeta en /etc/udev/rules.d/70-persistent-net.rules:

# PCI device 0x8086:0x4222 (ipw3945)
#SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:13:02:XX:XX:XX", NAME="eth1"

Y recargar el modulo:

# modprobe -r iwl3945
# modprobe iwl3945

Con lo que se generará la entrada:

# PCI device 0x8086:0x4222 (iwl3945)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:13:02:XX:XX:XX", ATTR{type}=="1", NAME="wlan0"

La cual ya podemos cambiar NAME a lo que queramos, eth1 en mi caso.


Pero eso no es todo, al intentar reinstalar el knetworkmanager (~arch) nos pide instalar libnl>1.0-pre6. Si añadimos tanto knm como libnl a /etc/poratge/package.keyword, nos encontramos con:

# emerge -av knetworkmanager
...
NetworkManager-nm-netlink.o: In function `nm_netlink_get_default_handle':
/home/dirk/src/NetworkManager/src/nm-netlink.c:58: undefined reference to `nl_handle_alloc_nondefault'
/home/dirk/src/NetworkManager/src/nm-netlink.c:61: undefined reference to `nl_handle_set_pid'
...
***KAPUT***
...
#

Y encima del error no se encuentra nada de nada por la red. El problema está en la versión de libnl que instala.Hay dos distintas en ~arch, 1.0_pre6-r1 y 1.1 y esta última rompe las cosas. Basta con hacer:

# emerge -av1 =libnl-1.0_pre6-r1
# emerge -av knetworkmanager

Y todo irá como la seda :)

Últimos coletazos de gentoo? Ya veremos...

¿Inseguridad wireless?

Tanto tiempo y esfuerzo en aprender cómo proteger la una wifi: WEP, WPA, VPN... para luego encontrarse en Internet con esto.

Y siendo Bruce Schneier el que lo dice, da mucho que pensar. Quizá sus vecinos no han descubierto el P2P, porque en España en cuanto dejas una wifi abierta en una gran ciudad ya tienes a 4 o 5 listos usando el emule con tu ADSL.

También sorprende el apoyo de Bruce al proyecto de FON, en un principio no sólo podría parecer inseguro sino que además un tercero se beneficia de ello.

Los comentarios al post también son muy interesantes, recomiendo echarles un ojo.

Saludos!

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!

(In)seguridad wireless III

¡Al fin! Tras mucho esfuerzo y sufrimiento al fin los vecinos no van a poder conectarse a mi wifi. Bueno, esto no es del todo cierto: si que van a poder conectarse, pero no van a poder usarla.

Ultimamente han llegado a mi casa multitud de chismes con capacidad wifi. A la semana de tener la PSP se le unió la Wii y hace una semana la flamante PS3. Y todos ellos con soporte WPA, así que ya tocaba hacer algo. Tras decidirme a cambiar al fin el cifrado WEP por WPA me puse manos a la obra. Hasta ahora tenía un portátil NEC PIVM 1.8GHz con 256Mb RAM haciendo de router/server con debian stable, usando cifrado WEP y un script iptables bastante molesto para posibles intrusos. Para los PC's que no tuvieran soporte de WPA (el PC de "la familia" con una tarjeta belkin 11b, p.ej.) tenía una fonera que podía poner en modo WEP con forwarding deshabilitado y OpenVPN al server, de modo que hiciera falta conectarse a la VPN para salir al exterior. No me hacía gracia usar la fonera con su firmware original para mover tráfico, pero no había otra opción de coste 0.
La tarjeta PCMCIA de 25 euros que me compre en su día llevaba ya un tiempo funcionando en modo Master + WEP gracias a los drivers prism54 y el hostapd anunciaba (y aún anuncia) que también daba soporte a este chispet para modo Master + WPA. Bien, apt-get install hostapd, leer docuemtancion, editar configuración, probar y... ¡buen intento, sigue probando!

hostapd -dd hostapd.conf
Configuration file: hostapd.conf
Opening raw packet socket for ifindex 5
ioctl(SIOCGIFINDEX): No such device
prism54 driver initialization failed.

No se encuentra dispositivo. Tras cambiar el archivo .conf durante 5 minutos lo doy por imposible y busco en internet. Al igual que en un mensaje en algún foro, lo ejecuto con strace y efectivamente, hostapd levanta la interfaz eth2 (bien) y luego intenta controlar la eth2ap (¡mal!). Por ahi sugerían recompilar el hostapd con un hack del driver prism54: quitar a pelo ese "ap" del string del nombre de la interfaz. Bueno, se puede intentar. Como los experimentos, mejor con gaseosa, quito la tarjeta del router/server debian stable y la pongo en el portatil gentoo. Copio el ebuild a un overlay local, lo edito para bajar el código del disco duro, modifico el propio código (%sap ->%s), digest del ebuild y pa'lante. Y... nada. Arranca el rpograma, saca todos sus mensajitos, pero ni pone la tarjeta en modo Master, ni WPA, ni nada de nada. Indagando más por la red, resulta que el soporte de prism54 para hostapd es por así decirlo "histórico" ya que la realidad es que "un día funcionó con una versión del driver" segun cuenta el propio creador del hostapd en este email. La cosa para prism54 dejó de funcionar allá por 2005, en el mail de 2006 dijo de avisar en la web que ya no funcionaba y a noviembre de 2007 sigue apareciendo que lo soporta para que algún pardillo pierda la tarde intentándolo. Dado que no me apetecía bucear en las versiones del 2004 del prism54 para recompilar un modulo para el kernel de 2007 y el posible fin del mundo que podría ocasionar dicha combinación, deseché esa vía.

Dado el estado de las cosas, me he decidido por otra configuración. Para los PC's, prism54 en Master + WEP (menos da una piedra) con OpenVPN y política DROP para FORWARD con origen wifi. A traves el tun0, salida a internet, así cualquiera se puede meter en la wifi pero ni podrá usarla ni escuchar nada puesto que todo irá en tuneles cifrados. Y para las consolas, fonera + WPA, así de paso se separa el tráfico de unos y otros para (en el futuro) implementar QoS con tc.

La instaltación de la OpenVPN la he hecho siguiendo el HOWTO oficial, usando certificados. Tanto para windows con OpenVPN GUI como para linux con NetworkManager el sistema funcona bastante bien.
Al hacer un 'ping server-f -s 15000' con la wifi da unas tasas de 1,1Mb/s tanto de subida como de bajada. Al hacerlo con la VPN, el trafico observado en la interfaz wifi es de apenas 350kb/s. Extrañado, cree en el server un archivo de 100MB con 'dd if=/dev/zero of=/var/www/zero' y lo bajé a traves de la VPN. Resultado: 350kb/s en la wifi, 3Mb/s de velocidad efectiva. Razón: comp-lzo haciendo su trabajo. En efecto, al intentar bajar un 'openssl rand 100000000 > /var/www/rand' las tasas en wifi eran de 2,4Mb/s y en el tunel 2,02Mb/s (todo esto con la wifi a 54Mbps teóricos). Eso sí, durante la descarga de datos, el proceso de VPN llega a consumir un 15% de CPU, asi que habrá que pensar en cambiar el cifrado blowfish por defecto por alguno más ligero...

Algún día postaré todos los ficheros de configuración y scripts de iptables, pero a día de hoy creo que ya he hecho bastante.

Eso sí, aunque ya tenga una wifi segura, no pienso ponerle antivirus al PequeSuave Ventanas XP, ¿que sería de esta vida sin riesgo?

(In)seguridad wireless II

Con un par de meses de retraso me entero que un grupo de alemanes han terminado de romper el WEP. Si bien ya era conocido que con unos cientos de miles de tramas y menos de una hora de proceso se podía sacar una clave de 128bits, el nuevo método deja esos logros a la altura del betún.

A grandes rasgos, se aprovecha de las tramas ARP para obtener cadenas de 16 bytes de datos pseudoaleatorios del RC4. Esto es gracias a que los 8 bytes de LLC y los 8 de la cabecera ARP son totalmente constantes y conocidos, tanto para la petición como para la respuesta. Así que simplemente se hace un XOR con los contenidos cifrados de la trama ARP y se obtiene el flujo RC4 original. Las propias tramas ARP se distinguen por su longitud. Repitiéndolo (muchas) veces se obtiene la cantidad necesaria de tramas cifradas con distintos IV's para efectuar un ataque estadístico y así recuperar la clave WEP de la wifi.

Ahora los números. Si antes hacían falta cerca de medio millón de tramas (mas bien de IV's) para
poder empezar el análisis con esperanza. Ahora con 40mil (tramas) nos da una esperanza del 50% de encontrar la clave. Para orientarnos, con un AP 11g eso son unos 50 segundos de inyección. Y si antes hacía falta media hora larga para encontrar la clave a partir de los IV's capturados, con el método estadístico basado en ARP se tarda.... ¡3 segundos! Resultado: crackeo (perdón, "recuperación") de claves en menos de un minuto con posibilidades de éxito y en 2 minutos con seguridad de éxito. Para más detalles técnicos, consultar el paper de los autores.

Para llevarlo a la práctica, basta con:
- Tener un punto de acceso con WEP. No, no podeis hacerlo con el del vecino, ¡eso está prohibido!
- Una tarjeta que soporte inyección
- Una versión medianamente reciente del aircrack.
- Capturar paquetes enteros en lugar de sólo IV's
- Ejecutar el aircrack-ng con la opción "-z" para que haga el análisis PTW

Mañana lo probaré con alguna clave aleatoria en un AP dedicado, a ver que tiempo consigo :D

Parece mentira que aún tras leer todas estas maravillas siga usando WEP en casa. Todo por no dedicar 3 minutos a configurar wpa_supplicant. Eso sí, tengo el (leve) atenuante de filtrado mac, iptables tocapelotas y sin servidor DHCP. No sirve de gran cosa pero al menos entorpece a posibles vecinos cotillas. Si alguien es capaz de romper la clave, spoofear su MAC y adivinar cual es el rango de IP's válido así como la IP de gateway, como premio puede usar mi ancho de banda, o lo que quede de él. Eso o tener un usuario de FON, pero eso es otra historia...

(In)seguridad wireless

El día 28 de septiembre dejé de trabajar como becario de IT en una empresa de ingeniería y como regalo de despedida recibí un PSP "Slim & Lite". Una monada el bicho por cierto. Como no sabían mis gustos en cuanto a juegos en lugar de un UMD recibí un montón de complementos: cables, protectores para la pantalla, etc.

El caso es que volvía a casa en bus y tras trastear un buen rato con las configuraciones de todo el menú me dio por mirar la wifi. La consola tiene soporte para 802.11b (la wifi de 11Mbps, vamos). Siendo como es, un aparato de unos 20cm en su dimensión más amplia no creo que tenga una antena demasiado potente. Aún así, en los 5km que estuve trasteando en el bus antes de llegar a casa encontró nada menos que 67 redes distintas. Y eso que gran parte de esos 5km era una carretera con chalets a los lados...

Y el dato curioso, o quizá preocupante. De esas 67 redes, 10 estaban totalmente sin proteger, algunas incluso con ssid's de "default" o "Wireless". Vamos, si no han cambiado ni la ssid del punto de acceso la probabilidad de entrar al router con admin/admin son más bien altas. Y las consecuencias de eso dependen únicamente de la mala leche del "invitado".
Pero hay más. De las 57 restantes, 50 tenían cifrado WEP. Sí sí, WEP, ese que se rompe en unos minutos con cualquier herramienta de "auditoría de redes". Sólo 7 de las 67 redes tenían cifrado WPA, poco más del 10%. ¿Tan difícil es? ¿No viene en los propios menús de los routers inalámbricos "Cuidado: WEP malo", "Use WPA por su seguridad" y similares? No es que el vecino de al lado tenga que saber de IV's ni inyección de tramas, pero lo mismo le interesa saber que cualquier fulano que pase por la calle tiene acceso a sus carpetas compartidas en Windows, ¿no?

No es que un viajecillo en autobús con una PSP en la mano sea un estudio serio, pero es como para plantearse si a día de hoy realmente vale la pena pagar los 30 y pico euros al mes en ADSL si invirtiéndolos en una buena antena wifi se puede localizar por la ventana decenas de vecinos deseosos de compartir sus conexiones con el mundo...

Un saludo y hasta la próxima!

PD: para que todo esto sea más gracioso, yo mismo uso WEP en casa. Pero shhhhhh......