Aunque digan que la medicina es una profesión vocacional, las ingenierías no se quedan atrás. No creo que nadie aguante 5 cursos (es decir, 7-8 años) de caminos, teleco o aeronáutica sólo porque "luego tienes muchas salidas". Fontanero también tiene muchas salidas, y con todo mi respeto a los fontaneros, es bastante más fácil. Y aunque la informática sea quizá el patito feo de las ingenierías, no se queda atrás. De hecho, a veces en la carrera te putean incluso un poco más, para recuperar el terreno perdido, debe de ser. El problema es que existe una cultura popular en la que si sabes escribir una carta en Word, sabes informática, si sabes navegar por Internet eres un experto y si ya sabes instalar Pequesuave Ventanas XP es que ya te falta nada para ser Guillermo Puertas.
Pero en mi caso es por puro frikismo y pasión por los chips, los bytes y todoas esas cosas. Me parecía fascinante como simplemente escribiendo una serie de comandos se podía hacer que un montón de chatarra "cobrara vida" e hiciera exactamente lo que se le decía (pantallazos azules aparte). Por aquel entonces ni siquiera tenía ordenador y me dedicaba a ojear viejos libros sobre Basic que dios sabe de dónde salieron. Más tarde cuando ya compramos el primer PC, un PIII 450Mhz el problema eran los recursos. No conocía nada de linux y en Pequesuave Ventanas para programar necesitabas "suites" de Borland o cosas similares, inalcanzables. Tras un primer intento (ridíiiiiculo) con Visual Basic (5, si no recuerdo mal) conseguí el DIV2, con el que hice mi primer matamarcianos, siguiendo un tutorial de una revista. En aquellos tiempos oscuros sin Internet la información era un tesoro y un chaval de 14 años no podía permitirse el lujo de comprar un libro de programación. En la biblioteca del pueblo sólo había un viejo libro de Pascal, que me daba la sensación de ser un lenguaje viejo e inútil. Para entonces ya había empezado a oir cosas sobre Linux y que estaba hecho en un lenguaje llamado C, al igual que muchos videojuegos, así que ese era el lenguaje a aprender. Tras mucho esfuerzo conseguí unos programas ejemplo tipo "hola mundo" en C, ¡bajados de Internet! en un ordenador del instituto y poco más tarde todo un señor libro de programación en C. Poco a poco empecé a "dominar" el tema, aunque algunas cosas me seguían pareciendo cosa de magia, y casi sigue siendo así hasta ahora (casi, ¿eh?), como pueden ser la programación Win32, DirectX, OpenGL, programación multimedia... Cuando llegué al instituto la asignatura de informática era (de nuevo, casi) mejor que el recreo. La parte de Pequesuave Oficina era para lerdos y la parte hiper-dificil de programación en C consistía en hacer un hola mundo y un programa que haga ordenaciones números enteros. Nada de quicksort: empezando por un ¿voy bien así? y alcanzando la máxima complejidad con un modo de burbuja de orden estrictamente n cuadrado y su digi-evolución, el método de burbuja mejorado, donde el bucle interno de inicia más allá de los elementos ya ordenados, que es el que viene en la wikipedia.
Y finalmente teminé le bachillerato y conseguí sustituir literatura e historia por física y programación. Tras un principio traumático con Haskell y su paradigma "no-uso-variables-pero-tengo-funciones-auxiliares-para-
guardar-información-que-necesitare-mas-tarde-y-que-
en-realidad-es-una-implemetación-tremendamente-
ineficiente-y-liosa-de-variables" pasamos a ADA, que no era tan distinto de C, aunque le añadía la funcionalidad de tipado: "no puedes sumar cantidad y 5, porque cantidad es del tipo_dinero y 5 es del tipo_integer". Pero eso era pasable, bastaba con tener un poco de cuidado y todo era coser y cantar. Hasta que en tercero llegó la programación orientada a objetos. De repente, desapareció cualquier rastro de otro tipo de programación y los profesores daban las clases rezando "padre nuestro que estás en un patrón factoría" en lugar de padre nuestro y en vez de "nos creó a su imagen y semejanza" era "heredamos de él atributos y métodos por ser una clase hija".
Y yo me preguntaba... ¿de verdad que todo lo que he aprendido hasta ahora no me vale para nada? ¿Será que los objetos es lo único que vale y que se usa y todo lo demás son tecnologías obsoletas? Yo desde luego me apaño perfectamente haciendo todas las prácticas en C sin haber aprendido a fondo ni C++ ni Java en lo que llevo de carrera. Y el núcleo de linux o GTK están hechos en C, pero quizá en C++ serían más bonitos, más fáciles y te harían café y tostadas por las mañanas... Por suerte en barrapunto me he encontrado con algunos comentarios sobre una entrevista al creador de C++ y con una simpática respuesta de Linus Torvalds que me han aclarado que la programación orientada a objetos es simplemente una forma más que tiene sus puntos fuertes y sus aplicaciones, no la panacea como nos quieren hacer ver.
Y por cierto, como dicen tambien en barrapunto, habría que ver la reacción de Linus si alguien le propone migrar el kernel de C a C++. Matarle quizá no le mate, pero seguro que contrata a esta gente para que vaya por las noches bajo su ventana ;)
Thursday, December 27, 2007
Tuesday, December 25, 2007
Blogger con OpenID
Antes de nada... ¡Feliz Navidad! Por ser unas fechas tan especiales, hoy no habrá tochopost.
Par hoy solo una pequeña nota, que ya había leído antes, pero me ha parecido interesante recordar: blogger ya permite identificarse con OpenID. Parece que este es el empujoncito final para hacer que OpenID alcance una "masa crítica" y se convierta por fin en un estándar. Para mas información, consultar el link ;)
¡Cuidado con los turrones, que luego vienen los propósitos de año nuevo y el gimnasio está muy caro!
Par hoy solo una pequeña nota, que ya había leído antes, pero me ha parecido interesante recordar: blogger ya permite identificarse con OpenID. Parece que este es el empujoncito final para hacer que OpenID alcance una "masa crítica" y se convierta por fin en un estándar. Para mas información, consultar el link ;)
¡Cuidado con los turrones, que luego vienen los propósitos de año nuevo y el gimnasio está muy caro!
Wednesday, December 19, 2007
Todo sobre mi Fonera
Tras una larga batalla parece ser que a la fonera no le gusta ninguno de los firmware nuevos, asi que le he flasheado uno un poco mas antiguo, el OpenWrt Kamikaze 7.07. Pero hasta aqui, he recorrido un largo camino, por una vez y sin que sirva de precedente, contaré la historia desde el principio de los tiempos.
Para quien no conozca la fonera, basicamente en un pequeño router inalambrico con un firmware basado en linux que durante un tiempo se pudo conseguir gratis con unas invitaciones y que ahora la gente se dedica a hackear.
Lo vende la empresa fon con el objetivo de que compartas tu adsl a cambio de usar el adsl de los demás usuarios. Y si alguien que no es usuario de fon quiere usar tu adsl, pues le paga un dinero a fon, y fon le deja usar tu adsl. Como aquel refrán de "cada uno en su casa y Dios en la de todos", fon pretende que cada uno comparta su adsl y ellos sacan dinero alquilándolo como si fuera suyo.
Pues bien, hace unos meses, creo que por navidades, fon decicio regalar un numero de foneras a los usuarios que llevaran mas tiempo registrados y sin fonera. Ahí conseguí la primera. Más tarde, sacó una promocion donde invitando a un amigo a fon, le regalaban una fonera. Ahí conseguí otras 3, y porque me daba palo seguir pidiendo. Y como soy bueno, dejé una de ellas enchufada para compartir mi adsl, que tampoco me cuesta nada.
Una vez con la(s) fonera(s) en mis manos, tocó empezar a trastear. Lo primero fue habilitar el ssh. Dado que tenía una versión antiguilla del firmware, lo pude hacer gracias a un fallo en una página de configuración. Clásico ejemplo de formulario mal validado, el programador se esperaba un valor y el usuario proporciona un comando del sistema operativo. El código no valida la entrada del usuario, y al intentar leer el valor, ejecuta el comando. Para más info sobre la técnica, que mejor sitio que la wikipedia. El formulario vulnerable en cuestión es uno de la página connection.sh, que sirve para (¡sorpresa!) configurar las conexiones de la fonera. El método paso por paso está muy bien explicadito en esta página. Merece la pena leer los demás artículos de la web, que aunque se dejó de actualizar hace mucho, son bastante instructivos.
Una vez tenemos acceso por ssh podemos hacer dos cosas: flashear la fonera con otro "sistema operativo" o bien dejarla como está.
Si la dejamos como está, lo primero que hay que hacer es habilitar el ssh al arranque y asegurarse que la fonera no se autoactualice. Por un lado, porque podríamos perder el ssh e incluso el "bug" para habilitarlo de nuevo y por otro lado, para que la gente de fon no pueda trastear en nuestra red.
El asunto del ssh es fácil, basta con hacer un: "ln -s /etc/init.d/dropbear /etc/init.d/S50dropbear".
La auto-acualización tampoco es difícil. Por defecto, la fonera cada X tiempo (1 hora creo recordar) se baja un script de fon.com y lo ejecuta, con privilegios de root, normalmente para efectuar los cambios que hagamos a traves de la pagina web de fon a nuestra fonera o actualizar el firmware. Digamos que nos fiamos de fon y confiamos que no nos quieren espiar ni robar (...), pero si alguna vez el servidor de fon se ve comprometido, el atacante tendria total libertad de hacerse con el control de cientos de miles de redes domesticas en todo el mundo, simplemente cambiando el script inofensivo que manda fon por el suyo propio, seguro que mucho mas interesante. Para evitar que esto ocurra, hay que modificar el script que se ejecuta periódicamente (/bin/thinclient) y comentar la línea que ejecuta el script bajado: ". /tmp/.thinclient.sh". Esta es la configuración que tengo en la fonera que sigue conectada como fonera propiamente dicha.
La otra opción, mucho más interesante, es flashear la fonera con otro firmware. Para ello hace falta poder escribir en la memoria persistente del aparato, pero no se puede hacer directamente. Cuando la fonera se enciende, no arranca directamente el kernel de linux, sino un gestor de arranque llamado RedBoot. Normalmente este gestor se para unos segundos antes de arrancar, esperando que se pulse una tecla para interrumpir el proceso. Por supuesto, la fonera no tiene teclado así que o bien se hace por una consola serie, o bien por telnet. La consola serie es accesible por hardware si se hace un circuito adaptador con un chip MAX232 y la consola telnet (mucho más cómoda) es accesible ya que el RedBoot arranca un server telnet mientras espera la pulsación. Pero claro, la gente de fon configuró el RedBoot para que al arrancar se pusiera la IP 0.0.0.0 y de este modo el server no está disponible. Y configuraron el kernel para evitar que se cambie la configuración del RedBoot. De este modo, para flashear la fonera primero tenemos que cambiar el kernel por otro equivalente pero que deje cambiar la configuración del RedBoot:
Una vez conectados, nos sale el aviso de pulsar ctrl+c para interrumpir el arranque. El cliente telnet estándar no parece ser capaz de hacer esto, así que han surgido por Internet varias alternativas. Una es enviarle el símbolo con netcat, otra usar un script en perl, pero quizá la más cómoda sea usar Putty, bien desde Pequesuave Ventanas o desde linux con Wine. Basta con conectarse y cerrar la ventana, una vez interrumpido el arranque nos podemos conectar con cualquier cliente telnet. A partir de este momento ya somos libres de meter cualquier distribución que nos apetezca, aunque solo hay dos que parecen estar mas o menos maduras, OpenWrt y DD-WRT.
Para instalar la distribución tenemos que bajarnos las imagenes del kernel y el sistema de archivos y ponerlos en un server TFTP en la subred. Desde el RedBoot ejecutamos:
Pero todo tiene su parte mala, y es que esto no siempre funciona:
Para quien no conozca la fonera, basicamente en un pequeño router inalambrico con un firmware basado en linux que durante un tiempo se pudo conseguir gratis con unas invitaciones y que ahora la gente se dedica a hackear.
Lo vende la empresa fon con el objetivo de que compartas tu adsl a cambio de usar el adsl de los demás usuarios. Y si alguien que no es usuario de fon quiere usar tu adsl, pues le paga un dinero a fon, y fon le deja usar tu adsl. Como aquel refrán de "cada uno en su casa y Dios en la de todos", fon pretende que cada uno comparta su adsl y ellos sacan dinero alquilándolo como si fuera suyo.
Pues bien, hace unos meses, creo que por navidades, fon decicio regalar un numero de foneras a los usuarios que llevaran mas tiempo registrados y sin fonera. Ahí conseguí la primera. Más tarde, sacó una promocion donde invitando a un amigo a fon, le regalaban una fonera. Ahí conseguí otras 3, y porque me daba palo seguir pidiendo. Y como soy bueno, dejé una de ellas enchufada para compartir mi adsl, que tampoco me cuesta nada.
Una vez con la(s) fonera(s) en mis manos, tocó empezar a trastear. Lo primero fue habilitar el ssh. Dado que tenía una versión antiguilla del firmware, lo pude hacer gracias a un fallo en una página de configuración. Clásico ejemplo de formulario mal validado, el programador se esperaba un valor y el usuario proporciona un comando del sistema operativo. El código no valida la entrada del usuario, y al intentar leer el valor, ejecuta el comando. Para más info sobre la técnica, que mejor sitio que la wikipedia. El formulario vulnerable en cuestión es uno de la página connection.sh, que sirve para (¡sorpresa!) configurar las conexiones de la fonera. El método paso por paso está muy bien explicadito en esta página. Merece la pena leer los demás artículos de la web, que aunque se dejó de actualizar hace mucho, son bastante instructivos.
Una vez tenemos acceso por ssh podemos hacer dos cosas: flashear la fonera con otro "sistema operativo" o bien dejarla como está.
Si la dejamos como está, lo primero que hay que hacer es habilitar el ssh al arranque y asegurarse que la fonera no se autoactualice. Por un lado, porque podríamos perder el ssh e incluso el "bug" para habilitarlo de nuevo y por otro lado, para que la gente de fon no pueda trastear en nuestra red.
El asunto del ssh es fácil, basta con hacer un: "ln -s /etc/init.d/dropbear /etc/init.d/S50dropbear".
La auto-acualización tampoco es difícil. Por defecto, la fonera cada X tiempo (1 hora creo recordar) se baja un script de fon.com y lo ejecuta, con privilegios de root, normalmente para efectuar los cambios que hagamos a traves de la pagina web de fon a nuestra fonera o actualizar el firmware. Digamos que nos fiamos de fon y confiamos que no nos quieren espiar ni robar (...), pero si alguna vez el servidor de fon se ve comprometido, el atacante tendria total libertad de hacerse con el control de cientos de miles de redes domesticas en todo el mundo, simplemente cambiando el script inofensivo que manda fon por el suyo propio, seguro que mucho mas interesante. Para evitar que esto ocurra, hay que modificar el script que se ejecuta periódicamente (/bin/thinclient) y comentar la línea que ejecuta el script bajado: ". /tmp/.thinclient.sh". Esta es la configuración que tengo en la fonera que sigue conectada como fonera propiamente dicha.
La otra opción, mucho más interesante, es flashear la fonera con otro firmware. Para ello hace falta poder escribir en la memoria persistente del aparato, pero no se puede hacer directamente. Cuando la fonera se enciende, no arranca directamente el kernel de linux, sino un gestor de arranque llamado RedBoot. Normalmente este gestor se para unos segundos antes de arrancar, esperando que se pulse una tecla para interrumpir el proceso. Por supuesto, la fonera no tiene teclado así que o bien se hace por una consola serie, o bien por telnet. La consola serie es accesible por hardware si se hace un circuito adaptador con un chip MAX232 y la consola telnet (mucho más cómoda) es accesible ya que el RedBoot arranca un server telnet mientras espera la pulsación. Pero claro, la gente de fon configuró el RedBoot para que al arrancar se pusiera la IP 0.0.0.0 y de este modo el server no está disponible. Y configuraron el kernel para evitar que se cambie la configuración del RedBoot. De este modo, para flashear la fonera primero tenemos que cambiar el kernel por otro equivalente pero que deje cambiar la configuración del RedBoot:
Al reiniciar, ya podemos cambiar la configuración de RedBoot, con los siguientes comandos:# Ir a la ram
cd /tmp
# Bajarse el kernel modificado (cualquiera de los dos sitios vale)
wget http://fonera.info/camicia/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
wget http://ipkg.k1k2.de/hack/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
# Copiar el kernel de la ram a la flash, mtd es el equivalente a dd para dispositivos flash
mtd -e vmlinux.bin.l7 write openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma vmlinux.bin.l7
# Reiniciar con el kernel modificiado
reboot
La fonera se reinicia y durante los primeros 10 - 15 segundos nos podemos conectar por telnet al RedBoot. Si tras el ultimo flasheo la fonera no termina de arrancar, no pasa nada, es posible que ocurra, en este caso se va a quedar parada en el RedBoot sin arrancar linux. Al arrancar el RedBoot se asigna la IP 192.168.1.254/24 sin puerta de enlace, por lo que habrá que hacer telnet (al puerto 9000) desde la misma subred o a través de una máquina que haga NAT en esa subred.# Ir a la ram
cd /tmp
# Bajarse el archivo de configuracion binario de RedBoot (ambos sitios son validos)
wget http://fonera.info/camicia/out.hex
wget http://ipkg.k1k2.de/hack/out.hex
# Volcar el contenido del archivo a la flash, (aqui podemos romper algo y que no arranque)
mtd -e "RedBoot config" write out.hex "RedBoot config"
# Reiniciar con el server telnet de RedBoot activo al arranque
reboot
Una vez conectados, nos sale el aviso de pulsar ctrl+c para interrumpir el arranque. El cliente telnet estándar no parece ser capaz de hacer esto, así que han surgido por Internet varias alternativas. Una es enviarle el símbolo con netcat, otra usar un script en perl, pero quizá la más cómoda sea usar Putty, bien desde Pequesuave Ventanas o desde linux con Wine. Basta con conectarse y cerrar la ventana, una vez interrumpido el arranque nos podemos conectar con cualquier cliente telnet. A partir de este momento ya somos libres de meter cualquier distribución que nos apetezca, aunque solo hay dos que parecen estar mas o menos maduras, OpenWrt y DD-WRT.
Para instalar la distribución tenemos que bajarnos las imagenes del kernel y el sistema de archivos y ponerlos en un server TFTP en la subred. Desde el RedBoot ejecutamos:
Y con esto ya tendríamos la fonera como un router cualquiera ejecutando un firmware "neutro". Ahora ya sólo quedaría elegir un firmware, pero eso ya depende de los gustos de cada uno, en mi caso tiro más por consola, así que OpenWrt. Para tener las versiones mas nuevas se puede mirar en varios sitios:# Asignamos IP a la fonera y le decimos el server por defecto
ip_addr -h IP_SERVER_TFTP -l 192.168.1.254/24
# Inicializamos (formateamos) la flash
fis init
# Cargamos el kernel en ram a partir de la dirección 0x80041000
load -r -b 0x80041000 NOMBRE_ARCHIVO_KERNEL
# Volcamos el kernel a la flash indicando los puntos de entrada y de ubicacion en memoria
fis create -r 0x80041000 -e 0x80041000 vmlinux.bin.l7
# Calculamos el espacio libre, el comando nos dira principio y fin del bloque.
# Hacemos (fin - principio) y da el tamaño, que suele ser 0x006F0000.
fis free
# Cargamos el rootfs en ram a partir de la dirección 0x80041000
load -r -b 0x80041000 NOMBRE_ARCHIVO_ROOTFS
# Volcamos el contenido del archivo a la flash. Tarda mucho sin responder, hasta 10 minutos
fis create -l 0x006F0000 rootfs
# Reiniciamos con el nuevo firmware
reset
- Sincronizar con el SVN y compilarselo uno todo (si se tiene mucha paciencia y tiempo libre)
- Revisiones r9xxx del foro de fonera.info, ahora mismo la r9703.
- Compilaciones de k1k2.de, en el momento de escribir este post la última es la r96xx del día 3 de diciembre, y su puede bajar de http://ipkg.k1k2.de/fonera_2.6.23.1/
Pero todo tiene su parte mala, y es que esto no siempre funciona:
- Las versiones mas nuevas no soportan WPA en modo AP, hay un fallo en el modulo de madwifi y no se puede asignar una clave a la interfaz. Pasa lo mismo tanto para la versión de k1k2.de como de fonera.info,
- La ultima version estable, la 7.09, no lo es. Con la wifi sin proteger perece ser que no tiene problemas, pero con hostapd activo (1 wifi con WPA+TKIP y sin clientes) no dura más de 36 horas sin colgarse. Desaparecen todas las wifis y la fonera deja de responder a los pings por ethernet. Probado con las versiones 0.57 y 0.58 de hostapd.
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:
Aparece esto otro:
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:
Pues nada, ¡a flashear de nuevo!
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 -> ASSOCIATINGEn lugar de aparecer el handshake:
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])
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=16Ojala 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.
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
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!
Saturday, December 8, 2007
Troubleshooting: disparando...
Bueno, aqui estoy otra vez. Ha pasado un mes desde la ultima entrada, pero entre viajes de estudios y entregas de practicas no ha habido mucho tiempo para bloguear. El viaje ha sido bastante interesante y educativo, una introducción a algoritmos de compresion de datos. Un tema para el cual vale la pena escribir una entrada un diade estos.
Pero a lo que iba, que mejor para volver al escribir que unos pocos problemillas de esos que tanto molestan.
Para empezar, el open office. Un programa fascintante, sobre todo cuando se instala en gentoo y no se usa el paquete binario: Nunca imagine que algo podría tardar tantas horas en compilarse en un Core Duo con 2GB de RAM. Pero ese no es el problema. El problema es mucho mas curioso y divertido. Arranco el oowriter, y no puedo poner tildes. Tecla de tilde, tecla de letra y... ¡nada! Ni siquiera sale la letra sin tilde. Y luego el mas dificil todavia: desde un konsole de root, se arranca el oowriter y ¡todo funciona! La ventana sale con el feo aspecto de GTK, pero se puede escribir correctamente. Tras trastear con las variables de entorno, consegui reproducir el comportamiento con un usuario normal haciendo unset de la variable KDE_FULL_SESSION antes de arrancar oowriter. Pero el problema era otro, y era que las locales estaban sin configurar. Por supuesto, la página de donde saque la info, no podia ser de otro sitio que de la documentacion de gentoo. Creado el archivo 02locales en /etc/env.d/ y todo listo y funcionando.
El segundo (y ultimo por hoy) problema por desgracia no ha conseguido solucionarlo, pero si al menos evitarlo. Se trata de un bonito fallo al reproducir video:
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 141 (XVideo)
Minor opcode of failed request: 19 ()
Serial number of failed request: 90
Current serial number in output stream: 91
Esto parece ser un fallo en el driver de video de intel que hace incompatible el uso de xcomposite y XVideo. He probado todas las soluciones habidas que he visto: añadir parametros Cachelines /LinearAlloc a xorg.conf, etc y ninguna parece funcionar (por el momento al menos). La manera de evitar este problema es bien no usar xcomposite y decir adios a compiz o bien configurar el reproductor para no usar xvideo y usar xshm para reproducir. En cualquier caso, el resultado funciona pero deja mal sabor de boca. Como se suele decir, mas se perdio en cuba, y ellos no tenian la competencia de Pequesuave. Y total, con la velocidad a la que se desarrolla compiz, seguro que en nada esta arreglado el tema.
Por hoy lo dejo que es tarde, hasta la proxima!
Pero a lo que iba, que mejor para volver al escribir que unos pocos problemillas de esos que tanto molestan.
Para empezar, el open office. Un programa fascintante, sobre todo cuando se instala en gentoo y no se usa el paquete binario: Nunca imagine que algo podría tardar tantas horas en compilarse en un Core Duo con 2GB de RAM. Pero ese no es el problema. El problema es mucho mas curioso y divertido. Arranco el oowriter, y no puedo poner tildes. Tecla de tilde, tecla de letra y... ¡nada! Ni siquiera sale la letra sin tilde. Y luego el mas dificil todavia: desde un konsole de root, se arranca el oowriter y ¡todo funciona! La ventana sale con el feo aspecto de GTK, pero se puede escribir correctamente. Tras trastear con las variables de entorno, consegui reproducir el comportamiento con un usuario normal haciendo unset de la variable KDE_FULL_SESSION antes de arrancar oowriter. Pero el problema era otro, y era que las locales estaban sin configurar. Por supuesto, la página de donde saque la info, no podia ser de otro sitio que de la documentacion de gentoo. Creado el archivo 02locales en /etc/env.d/ y todo listo y funcionando.
El segundo (y ultimo por hoy) problema por desgracia no ha conseguido solucionarlo, pero si al menos evitarlo. Se trata de un bonito fallo al reproducir video:
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 141 (XVideo)
Minor opcode of failed request: 19 ()
Serial number of failed request: 90
Current serial number in output stream: 91
Esto parece ser un fallo en el driver de video de intel que hace incompatible el uso de xcomposite y XVideo. He probado todas las soluciones habidas que he visto: añadir parametros Cachelines /LinearAlloc a xorg.conf, etc y ninguna parece funcionar (por el momento al menos). La manera de evitar este problema es bien no usar xcomposite y decir adios a compiz o bien configurar el reproductor para no usar xvideo y usar xshm para reproducir. En cualquier caso, el resultado funciona pero deja mal sabor de boca. Como se suele decir, mas se perdio en cuba, y ellos no tenian la competencia de Pequesuave. Y total, con la velocidad a la que se desarrolla compiz, seguro que en nada esta arreglado el tema.
Por hoy lo dejo que es tarde, hasta la proxima!
Subscribe to:
Posts (Atom)
