Como hemos puesto ese título tan subversivo tenemos que hacer uno de esos "Disclaimers" o, en español, algo así como renuncia a toda responsabilidad legal.

Dicho esto, en el resto de este artículo, nosotros vamos a utilizar un viejo router TP-link que tenemos por ahí para este tipo de pruebas, y eso es lo que os aconsejamos hacer (utilizar vuestro propio router).

Lo segundo que tenemos que decir, es que, para tener nuestro entorno bajo control, nuestro router va a estar flasheado con un firmware opensource. Hemos probado tanto DD-WRT como OpenWRT y todo lo que vamos a contaros ha funcionado sin problemas en ambas.

Para terminar, y antes de meternos en el fregao, comentaros que una versión reducida de este artículo fue publicada hacer algunas semanas en un foro on-line y en inglés. El autor es el mismo, servidor, pero este artículo no es una simple traducción literal de el otro... es mucho más!

Vamo allá.

Preparando el Router

Como hemos dicho, en este artículo, vamos a suponer que el router está ejecutando algún tipo de Firmware abierto (DD-WRT u OpenWrt van perfectos com ya os hemos dicho). La razón es que, necesitamos poder habilitar el acceso al intérprete de comandos en el router, lo que no siempre es posible con los firmwares originales instalados en los routers. Al menos, sin liarla parda.

Tanto DD-WRT como OpenWrt nos proporcionan un cómodo interfaz gráfico para configurar los servicios que queremos ejecutar en nuestro router. Lo que vamos a hacer es activar el servidor ssh para poder acceder al router desde la línea de comandos. Podéis encontrar los detalles de como hacer esto en las webs de los respectivos firmwares. En general, solo hay que pulsar un botón en un panel que debería llamarse "Services" o algo así.

Aquí tenéis una captura del panel de control de OpenWrt en nuestro router, para haceros una idea, y otra de un DD-WRT.

DD-WRT Service Panel	OpenWrt Dropbear es el servidor SSH

Consiguiendo Información del Router

Ahora que podemos acceder a la línea de comandos, tendremos que obtener información sobre la arquitectura de nuestro router especifico y así poder determinar que toolchain necesitamos para la compilación cruzada de nuestro programa.

Los routers van bastante pillados tanto de memoria como de espacio de almacenamiento, así que no es posible compilar directamente nuestro programa en el router y por lo tanto tendremos que compilarlo en otro ordenador, pero generando un ejecutable para el procesador utilizado por el router. Eso es lo que se llama Compilación Cruzada o Cross-Compiling.

Bueno, como íbamos diciendo necesitamos saber que procesador tiene nuestro router para poder escoger el toolchain apropiado. Así que nos conectamos por ssh al router y sacarle alguna información. Algunos comandos que podéis probar son:

# uname -a
Linux Er_ROUTER 3.10.49 #3 Wed Oct 1 14:00:51 CEST 2014 mips GNU/Linux

#cat /proc/cpuid
system type             : Atheros AR9341 rev 1
machine                 : TP-LINK TL-WR841N/ND v8
processor               : 0
cpu model               : MIPS 74Kc V4.12
BogoMIPS                : 266.64
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0000, 0x0020, 0x0a70, 0x0260]
isa                     : mips1 mips2 mips32r1 mips32r2
ASEs implemented        : mips16 dsp dsp2
shadow register sets    : 1
kscratch registers      : 0
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

En nuestro caso, el router usa un procesador MIPS de 32bits dentro de un SoC (System On Chip) Atheros. Con esa información y un poco de ayuda de Google, encontramos un toolchain compatible con nuestro router.

En nuestro caso, hemos encontrado un toolchain compatible, en los foros de dd-wrt...

http://www.dd-wrt.com/phpBB2/viewtopic.php?t=61112

En concreto, este toolchain funciona bien con los chipsets de Atheros comunes en los router TP-Link. En los Linksys/Cisco os podéis encontrar chipsets de Broadcom que, en principio, necesitan otro tipo de configuración.

