Hackeo de millones de módems e investigación de la intrusión en mi módem

• Sam Curry descubrió que una solicitud HTTP enviada desde su red doméstica se reproducía exactamente 10 segundos después desde una IP de DigitalOcean y, tras reemplazar su gateway Cox Panoramic Wifi, el problema desapareció, por lo que sospechó que su módem anterior había sido comprometido
• La IP del tráfico reproducido, 159.65.76.209, estaba vinculada con dominios relacionados con Adidas, dominios de phishing de ISG Latam y dominios para C&C aparentemente generados por algoritmo, pero no se confirmó la ruta real de la intrusión
• Durante un análisis del portal Cox Business en 2024, se descubrieron una API basada en Spring detrás de /api/cbma/ y documentación Swagger; de unas 700 API, algunas mostraban un problema de omisión de autorización al devolver alternadamente errores de autenticación y 200 OK
• Esta omisión de autorización permitía buscar clientes, consultar PII de cuentas, consultar direcciones MAC de equipos, consultar IP de módems, leer y escribir cuentas de Cox Business, y realizar cambios de configuración de equipos como modificar el SSID WiFi; en la PoC, su propio SSID cambió a Curry
• Cox retiró las API expuestas en menos de 6 horas tras el reporte, y al día siguiente ya no fue posible reproducir el problema; afirmó que el servicio de API había comenzado en 2023, que era independiente de la intrusión al módem de 2021 y que no había antecedentes de explotación previa

---

Tráfico anómalo que empezó en el módem de casa

• Para probar una vulnerabilidad blind XXE desde su red doméstica, levantó un servidor HTTP simple en Python en una instancia de AWS y verificó si recibía solicitudes externas
• Justo después de que quedara registrada correctamente una solicitud enviada con curl desde la computadora de su casa, una IP desconocida, 159.65.76.209, volvió a solicitar la misma ruta 10 segundos después
• Cuando solicitó otra ruta desde Safari en un iPhone, la misma IP también reprodujo la misma solicitud, por lo que parecía una situación en la que se observaba el tráfico de toda la red doméstica, no de una computadora específica
• El mismo fenómeno se repitió con una nueva instancia de AWS y Nginx, y luego también con una instancia de GCP, por lo que se descartó la posibilidad de una intrusión en AWS
• Tras devolver en la tienda el gateway Cox Panoramic Wifi anterior y reemplazarlo por un equipo nuevo, el tráfico reproducido desapareció y ya no aparecía “otra IP” en los logs

Investigación de 159.65.76.209

• Se confirmó que esa IP pertenecía a DigitalOcean y no era una dirección del ISP Cox
• En los registros de VirusTotal, de los 5 dominios conectados recientemente, 3 eran sitios de phishing y 2 parecían servidores de correo
  • regional.adidas.com.py
  • isglatam.online
  • isglatam.tk
  • mx12.limit742921.tokyo
  • mx12.jingoism44769.xyz
• isglatam.online e isglatam.tk fueron en algún momento sitios web de phishing dirigidos contra la empresa sudamericana de ciberseguridad isglatam.com
• Según los registros de URLscan, los dos dominios relacionados con ISG Latam alojaban sitios de phishing BeEF genéricos, y los registros relacionados pueden consultarse en los resultados de urlscan.io
• Aunque la misma IP estaba vinculada con Adidas, ISG Latam y la reproducción de tráfico del módem, no podía descartarse por completo que la IP hubiera sido reasignada entre varios propietarios

Análisis retomado 3 años después

• A comienzos de 2024, amigos del área de seguridad notaron el formato de limit742921.tokyo y jingoism44769.xyz
• Al realizar una búsqueda inversa de IP a partir de la IP del subdominio mx1 de limit742921.tokyo, se encontraron más de 1,000 dominios con el mismo patrón
• Todos los nombres de dominio tenían la forma [palabra][6 números].[TLD]
  • Ej.: acquire543225.biz
  • Ej.: battery935904.biz
  • Ej.: grocery634272.biz
• Por el registro masivo y la estructura algorítmica, parecían un algoritmo de generación de dominios usado por operadores de malware para ocultar direcciones de servidores C&C
• El último dominio observado se registró el 17 de marzo de 2023; para entonces ya no resolvía a ningún host y no se encontraron dominios similares registrados en la misma IP

Hipótesis a partir de funciones de administración del ISP y TR-069

