OpenWrt en Fonera 2200

Me he quedado sorprendidísimo con FON. Monstando la instalación de red de la casa he decidido desempaquetar una fonera que llevaba año en la estantería tal como la trajo en mensajero. Como suponía, era el modelo 2200, que se alimenta a 7,5V y 1A (las otras iban a 5V, 2A) y dicen que se calienta mucho menos y tal. También me sonaba que la revisión del firmware en estas era más nueva, con lo que ya no funcionaba mi método favorito para abrir el ssh, usando script injection en un formulario web.
instrucciones
Volviendo a la página de los alemanes que sacaron todos los ataques busqué el kolofonium, que por lo visto funcionaba con solo cambiar el DNS y ellos usaban un RADIUS trucado para abrir el ssh. Dicen en la web que loguean la IP y la MAC de cada fonera que desbloquean, lo que no me hacía mucha gracia. También era un método que dependía del servicio de terceros y dado que es de hace unos años podía estar ya retirado, pero aún así lo intenté. En la web tienen estadísticas hasta de enero de 2009, así que puede que aún funcione. Renicio, espero, resultado: FAIL.

Sigue sin haber ssh. Enruto la fonera a través del portátil y arranco el wireshark. Bien, le problema está claro. La fonera intenta bajarse el heartbeat.php y el falso download.fon.com que tienen montado contesta con un 403. Mal asunto. Intercepto el puerto 80 de su servidor y me hago un hearbeat.php que devuelva vacío. No le gusta. Pues uno que devuelva "OK". Le gusta. Por curiosidad miro el original de fon.com. Devuelve "OK". Que originales somos los informáticos.

Bien, sigamos con el kolofonium... sin suerte. Otra vez wireshark, el RADIUS contesta con un ICMP de port unreachable. Maaaal asunto. Para comprobar el puerto de RADIUS (1812 UDP) pruebo un:

# nmap -sU -p U:1812

Y efectivamente que está cerrado. Estupendo, el RADIUS de kolofonium está caído, y por lo visto ya no está mantenido.

Busco por google, nada alternativo. Busco en la pagina de OpenWrt y dicen que ¡el RedBoot está activado por defecto! Ojo, la IP cambia de 192.168.1.254 a 192.168.1.1 aunque el puerto sigue siendo el 9000. Instalo putty para linux, arranco la fonera y ¡BINGO! Me bajo la última versión estable, flasheo según las instrucciones para la versión 2100 (en la wiki avisan que valen para la 2200, no era por jugar a la ruleta rusa) y ¡voilá! OpenWrt en la fonera funcionando perfectamente. O casi. Para ponerla en modo cliente+ap no vale con editar la configuración, hay que hacerlo más a mano, pero eso lo dejo para otra entrada.

El sistema ha mejorado mucho mucho desde la última vez que lo probé. Ahora ya funciona el led de la wifi, el de power es controlable por software desde "/sys/class/leds/gpio7/brightness", funciona el watchdog, la configuración del sistema es bastante más ampila, pudiendo personalizar el reset... en fin, merece la pena probarlo.

Si alguien tiene alguna duda, estaré encantado resolverla. Los scripts para el modo cliente+ap los pondre cuando estén terminados del todo.

Volviendo al tema del principio, me he quedado alucinado con fon. Al principio se tomaban tantisimas molestias por evitar que la gente trastee con el router y ahora lo dejan abierto para flasheos... aunque viendo su historial lo sería nada raro que fuera otro agujero de seguridad, jejeje.

Fonera Reseteada

Finalmente el firmware kamikaze 7.07 que le instalé a la fonera no soluciono mi problema. Al pasar un día dejó de responder igual que con el 7.09, por lo que me mosqueó que pudiera tener algún fallo de hardware, ya que no encontré a nadie que se quejara de algo así por Internet. Mirando en la página de fon me dí cuenta de que esa fonera era la que había dado de alta, así que decidí reinstalar el firmware original de fon version 0.7.1.1, para tener un linux operativo y a la vez colaborar con fon, pues es lo minimo que puedo hacer despues de que me hayan regalado los routers. Hasta ahora lleva un record de 4 dias de uptime sin cuelgues (a los 4 días la tuve que cambiar de enchufe), y tiene pinta de ser estable.