Para saber si el toolchain que habéis conseguido es el bueno, solo tenéis que compilar cualquier programa... por ejemplo, un sencillo "Hola Mundo", subirlo al router y ejecutarlo. Si funciona, habéis encontrado la configuración correcta.

Otra forma más directa de conseguir vuestro toolchain es seguir las instrucciones para generar uno proporcionadas por la página oficial del Firmware que estéis utilizando. El primer paso para poder generar ese firmware es obtener/generar un toolchain.

En el resto del artículo, veremos como compilar, subir y ejecutar una aplicación al router.

Compilando Un programa

Para poder compilar un programa necesitamos instalar nuestro toolchain. Esto es mucho más sencillo de lo que parece. Solo tenéis que añadir al PATH, el directorio en el que se encuentran todos los ficheros interesantes.

Para nuestro ejemplo concreto, la secuencia de comandos a ejecutar es:

$ cd /tmp
$ tar xjv toolchain-tarball
$ export PATH=/tmp/toolchain-tarball-path-to/bin:$PATH

Así de fácil. En caso de duda, lo que tenéis que buscar es un directorio en el que se encuentren todas las herramientas necesarias para compilar un programa (gcc, as, ld,...), pero con un prefijo que identifica la plataforma. En el nuestro caso, el prefijo es mips-linux-.

Ahora ya podemos compilar nuestro programa. Podéis probar primero con un "Hola Mundo", pero nosotros vamos directamente con el programa que utilizaremos como puerta trasera en nuestro propio router. Por supuesto!. Se trata del infame NetKitty.

Descargamos el código de Savannah, y compilamos con algo como esto:

$ mips-linux-gcc -static -o nk-mips nk.c

Notad que estamos creando un fichero estático. La razón es que un fichero estático no requiere de ninguna librería. Va a funcionar siempre que el procesador y el sistema operativo sean los correctos.

Además, en un router no os vais a encontrar muchas librerías. Mirad por ejemplo lo que hay en nuestra instalación OpenWRT:

root :~ # ls /usr/lib/
iptables              libiwinfo.so          libxtables.so.10.0.0
libip4tc.so           libjson-c.so.2        lua
libip4tc.so.0         libjson-c.so.2.0.1    opkg
libip4tc.so.0.1.0     liblua.so.5.1.5       pppd
libip6tc.so           libnl-tiny.so         uhttpd_ubus.so
libip6tc.so.0         libxtables.so
libip6tc.so.0.1.0     libxtables.so.10
root :~ # 

Subiéndolo y ejecutando

Ahora ya solo tenemos que subir nuestro programa al router y ejecutarlo. Puesto que hemos habilitado el acceso SSH, podemos utilizar el comando scp para subir nuestro fichero al router. Algo como esto:

$ scp nk-mips root@router_ip:/tmp

Estamos copiando nuestro fichero en tmp, ya que los sitios en los que podemos escribir y ejecutar programas están limitados. El directorio temporal está siempre ahí, y, en general, nos permite tanto escribir como ejecutar. No os olvidéis de dar permisos de ejecución, que a veces son eliminados en el proceso de copia. Con scp deberían estar correctos, pero nosotros los forzamos igualmente.

Veámoslo

Accedemos al router y ejecutamos NetKitty:

$ ssh root@router_ip
# cd /tmp
# chmod +x nk-mips
$ ./nk-mips
NetKitty Version 01.09.1
(c) 2006-2011,2013,2016. David Martinez Oliveira

Usage: nk [-daemon] [-shell] [-hub] [-os] [-client ((T|U|B|S),(ip|bt|serial),(port|baud))+] [-server ((T|U|B),port)+]

Estupendo todo funciona perfectamente. En principio no necesitamos acceder a la línea de comandos del router explícitamente. Utilizanfo ssh podemos ejecutar cualquier commando remotamente desde nuestra máquina de desarrollo. Algo tal que así:

$ ssh root@router_ip "/tmp/nk-mips"

Lo del título

Bueno, al empezar dijimos que el título no se trataba de uno de esos ClickBaits sin mucho contenido. Así que vamos a deciros como todo lo que os hemos contado, se puede convertir en una puerta trasera corriendo en un router casero.

El truco está en el reciente modo daemon de la última version de NetKitty, así como su capacidad para ejecutar un shell remoto. El modo daemon lo necesitamos para poder cerrar nuestra session ssh y que el programa siga funcionando. Si, amigos mios, en estos pequeños, no vais a encontrar ni nohup, ni screen, ni nada similar... así que lo mejor es lanzar un daemon y dejarlo ahí corriendo.

Esto se puede conseguir con el siguiente comando:

# nk-mips -d -sh -s T,5000
# exit

Ahora, si nos conectamos a la ip del router, puerto 5000. Zaca!, acceso root a la shell del router!. Nuestra puerta trasera instalada.

Vaya, esto asusta un poco

Si eh?. Da un poco de juju. Tenemos a netkitty en tu router, permitiendo a cualquier acceder a él, toquetear tus conexiones. Bueno, en un típico ClickBait, se promocionaría el sensacionalismo hasta limites insospechados...

Nosotros como somos asín, vamos a ser más realistas.

Para que un cracker (sí, esa es la palabra correcta, hacker significa otra cosa), pueda instalar esta puerta trasera debería hacer lo siguiente:

• Obtener acceso a nuestra red, ya sea a través de wifi (crackeando la clave wifi) o del cable (más díficil por las limitaciones físicas)
• Luego debería obtener acceso al panel de control del router (mirar más abajo), para poder activar el acceso SSH que por defecto está desactivado
• Una vez que tenga acceso SSH, entonces podría hacer todo lo que os hemos contado antes
• Cuando haya dejado la puerta trasera instalada en el router, debería desactivar el acceso SSH (o almenos dejarlo como estaba), para no levantar sospechas

Para que todo lo que os acabamos de contar funcione, se tienen que dar un montón de condiciones bastante improbables:

• El router tiene que estar configurado para permitir el acceso wifi al panel de control. Normalmente, los routers modernos solo permiten el acceso al panel de control desde una conexión por cable.
• Aún así, el atacante tiene que averiguar la contraseña de la red wifi para poder connectarse y acceder al panel de control para habilitar el acceso ssh/telnet. Una red wifi que use WPA2 es muy, muy difícil de crackear.
• Tras todo eso, el atacante necesita averiguar el password para acceder al panel de control y poder activar el accesso ssh/telnet, que suele estar desactivado por defecto.

Como veis, si habéis seguido las normas básicas de configuración de redes wifi: Cambiar contraseñas por defecto, utilizar WPA2 y restringir el accesso al panel de control al máximo. Las probabilidades de que alguien consiga llegar tan lejos son bastante remotas.

Además, ahora sabéis como ejecutar vuestros propios programas en vuestro router, así que podéis, fácilmente, escribir/compilar algún programa de monitorización que os alerte de una intrusión.

Haciendo nuestros programas pequeños

Si lo que os hemos contado hasta ahora ha funcionado, en estos momentos, tendréis una versión estática de NetKitty que puede correr en vuestro router. Echadle un ojo al tamaño. Debería ser unos 700/800 Kb, lo que para un router es una barbaridad. Por ejemplo, la versión de busybox en mi router ocupa menos de 300 Kb y ofrece unos cuantas funciones.

Usage: busybox [function [arguments]...]
   or: busybox --list
   or: function [arguments]...

        BusyBox is a multi-call binary that combines many common Unix
        utilities into a single executable.  Most people will create a
        link to busybox for each function they wish to use and BusyBox
        will act like whatever it was invoked as.