• Los agentes de soporte de Cox podían actualizar el módem de forma remota, cambiar la contraseña WiFi y ver los dispositivos conectados
• Esta administración remota se relaciona con el protocolo TR-069, implementado en 2004, mediante el cual los ISP administran equipos dentro de la red a través del puerto 7547
• TR-069 en sí no estaba expuesto al exterior y ya había sido tratado en charlas de DEF CON, por lo que el interés se desplazó hacia las herramientas de soporte y API internas usadas por los agentes
• Se consideró que, si un atacante quisiera comprometer un módem, podría apuntar a la infraestructura base de las herramientas de soporte, en especial a API capaces de cambiar la configuración de equipos de clientes o ejecutar comandos arbitrarios
• La investigación terminó orientándose a revisar la capa de confianza entre el ISP y los equipos del cliente, más que a confirmar la ruta real de intrusión de 2021

Estructura de API del portal Cox Business

• En el archivo JavaScript de frontend main.36624ed36fb0ff5b.js del portal Cox Business se identificaron más de 100 llamadas a API basadas en /api/cbma/
• La ruta /api/cbma/ tenía un comportamiento de respuesta distinto al de otras rutas /api/, por lo que parecía una API proxificada hacia un backend separado del frontend
  • /api/anything_else/example devolvía una respuesta de redirección
  • /api/cbma/example devolvía 500 Internal Server Error
• Las solicitudes de registro incluían encabezados como clientid, Apikey, Cb_session y Authorization, y el formato de las respuestas parecía de un backend basado en Spring
• Al cambiar el método HTTP, apareció una respuesta de error de Spring, lo que confirmó que el backend de la API estaba basado en Spring
• No se encontraron rutas de actuator, pero sí se descubrió una ruta de Swagger UI

Carga eludida de documentación Swagger y 700 API

• Swagger UI cargaba, pero los recursos estáticos entraban en un bucle de redirección y la documentación aparecía vacía
• Parecía que las solicitudes a recursos estáticos como .js, .css y .png se enrutaban al host base, no al proxy de la API
• Al agregar %2f, una / codificada, al final de la URL, fue posible cargar los recursos JavaScript estáticos a través del proxy de la API
• Al usar match-and-replace de Burp para agregar %2f a las solicitudes de recursos estáticos, la documentación Swagger se mostró correctamente
• En total se identificaron unas 700 llamadas a API, y las áreas más relacionadas con funciones de equipos y cuentas fueron accountequipment, datainternetgateway y account

Omisión de autenticación y acceso a datos de clientes

• Al repetir solicitudes contra todos los endpoints GET, algunos devolvían errores de autenticación y otros 200 OK; incluso la misma solicitud alternaba resultados al repetirse
• El endpoint profilesearch inicialmente devolvía resultados de búsqueda vacíos y luego, ante la misma solicitud, alternaba entre errores de autenticación y respuestas exitosas
• Al repetir solicitudes con el término de búsqueda cox, se devolvieron resultados que parecían perfiles de clientes empresariales de Cox y un profileGuid
• Al solicitar con el término fbi, se devolvieron resultados que incluían direcciones físicas de varias oficinas de campo del FBI que eran clientes empresariales de Cox
• El mismo problema de permisos afectaba a otras API, y al reproducir una solicitud varias veces era posible acceder a funciones administrativas incluso sin autenticación

Consulta de direcciones MAC de equipos e información de cuentas

• Al tomar la dirección MAC de su propio módem desde la cuenta de Cox e ingresarla en una API con el parámetro macAddress, se devolvió la dirección IPv4 de ese equipo
• Este resultado confirmó que la API del sitio web de Cox Business podía comunicarse con equipos reales
• La API de lista de equipos que usa el ID de cuenta devolvía información de los equipos vinculados a la cuenta
  • Categoría del equipo
  • Nombre del modelo
  • Dirección MAC
  • Información de puertos
  • Número de serie
• La API de consulta de usuarios por correo electrónico devolvía información de cuentas empresariales como nombre, teléfono, estado, tipo de usuario, si era propietario del perfil y correo alternativo
• También funcionaban solicitudes POST similares de actualización de cuentas, lo que confirmó que era posible leer y escribir cuentas empresariales

encryptedValue y cambios de configuración de equipos

