¿De quién es tu router? Ingeniería inversa de un Comtrend GRG-4355u de Digi

El router que te deja el operador no es tuyo del todo. Lo pagas en la cuota, vive en tu casa y lleva tu tráfico, pero su firmware lo decide el ISP, hay cuentas que no ves, y por un canal de gestión remota el operador puede reconfigurarlo, actualizarlo o reaprovisionarlo cuando quiera. Para un lector de ciberseguridad eso es una pregunta de modelo de amenazas: ¿quién controla de verdad este aparato, y qué puede hacer un atacante que tenga las credenciales de la pegatina?

Este artículo responde a esa pregunta sobre un caso concreto: el Comtrend GRG-4355u que Digi distribuye para fibra. Le hicimos ingeniería inversa —sin abrir la caja, sin UART, sin JTAG, solo por la red local—, encontramos una cadena de debilidades que lleva de una cuenta de invitado a root, y después lo convertimos en un router neutro y endurecido que ya no obedece al operador. Todo sobre equipo y línea propios.

Nota de investigación responsable. Todo lo que sigue es sobre un aparato propio, en la línea propia, en la LAN, con cambios reversibles y rollback documentado. No publicamos ni una credencial, ni un hash, ni un número de serie, ni la receta paso a paso: esto es un análisis de clases de vulnerabilidad y su significado, no un arma contra el parque de un ISP. Un detalle que vale la pena contar: el propio guardrail de la IA con la que trabajamos se negó a ejecutar el login root interactivo, y esos pasos los hizo el humano. La seguridad también se hace así.

El ecosistema: un OpenWrt del fabricante con dueños compartidos

Antes de tocar nada, el inventario. El GRG-4355u lo fabrica Comtrend (aunque Digi lo distribuya), monta un SoC Airoha EN7581 (cuatro núcleos ARM Cortex-A53), y por dentro corre un OpenWrt del fabricante con interfaz LuCI, kernel 5.4.55, bajo la etiqueta de firmware DIG-1.3.22. Las unidades que hemos visto declaran hardware 1.1 o 1.2.

Lo interesante no es la foto del hardware, sino el mapa de quién manda sobre él:

• Cuentas: hay un admin, un user de bajo privilegio —cuyas credenciales suelen venir en la pegatina— y un root. Lo llamativo: entrar por SSH con las cuentas normales no da una shell de Linux, sino un CLI restringido del fabricante (/sbin/cli).
• El plano web: LuCI habla por HTTPS con rpcd/ubus, el bus de llamadas de OpenWrt. Ahí se decide, por configuración, qué puede leer y escribir cada login.
• Una capa de control oculta: además del firewall estándar (UCI), el fabricante instala cxt_acl_lan, un control de acceso propio fuera del UCI. Es decir, hay reglas que deciden qué puertos están abiertos que no se ven en la configuración normal del cortafuegos.
• El ISP, por encima de todo: un agente TR-069 / CWMP conecta con el servidor de gestión (ACS) del operador por una VLAN de gestión separada. Ese canal puede empujar configuración, firmware y credenciales. El dueño de la casa no lo apaga desde la interfaz.

Esa última pieza es la tesis del artículo: el eslabón de confianza más fuerte del aparato no es local, es del operador.

Ingeniería inversa: de invitado a root, por la red

El objetivo no era abrir la caja. El reto era partir de lo que tiene cualquiera —las credenciales de bajo privilegio de la pegatina y acceso a la LAN— y ver hasta dónde se llega. Se llega a root, encadenando cuatro debilidades del plano de gestión.

V1 · El plano de autorización se rompe a sí mismo. La primera debilidad es la más elegante y la más grave. En rpcd, cada login tiene una lista de permisos. La cuenta de bajo privilegio pertenece, por configuración de fábrica, a un grupo que le permite escribir la propia configuración que define sus permisos. Dicho de otro modo: una cuenta restringida puede editar las reglas que la restringen y ascenderse a permisos de comodín. No hace falta ningún exploit de memoria; es un fallo de modelo de autorización. Es, además, la parte que el propio proyecto dejó preparada para publicación, porque es la lección: el límite de privilegios estaba mal dibujado.