Currently defined functions:
        [, [[, arping, ash, awk, basename, brctl, bunzip2, bzcat, cat, chgrp,
        chmod, chown, chroot, clear, cmp, cp, crond, crontab, cut, date, dd,
        devmem, df, dirname, dmesg, du, echo, egrep, env, expr, false, fgrep,
        find, free, fsync, grep, gunzip, gzip, halt, head, hexdump, hostid,
        hwclock, id, ifconfig, kill, killall, less, ln, lock, logger, ls,
        md5sum, mkdir, mkfifo, mknod, mkswap, mktemp, mount, mv, nc, netmsg,
        netstat, nice, nslookup, ntpd, passwd, pgrep, pidof, ping, ping6,
        pivot_root, poweroff, printf, ps, pwd, readlink, reboot, reset, rm,
        rmdir, route, sed, seq, sh, sleep, sort, start-stop-daemon, strings,
        switch_root, sync, sysctl, tail, tar, tee, telnet, telnetd, test, time,
        top, touch, tr, traceroute, true, udhcpc, umount, uname, uniq, uptime,
        vconfig, vi, wc, wget, which, xargs, yes, zcat

La memoria disponible es limitada en estos dispositivos, así que, cuanto más pequeño sea nuestro ejecutable mejor.

En números anteriores de Occam's Razor, ya os hablamos de como hacer vuestros programas muy pequeñitos. Una opción es utilizar uCLinux, y la otra es utilizar dietlibc. uCLinux está preparado para compilación cruzada. Solo tenéis que configurar la librería para el tipo de vuestro router... bueno, no es que sea trivial, pero al menos disponemos de un menu para configurar las cosas.

Con dietlibc, las cosas no es que sean mucho más complicadas, pero merecen una breve explicación.

Dietlibc para MIPS, ARM,...

Si instaláis la versión de dietlibC de vuestra distribución, lo más probable es que solo instale los ficheros para vuestra máquina (x86 o x86_64). Pero nosotros necesitamos compilar para MIPS. Quizás alguna distribución disponga de esas versiones, pero en caso de no ser así, la solución tampoco es tan difícil.

Descargaros la última version de dietlibc de su web: https://www.fefe.de/dietlibc/. Sí amigos, la última version es de 2013, pero aún así nos va a solucionar el problema.

Descomprimidla, y lo único que ahora tenéis que hacer es recompilarla para las distintas arquitecturas soportadas (MIPS y ARM están soportadas), utilizando vuestro compilador cruzado. Si, el que utilizamos anteriormente.

Primero haced una instalación normal, siguiendo las instrucciones. Además de compilar la versión para vuestra plataforma, instalaréis el script que utilizaremos más tarde para compilar. Es el mismo para todas las plataformas, así que esto solo tendréis que hacerlo una vez.

Poniendo a dieta a NetKitty

Ahora podemos compilar la librería para nuestra plataforma, utilizando nuestro compilador cruzado.

Para nuestro ejemplo, el proceso sería más o menos:

make ARCH=mips CROSS=mips-linux-uclibc- all

Para recompilarla para ARM con el toolchain proporcionado por debian (el que podéis instalar del repositorio), sería algo tal que así:

make ARCH=arm CROSS=arm-linux-gnueabi- all

Con nuestra flamante versión de dietlibc para MIPS (y quizás también para ARM), podemos recompilar nuestro querido NetKitty con un comando tal que asín:

diet -Os mips-linux-uclibc-gcc -o nk-diet-mips-1.9.1 nk.c -lcompat

Si. Tenemos que añadir la librería compat, para que funcione la función daemon. Si también quisiéramos una versión de NetKitty para ARM y poder ejecutarla en nuestro teléfono Android, o en nuestra Rpi, o en nuestra BBB o.... Podríamos utilizar el comando:

diet -Os arm-linux-gnueabi-gcc -o nk-diet-arm-1.9.1 nk.c -lcompat

Ahora, nuestro binario estático, debería ocupar unos 20Kbytes.... Mucho mejor.

Bueno, esto es todo por hoy. Esperamos que os haya resultado interesante y no olvidéis enviarnos vuestros experimentos!

■