• Las solicitudes de cambio de configuración de equipos requerían el parámetro encryptedValue
• Las funciones encryptWithSaltandPadding y decryptWithSaltandPadding dentro de JavaScript se usaban para cifrar y descifrar valores con AES
• El PIN de 4 dígitos configurado al registrar una cuenta también se cifraba con la misma función, por lo que era posible obtener el contexto de ejecución de esa función en el depurador del navegador
• Al descifrar el encryptedValue incluido en la respuesta de un equipo de la cuenta de un conocido que usaba Cox Business, se encontraron los siguientes elementos
  • Número de cuenta de Cox
  • Nombre del equipo
  • ID del equipo
  • Valor desconocido
  • Dirección MAC
  • Etiqueta
• Aunque se rehiciera el cifrado de una cadena con valores arbitrarios para el número de cuenta y el ID del equipo, dejando solo una dirección MAC válida, la solicitud tenía éxito; esto confirmó que el servidor no verificaba la correspondencia entre la dirección MAC y la cuenta

Posibilidad de cambiar arbitrariamente la configuración de módems

• Se envió una solicitud POST para cambiar el SSID WiFi dirigida a la dirección MAC de su propio equipo
• La respuesta fue 200 OK y Success, y luego la red quedó brevemente fuera de línea
• Unos 5 minutos después, la red se reinició y el SSID cambió a Curry
• Esta PoC mostró que la API de actualización de configuración de equipos realmente funcionaba y que un atacante podía sobrescribir configuraciones de equipos mediante la API
• Ese nivel de permisos era similar al del soporte técnico del ISP y podía afectar a millones de equipos Cox accesibles por la API

Alcance del impacto y posibles flujos de ataque

• La combinación de vulnerabilidades creaba una ruta por la cual un atacante externo sin requisitos previos podía cambiar la configuración de millones de módems, acceder a PII de clientes empresariales y obtener privilegios de nivel soporte del ISP
• Cox es el mayor proveedor privado de banda ancha de Estados Unidos, el tercer mayor proveedor de TV por cable y el séptimo mayor operador telefónico; tiene millones de clientes y es el ISP más popular en 10 estados
• Los posibles flujos de ataque eran los siguientes
  • Buscar objetivos de Cox Business por nombre, teléfono, correo electrónico o número de cuenta
  • Consultar PII de cuentas, direcciones MAC de equipos, correos electrónicos, teléfonos y direcciones mediante el UUID devuelto
  • Consultar la contraseña WiFi y los equipos conectados usando la dirección MAC del equipo
  • Ejecutar comandos arbitrarios, actualizar propiedades de equipos y tomar control de cuentas de víctimas
• Había más de 700 API expuestas, y muchas ofrecían funciones administrativas como consultar equipos conectados al módem
• Cada API sufría el mismo problema de permisos que permitía ejecutar comandos no autorizados mediante solicitudes repetidas

Reporte, parche y dudas pendientes

• La vulnerabilidad se reportó a través del programa de divulgación responsable de Cox
• Cox retiró las llamadas a las API expuestas en menos de 6 horas, y al día siguiente ya no fue posible reproducir la vulnerabilidad
• Según la investigación de Cox, no había antecedentes de explotación previa de ese vector, y el servicio vulnerable había comenzado en 2023, por lo que no pudo haberse usado para la intrusión al módem de 2021
• Cox informó que no tenía ninguna relación con la IP de DigitalOcean, por lo que el módem original quedó como comprometido por un método distinto al revelado en este artículo
• Como el módem original había sido devuelto, no fue posible hacer un dump del firmware ni un análisis forense, y tampoco se confirmó por qué se reproducía el tráfico

Línea de tiempo de divulgación

• 2024-03-04: Reporte de la vulnerabilidad mediante el programa de divulgación responsable de Cox
• 2024-03-05: Aplicación de hotpatch; los endpoints empresariales no esenciales pasan a devolver 403 y dejan de funcionar
• 2024-03-06: Envío de correo a Cox indicando que ya no era posible reproducir la vulnerabilidad
• 2024-03-07: Cox responde que iniciará una revisión de seguridad integral
• 2024-04-10: Se comunica a Cox la intención de publicar 90 días después del reporte
• 2024-04-29: Se comparte con Cox el enlace al borrador del blog

[GN⁺]

Opiniones de Hacker News

• albinowax_ publicó esto primero, y me molestaba que no recibiera karma, así que moví el comentario a https://news.ycombinator.com/item?id=40560010
  Espero que xrayarx lo tome bien. Tenemos planeado implementar correctamente el karma compartido para estos casos, pero hasta entonces a veces recurrimos a este tipo de método manual algo tosco
  • Según el sistema, yo lo publiqué hace 13 horas y él lo publicó hace 10 horas. Así que no entiendo muy bien eso de que él lo publicó primero