V2 · Exfiltrar el firmware por la red. Con permisos amplios, el siguiente paso es conseguir el firmware, del que no hay copia pública. No hace falta un UART: un endpoint de descarga autenticado del propio sistema web sirve ficheros completos incluyendo dispositivos de bloque crudos, lo que permite volcar las particiones de flash enteras por HTTPS. Es una clase de fallo —lectura de ficheros/bloques más allá de lo previsto— que convierte una sesión autenticada en una exfiltración de firmware y NVRAM. (El detalle exacto de la petición queda fuera: es la parte armable.)

El análisis offline, y el premio: DES crypt en 2026. Con el rootfs en la mano (un squashfs comprimido), se extrae /etc/shadow. Y ahí aparece el hallazgo que un lector de seguridad reconoce al instante: el hash de la contraseña root de fábrica usa DES crypt tradicional —el esquema de los años 70, de 56 bits y solo 8 caracteres significativos—, obsoleto desde hace décadas. Se rompe offline sin esfuerzo. Que un router de gama actual, de 2026, guarde su hash root en DES es un fallo de higiene de primer orden.

V · El muro no era la contraseña. Un detalle instructivo: tener la contraseña root no bastaba, porque el puerto SSH daba timeout. No por cifrado ni por la contraseña, sino porque esa capa oculta del fabricante (cxt_acl_lan) tenía el servicio SSH desactivado por política, fuera del cortafuegos visible. El dueño lo habilita desde el control de acceso del fabricante y el puerto 22 abre. Lección: hay estado de seguridad relevante que la interfaz no te enseña.

V3 · Persistencia limpia. Curiosamente, cambiar la contraseña de root desde la interfaz falla ("usuario no autorizado"), pero la escritura de ficheros sí está disponible con los permisos elevados. Así que la persistencia se hizo por el camino estándar de OpenWrt: una clave pública SSH en el authorized_keys de root. Login por clave, sin tocar /etc/shadow, y con las cuentas admin/user intactas. Reversible borrando un fichero.

V4 · El atajo del CLI. Y por si faltaba, el CLI del fabricante guarda su contraseña de modo privilegiado ("enable") como un doble base64 en la configuración, legible por la cuenta de bajo privilegio. Eso no es cifrado, es ofuscación: se decodifica de forma trivial. Un secreto de fabricante guardado con codificación reversible es, en la práctica, un secreto en claro.

Lo que esto significa

Resumido en clases: autorización rota (V1), exfiltración de firmware por lectura de bloques (V2), hash débil y contraseña por defecto (DES crypt), capa de control oculta (cxt_acl_lan) y secreto de fabricante ofuscado, no cifrado (V4). Ninguna requiere acceso físico. Cualquiera con las credenciales de la pegatina y la LAN puede, en principio, sacar el firmware entero, la NVRAM y obtener root persistente. Y como el aparato lo gestiona el operador por TR-069, el plano de gestión remota es tan crítico como el local.

Qué hicimos después: un router neutro y endurecido

Encontrar root es la mitad entretenida. La mitad útil es recuperar el control del aparato y dejarlo rápido, robusto y bajo tu mando, sin romper la fibra. Todo lo que sigue es reversible y está pensado para sobrevivir a un reinicio.

Autonomía: fuera TR-069. Lo primero, quitar el agente TR-069/CWMP (easycwmp y los paquetes asociados) y deshabilitar sus demonios. Con eso, el operador deja de gestionar, actualizar y reaprovisionar el equipo automáticamente. Es el cambio que más devuelve el control: el router pasa a arrancar de su configuración guardada, sin un ACS decidiendo por ti.

Debloat reversible. Un router doméstico trae un montón de servicios que no usas y que son superficie de ataque: VoIP, DLNA/Samba/FTP, multicast proxy, UPnP, DDNS, SNMP, telemetría varia. El script de optimización apaga alrededor de 22 servicios, guardando el estado para poder revertir. Clave: se hace con lista blanca de lo que nunca se toca —el stack PON (la fibra), el firewall, dropbear, rpcd, uhttpd, DNS/DHCP, NTP— para no romper nada esencial.

La optimización que no hicimos, a propósito. Aquí la decisión de ingeniería interesante: nada de SQM ni de tuneos de BBR/buffers. Suena contraintuitivo, pero el EN7581 hace NAT por hardware (HW NAT/PPE); meter colas de software o reescribir los buffers sacaría el tráfico del camino del hardware y lo haría más lento. El AQM ya lo hacen las colas del propio chip. La única sintonía de red fue subir el conntrack_max (de 16.384 a 65.536) y bajar el nivel de log de consola. Honestidad técnica: el cambio de gobernador de CPU se dejó anotado pero en el EN7581 resulta ser un no-op (se queda en userspace), así que no cuenta como mejora.