Una vez con la fonera controlada me dio por coger la que estaba bloqueada. Había activado el ssh muchos meses atrás para trastear con ella. Por supuesto, desactivé la autoactualización para que fon no trasteara con ella. Y como suele pasar, tras un par de meses sin entrar se me olvidó la contraseña. El método normal para cambiar la password era a través de la página de fon (aotuactualización), por lo que no iba a funcionar. La otra opción era darle al botoncito de reset de debajo, pero no parecía funcionar. El funcionamiento del reset es muy curioso ya que lo que hace es tocar es sistema de ficheros.
La fonera de serie (y luego con Kamikaze también) trae dos "particiones" de la flash. La primera es de solo lectura y está comprimida (squashfs) y es lo que hay de inicio en el firmware. Más tarde, toda la flash que no ha sido utilizada para la imagen raíz se queda como disponible, con el sistema de archivos jffs2. Cuando la fonera arranca, monta la parte squashfs en /rom y la jffs2 en /jffs.

root@mercury_friendship:~# mount
rootfs on / type rootfs (rw)
/dev/root on /rom type squashfs (ro)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /tmp type tmpfs (rw,nosuid,nodev)
tmpfs on /dev type tmpfs (rw)
none on /dev/pts type devpts (rw)
/dev/mtdblock3 on /jffs type jffs2 (rw)
mini_fo:/jffs on / type mini_fo (rw)

Por último para el sistema raíz / usa mini_fo, una combinación sobre la marcha de ambos sistemas de ficheros: si algo está en jffs lo lee de ahí, y si no lo busca en rom, de manera que se puede "modificar" los ficheros de la rom creando un fichero con la misma ruta en jffs, ya que este archivo se leerá antes.
Sabido esto, lo que pasa al darle al boton reset, es que la fonera borra todo el contenido de la parte jffs, quedando por tanto sólo la parte rom, que contiene el estado original del sistema.

Pues en mi caso por desgracia esto no pasaba. En teoria debería arrancar tal como llegó de fon, con el firmware hackeable, contraseña por defecto y el ssh capado, pero no ocurría esto, arrancaba como si nada. Despues de probar todos los métodos posibles (al arrancar 5 segundos, durante todo el arranque, ya encendida, en dos arranques seguidos, etc.) llegué a la conclusión de que algo no funcionaba bien así que qué mejor que destriparla y mirar. Y ya que no se veía nada raro, caí en que quizá el propio botón de reset estaba estropeado y rescaté una placa de prácticas de electrónica de hace unos años para voler a sacarle partido, con este resultado:

Montaje de los cables

El CD está para poder ver qué luces están encendidas, ya que los leds quedaban mirando hacia abajo y no podía darle la vuelta ya que los cables no estaban soldados a la fonera.


Un poco más cerca:

Como se puede ver es bastante sencillo, dos cables y un pulsador externo. Podría haber hecho simplemente "un puente" pero así es bastante más cómodo.

Con el montaje del pulsador externo el reseteo funcionó a la primera, pulsandolo un ratito mientras arrancaba, luego ya solo quedó abrir ssh, cambiar kernel e instalar una versión nueva de OpenWrt. Aunque para mi disgusto, siguió dando error.

Por suerte, esta vez he descubierto que no soy el único al que le da este error. El problema reside en que el módulo madwifi del kernel y el hostapd comparten alguna porción del código y si se usan versiones de distintas fuentes el resultado no es muy bueno. En caso de la fonera el problema está en que usaba el kernel 2.6.23.1 del 3 de diciembre pero el directorio packages de ese kernel sólo tenía 15 o 20 paquetes ipk, y el hostapd no estaba entre ellos, así que use los ipk del directorio del kernel del 3 de octubre. Así que o bien uso un kernel más antiguo (con sus posibles cuelgues), espero a que el tío que lleva esa página saque más paquetes para el 2.6.23.1 (que no tiene pinta) o bien lo compilo yo solito, que va a ser la solución. Pero eso lo dejo "para después de la publicidad".

Un saludo!

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:

# 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

Al reiniciar, ya podemos cambiar la configuración de RedBoot, con los siguientes comandos:

# 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

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.
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:

# 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

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:

• 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/

Las versiones "estables" (por llamarlas de algún modo) se pueden bajar de la página de OpenWrt: http://downloads.openwrt.org/kamikaze/, siendo la versión más nueva la 7.09. Los archivos para la fonera son los de la subcarpeta atheros-2.6.

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.
  

Como dije al principio, ahora tengo el 7.07, a ver que tal funciona este, habra que esperar 30 horas...