Robustez y persistencia. Los cambios viven en el overlay (UBIFS), así que sobreviven a un reinicio. Un reset de fábrica sí los borra —por diseño del aparato—, y por eso el proyecto tiene una re-entrada automatizada que vuelve a dejar el router en su estado conocido sin intervención manual. Cada cambio tiene su procedimiento de vuelta atrás.

El router neutro. El objetivo final era poner tu router detrás y usar el GRG solo como ONT. Se puede, puenteando la VLAN de Internet (la 20) al puerto de 10 Gb (LAN5): el GRG hace de ONT tonto y tu router hace de router. En nuestro montaje, además, un segundo equipo quedó como punto de acceso tonto para la Wi-Fi.

¿Y firmware propio? El veredicto honesto

La pregunta natural de cualquiera que llega hasta aquí: ¿y por qué no flashear OpenWrt de verdad y olvidarse del firmware del fabricante? La respuesta, tras evaluarlo, es que hoy no es viable en el GRG si quieres conservar la fibra.

El motivo es el SoC. El EN7581 es a la vez el router y la ONT (la parte óptica), y todo el stack de fibra —los módulos de kernel del MAC PON, el demonio de red de Airoha, la pila OMCI— es binario cerrado y atado al kernel 5.4.55. OpenWrt upstream tiene soporte básico del EN7581 (Ethernet, Wi-Fi, routing), pero no hace PON: flashearlo significa quedarte sin fibra. Reutilizar los blobs del fabricante sobre un OpenWrt moderno tampoco va: los módulos de 5.4.55 no cargan en kernels 6.x y nadie ha portado la pila PON del EN7581.

Las alternativas realistas, por tanto, no pasan por el GRG:

• Un stick SFP ONT "8311" (el ONT en un transceptor) en el puerto SFP de tu propio router, programado con la identidad de la línea. Tu router es el router; el operador solo controla el stick por OMCI.
• Modo bridge, que es lo que dejamos montado: el GRG como ONT en puente y tu router detrás.

Decir "no se puede, y esto es lo que sí" es parte del oficio. Un resultado honesto vale más que una promesa que brickea la fibra.

Modelo de amenazas y lo que nos llevamos

• El plano de gestión manda sobre todo lo demás. Da igual lo fuerte que sea la contraseña Wi-Fi si una cuenta local puede reescribir sus propios permisos y si el operador puede empujar configuración por TR-069. La seguridad de un router se juega en quién controla su gestión, local y remota.
• Los valores por defecto a escala de parque son el riesgo real. Una contraseña trivial y un hash root en DES crypt, si son comunes a toda la flota, exponen a cada unidad al mismo compromiso local. DES en 2026 es un fallo de higiene difícil de justificar.
• Ofuscación no es cifrado. Un doble base64 "protegiendo" un secreto de fabricante es un secreto en claro con un paso extra. Lo mismo vale para cualquier "codificación" que un atacante deshace mentalmente.
• Hay planos de control que no ves. Un firewall del fabricante fuera del UCI, o un TR-069 que no puedes apagar desde la interfaz, significan que no tienes visibilidad completa del estado de seguridad de tu propio aparato. Recuperarla —quitando TR-069, mapeando cxt_acl— es parte del endurecimiento.
• Investiga sobre lo tuyo, y con freno. Equipo propio, línea propia, LAN, cambios reversibles, y sin publicar lo que arma a un tercero. Que un guardrail te pare el login root y lo tenga que hacer el humano no es un estorbo: es el modelo de responsabilidad funcionando.

El router del salón resultó ser un objetivo de seguridad completo: autorización rota, firmware exfiltrable por la red, criptografía de los setenta y un operador con un canal de control que el dueño no ve. Convertirlo en un aparato neutro, rápido y bajo tu mando fue la recompensa; el mapa de confianza —y de quién manda de verdad— es lo que nos llevamos.

Recursos

• OpenWrt — el sistema sobre el que se construye el firmware del fabricante y la alternativa de referencia: openwrt.org.
• Proyecto 8311 — firmware para sticks SFP ONT, la vía realista al "router propio" en fibra: busca la comunidad 8311.
• Sobre TR-069 / CWMP y la gestión remota de CPE: el estándar del Broadband Forum (TR-069).