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

• Las solicitudes HTTP de la red doméstica se reproducían tal cual unos 10 segundos después desde una IP de DigitalOcean, lo que reveló indicios de que el tráfico de varios dispositivos detrás de una gateway Cox Panoramic Wifi estaba expuesto al exterior
• El rastreo en VirusTotal y URLscan mostró que esa IP había estado vinculada anteriormente con dominios de phishing y con dominios masivos del formato word+6 digits+TLD, lo que planteó la posibilidad de un algoritmo de generación de dominios para C&C
• Durante el análisis del portal Cox Business en 2024, quedaron expuestos una API basada en Spring detrás de /api/cbma/ y documentos Swagger, y se produjo una omisión de verificación de permisos con solo repetir solicitudes
• La API expuesta permitía buscar clientes, consultar PII de cuentas, consultar direcciones MAC de equipos e incluso cambiar configuraciones WiFi; la lógica de generación de encryptedValue también podía invocarse desde el JavaScript del frontend
• Cox retiró la API expuesta en menos de 6 horas tras el reporte, pero este servicio comenzó en 2023, por lo que la causa de la intrusión original al módem en 2021 sigue siendo un caso aparte

---

Reproducción de solicitudes HTTP detectada en la red doméstica

• Para probar una vulnerabilidad blind XXE, se levantó un servidor HTTP en Python en una instancia de AWS y luego se envió una solicitud a /test123 desde una computadora en casa
  • La solicitud original llegó desde la IP doméstica 98.161.24.100
  • Unos 10 segundos después, una IP desconocida 159.65.76.209 volvió a enviar una solicitud a la misma ruta
• Al solicitar la misma URL desde Safari en iPhone, la misma IP volvió a reproducir la solicitud
  • El mismo fenómeno se repetía no solo en la computadora de casa, sino también en otros dispositivos de la red doméstica
• La misma IP reprodujo solicitudes también con una nueva instancia de AWS y Nginx, y con una instancia de GCP, lo que redujo la probabilidad de que fuera un problema propio de AWS
  • Las posibilidades restantes eran una intrusión en el ISP, en el módem o en la ruta de red
• Al consultar el propietario de la IP, 159.65.76.209 resultó ser una dirección de DigitalOcean, no una dirección del ISP

Infraestructura maliciosa previa vinculada con la IP de DigitalOcean

• Una consulta en VirusTotal confirmó dominios que en el pasado resolvían a esa IP
  • De los 5 dominios más recientes, 3 eran sitios de phishing y 2 parecían servidores de correo
  • Dominios de ejemplo:
    • regional.adidas.com.py
    • isglatam.online
    • isglatam.tk
    • mx12.limit742921.tokyo
    • mx12.jingoism44769.xyz
• isglatam.online e isglatam.tk eran sitios de phishing dirigidos contra la empresa sudamericana de ciberseguridad isglatam.com
  • En el sitio real de ISG Latam se confirmó que es una empresa con sede en Paraguay y socia de Crowdstrike, AppGate, Acunetix, DarkTrace y ForcePoint
• En URLscan quedaron rastros de que ambos dominios alojaban un sitio de phishing BeEF típico
  • Registro relacionado: resultado de URLscan
• La misma IP estaba vinculada con un dominio relacionado con Adidas, phishing a ISG Latam y actividades que parecían reproducción de tráfico de módem
  • Aunque existía la posibilidad de que la IP hubiera rotado entre varios propietarios, los intervalos entre actividades eran largos, por lo que no parecía probable que hubiera sido reasignada de inmediato a otro usuario malicioso

Reemplazo del módem y nueva investigación 3 años después

• El equipo en uso era una gateway Cox Panoramic Wifi, y se reemplazó por un módem nuevo en una tienda de Cox
  • Como el equipo anterior era alquilado al ISP, debía devolverse
  • No fue posible realizar un volcado del firmware ni ingeniería inversa
• Tras instalar el módem nuevo, la reproducción de solicitudes HTTP se detuvo por completo
  • Ya no aparecía ninguna otra IP en los logs
  • En ese momento era difícil investigar más allá de concluir que el módem anterior había sido comprometido
• A inicios de 2024, unos 3 años después, al reabrir la investigación con conocidos del sector de seguridad, llamaron la atención formatos de dominio como limit742921.tokyo y jingoism44769.xyz
  • Al hacer búsquedas reverse IP sobre las IP relacionadas, se confirmaron más de 1,000 dominios con el mismo patrón
• Todos los dominios tenían la estructura word + 6 numbers + TLD
  • Por el registro masivo y la estructura algorítmica, parecía un algoritmo de generación de dominios usado por operadores maliciosos para ocultar direcciones de servidores C&C
  • El último dominio observado se registró el 17 de marzo de 2023, y desde entonces ya no había hosts resolviendo
• El módem nuevo de reemplazo era del mismo modelo, pero según búsquedas en Google no se encontraron vulnerabilidades públicas para ese modelo

Hipótesis a partir de herramientas de soporte del ISP y TR-069

• Al mover un módem Cox a una nueva ubicación, se confirmó que un agente de soporte del ISP podía cambiar la configuración del equipo de forma remota
  • El agente de soporte podía actualizar la configuración del equipo, cambiar la contraseña WiFi y revisar los dispositivos conectados
• Esta administración remota se realiza mediante el protocolo TR-069, implementado en 2004
  • Es un método para que el ISP administre equipos dentro de su propia red usando el puerto 7547
  • El protocolo también se trató en una charla de DEF CON, pero no era una superficie expuesta al exterior
• El foco de la investigación pasó del protocolo en sí al sitio web interno de administración de equipos que usan los agentes y a las API detrás de él
  • Si estas API podían consultar o modificar la configuración de los equipos de clientes, o ejecutar comandos, podían convertirse en una vía de intrusión al módem

Estructura de la API del portal Cox Business

• El portal Cox Business ofrece administración remota de equipos, configuración de reglas de firewall y monitoreo de tráfico de red
• Se extrajeron rutas desde el archivo JavaScript del frontend de la página de login, main.36624ed36fb0ff5b.js
  • Se confirmaron más de 100 llamadas a API basadas en /api/cbma/
  • Ejemplos:
    • /api/cbma/voicemail/services/voicemail/inbox/transcribeMessage/
    • /api/cbma/profile/services/profile/userroles/
    • /api/cbma/accountequipment/services/accountequipment/equipments/eligibleRebootDevice
• /api/cbma/ mostraba respuestas distintas a las del frontend general, por lo que parecía un reverse proxy hacia un backend separado
  • Una solicitud a /api/anything_else/example devolvía una redirección 301
  • Una solicitud a /api/cbma/example devolvía 500 Internal Server Error
• La solicitud de registro incluía varios encabezados relacionados con autenticación
  • Clientid: cbmauser
  • Apikey: 5d228662-aaa1-4a18-be1c-fb84db78cf13
  • Cb_session: unauthenticateduser
  • Authorization: Bearer undefined
• Al cambiar el método HTTP, se devolvió una respuesta de error con formato Spring, lo que confirmó que el backend estaba basado en Spring

Documentación Swagger y bypass de recursos estáticos

• No se encontraron rutas de Spring actuator, pero algunas rutas de Swagger UI sí eran accesibles
  • La ruta /api/cbma/userauthorization/swagger-ui/index.html respondía
• La página Swagger cargada inicialmente estaba vacía
  • Los recursos estáticos como .png, .js y .css se enrutaban a la ruta del host original en lugar de al proxy de la API, generando redirecciones infinitas
• Con Burp Intruder, al probar agregando desde %00 hasta %FF al final de la URL, se obtuvo 200 OK al añadir %2f, la / codificada en URL, después de .js
  • Ejemplo: /swagger-initializer.js%2f
• Al usar match-and-replace de Burp para agregar %2f a todos los recursos estáticos, la documentación Swagger cargó correctamente
• En total se confirmaron alrededor de 700 llamadas a API
  • account: 115
  • voiceutilities: 73
  • user: 70
  • datainternetgateway: 57
  • accountequipment: 55
  • billing: 53
  • ticket: 52
  • Otros como profile, voicecallmanagement, voicemail, userauthorization, csr, etc.
• Las API directamente relacionadas con equipos y cuentas de clientes parecían ser principalmente accountequipment, datainternetgateway y account

Omisión de verificación de permisos mediante solicitudes repetidas

• Al revisar si era posible acceder sin autenticación a todos los endpoints GET, algunos devolvían errores de autenticación y otros devolvían 200 OK
• El endpoint profilesearch devolvía inicialmente una respuesta exitosa con resultados de búsqueda vacíos
  • La misma solicitud a veces devolvía Authorization Error-Invalid User Token y, al enviarla de nuevo, tenía éxito
• Al reenviar la misma solicitud varias veces, el error de permisos desaparecía y se devolvían resultados de búsqueda de clientes
  • Una búsqueda de cox devolvía 10000+ hits
  • Una búsqueda de fbi devolvía resultados con direcciones físicas de oficinas de campo del FBI que eran clientes comerciales de Cox
• Solo repitiendo solicitudes a la API era posible una omisión de permisos, y el mismo problema parecía afectar a más de 700 API en general

Acceso a equipos de clientes y consulta de cuentas

• Para verificar si la API de Cox Business también podía acceder a equipos de redes residenciales, se probó una API simple que recibía una dirección MAC
  • Endpoint: /api/cbma/accountequipment/services/accountequipment/ipAddress?macAddress=:mac
• Tras confirmar la dirección MAC desde la propia cuenta Cox y repetir la solicitud, se devolvió la dirección IPv4 del módem propio
  • Se confirmó que esta API podía comunicarse con equipos reales de Cox
• También funcionaba una API de listado de equipos que usa el ID de cuenta
  • Endpoint: /api/cbma/accountequipment/services/accountequipment/v1/equipments/{accountId}
  • La respuesta incluía información de equipos de internet, voz y TV
  • Se devolvían modelo del equipo, tipo de equipo, dirección MAC, lista de puertos y número de serie
• Una API de consulta de usuario basada en email también devolvía información de cuentas comerciales
  • Solicitud de ejemplo: /api/cbma/user/services/user/[e-mail]
  • Incluía email, nombre, teléfono, estado, permisos, si era propietario del perfil y email alternativo
• Una solicitud POST similar para actualizar cuentas también funcionaba, confirmando que era posible leer y escribir en cuentas comerciales

encryptedValue y cambio de configuración de equipos

• Las solicitudes para cambiar configuraciones de hardware requerían un parámetro llamado encryptedValue
  • Ejemplos: cambiar contraseña del equipo, cambiar configuración WiFi
• Se rastreó en el JavaScript del frontend la lógica para generar y descifrar encryptedValue
  • encryptWithSaltandPadding
  • decryptWithSaltandPadding
• Como el PIN de 4 dígitos configurado al registrar una cuenta también se cifraba con la misma función, era posible poner un breakpoint en el punto donde el navegador llamaba a esa función e invocarla directamente desde la consola
• Al descifrar un encryptedValue obtenido de una respuesta real de cuenta, se confirmó un valor con el siguiente formato
  • Número de cuenta Cox
  • Nombre del equipo
  • ID del equipo
  • Valor desconocido
  • Dirección MAC
  • Etiqueta
• Incluso al rellenar con valores arbitrarios la mayoría de los campos, como el número de cuenta, y usar solo una dirección MAC válida para generar un nuevo encryptedValue, la solicitud tenía éxito
  • El servidor no verificaba que el ID de cuenta coincidiera con la dirección MAC

Posibilidad de cambiar la configuración de cualquier módem

• Se envió una solicitud POST contra el equipo propio para cambiar el SSID WiFi a Curry
  • Endpoint: /api/cbma/accountequipment/services/accountequipment/gatewaydevice/wifisettings
  • El cuerpo de la solicitud incluía wifiSettings, additionalProperties y encryptedValue
• La respuesta fue {"message": "Success"} y luego la red se desconectó brevemente y se reinició unos 5 minutos después
  • El SSID cambió efectivamente a Curry
• Este comportamiento demostró que los cambios de configuración de equipos mediante la API se aplicaban a los equipos reales
  • Un atacante podía obtener el UUID de cuenta mediante búsqueda de clientes
  • Consultar las direcciones MAC de los equipos conectados
  • Leer o cambiar la configuración del equipo según la dirección MAC
• Este nivel de permisos equivalía a un acceso similar al del equipo de soporte del ISP, y era una vía que podía afectar a millones de equipos Cox

Alcance del impacto y escenarios de ataque

• La combinación de vulnerabilidades mostró que un atacante externo, sin condiciones previas, podía hacer lo siguiente
  • Ejecutar comandos y cambiar configuraciones en millones de módems
  • Acceder a PII de clientes de Cox Business
  • Obtener permisos similares a los del equipo de soporte del ISP
• Cox es el proveedor privado de banda ancha más grande de Estados Unidos, el tercer proveedor de TV por cable más grande y el séptimo operador telefónico más grande, además de ser el ISP más popular en 10 estados
• Flujo de ataque de ejemplo:
  • Buscar objetivos de Cox Business por nombre, teléfono, email o número de cuenta
  • Usar el UUID devuelto para consultar toda la PII de la cuenta, direcciones MAC de equipos, emails, teléfonos y direcciones
  • Usar la dirección MAC del hardware para consultar la contraseña WiFi y los dispositivos conectados
  • Ejecutar comandos arbitrarios, cambiar propiedades del equipo y secuestrar la cuenta de la víctima
• Una parte importante de las más de 700 API expuestas ofrecía funciones de administrador, y al repetir solicitudes se producía el mismo problema de permisos

Reporte a Cox y corrección

• La vulnerabilidad fue reportada mediante el responsible disclosure program de Cox
• Cox retiró las llamadas a la API expuesta en menos de 6 horas tras el reporte y comenzó a trabajar en la corrección de la vulnerabilidad de permisos
  • Al día siguiente ya no era posible reproducir la vulnerabilidad
• Cronograma público:
  • 2024-03-04: reporte de la vulnerabilidad a Cox
  • 2024-03-05: aplicación de hotpatch; endpoints comerciales no esenciales comenzaron a devolver 403 y dejaron de funcionar
  • 2024-03-06: se informó por email a Cox que la vulnerabilidad ya no podía reproducirse
  • 2024-03-07: Cox respondió que iniciaría una revisión de seguridad integral
  • 2024-04-10: se informó a Cox la intención de publicar tras 90 días desde el reporte
  • 2024-04-29: se compartió con Cox el enlace al borrador del blog

Dudas pendientes

• Cox investigó si la ruta de vulnerabilidad específica había sido explotada en el pasado y confirmó que no había historial de explotación
  • El servicio comenzó a operar en 2023
  • Como la intrusión original al módem ocurrió en 2021, la vulnerabilidad pública de la API de Cox Business no fue la causa de aquella intrusión
• Cox informó que no tenía ninguna relación con la IP de DigitalOcean
  • El equipo sí fue hackeado realmente, pero mediante un método distinto a la vulnerabilidad pública de la API
• El módem no estaba configurado para permitir acceso externo y nunca se había iniciado sesión en el equipo desde la red doméstica
  • Entre otras posibles vías se mencionó algo como un 0day que llevara de CSRF local a RCE
• La mayor duda es por qué el atacante reprodujo las solicitudes HTTP
  • Si ya estaba dentro de la red, podía acceder sin ser detectado, pero no se confirmó por qué reprodujo todas las solicitudes HTTP

[GN⁺]

Opiniones en Hacker News

• Buen artículo y fácil de seguir. En particular, me gustó que Cox no atacara a quien reportó el problema ni lo negara, sino que actuara como un ejemplo de respuesta de seguridad responsable, que es lo que uno esperaría en una situación así.
  Me gustaría ver una publicación de seguimiento sobre cuál fue el bug que permitía de forma intermitente el acceso no autorizado a la API. Este tipo de errores puede pasarse por alto fácilmente con pruebas superficiales o, según la causa, quizá ni siquiera reproducirse en un entorno de pruebas.

  • Es cierto que Cox respondió de forma responsable, pero me habría gustado que aprovecharan mejor la oportunidad cuando al principio alguien llegó con un equipo infectado en la mano.
    Hace tiempo descubrí por casualidad una vulnerabilidad grave en una telco tradicional, y solo con los canales normales de soporte al cliente me tomó casi una semana llegar a la persona adecuada; la organización de soporte no pudo escalar el caso en absoluto. En el caso de Cox también, un profesional de infosec llegó personalmente con un equipo infectado, pero la organización de soporte no supo manejarlo bien.
  • El artículo también fue fácil de leer y la respuesta de Cox fue buena. También me gustó que el proceso de descubrimiento y el bug en sí no se presentaran de forma negativa ni condescendiente.
  • Las empresas deberían recompensar a quienes encuentran estas cosas, no demandarlos por “hackear”.
  • A mí también me da curiosidad cuál fue el bug que permitía de forma intermitente el acceso no autorizado a la API. Quizá nunca lo sepamos, pero podría haber sido un backend de pruebas sin verificaciones de autorización incluido por error en la configuración del load balancer.
  • El artículo estuvo bueno, pero me molestó un poco que usaran super todo el tiempo, como “super curious”, “super interesting” y “super interested”.

• Lo molesto en estas situaciones es cuando el ISP te obliga a usar su módem o router. Por ejemplo, AT&T fiber usa autenticación 802.1X basada en certificados para acceder a la red; sin eso, se podría conectar cualquier equipo al ONT.
  Hay o hubo métodos para saltárselo, pero no quiero pasar por todo ese proceso solo para usar internet, así que desactivo todas las funciones del router de AT&T y conecto detrás mi propio router, que mantengo actualizado. Si hackean el router de AT&T, quizá no me dé cuenta hasta que el servicio se vea afectado. Menos mal que hoy casi todo usa HTTPS.

  • Si es AT&T fiber con el ONT separado del módem, saltarse 802.1X es bastante fácil. Basta con poner un switch no administrado entre el módem y el ONT, dejar que el módem se autentique y luego desconectar el módem.
    Si el ONT se reinicia, probablemente haya que hacerlo de nuevo, pero en mi caso AT&T me dio un UPS para el ONT, así que debería reiniciarse con poca frecuencia. Personalmente armé una configuración compleja basada en una NIC de bypass: cuando el firewall está apagado o reiniciándose, el tráfico pasa por el módem de AT&T; cuando está encendido, mi firewall recibe el tráfico y lo reenvía selectivamente a través del módem. Pero, en realidad, con un switch no administrado alcanza.
  • La posibilidad de que hackeen el router CPE de AT&T no cambia mucho si entre mi red y la red de AT&T está mi router. Incluso si eliminas el router CPE de AT&T, al final sigues conectado a una caja negra que no controlas, y ese equipo también podría estar hackeado o inspeccionar el tráfico de varias formas.
  • Por suerte, Cox no es ese tipo de ISP. Aceptan cualquier módem DOCSIS lo suficientemente moderno para la velocidad contratada.
    Pero hasta ahí llegan mis elogios a Cox. Llevo dos años sufriendo pérdida intermitente de paquetes, y aunque recopile datos que indican que cierto nodo probablemente está sobresuscrito, no parece haber una ruta de escalamiento de soporte para llegar a alguien que lo entienda.
  • Como referencia, en xgspon el procedimiento de bypass ya está automatizado. Es algo como “conectar el SFP+, subir el firmware desde la interfaz web, ingresar el número de serie del equipo”; y, según el módulo SFP que uses, incluso se puede omitir el paso 2.
    En la práctica, el estado de 802.1X no se valida del lado del servidor. El estándar dice que, si se requiere 802.1X y no se realiza, el módem no debería reenviar tráfico, pero la mayoría simplemente lo reenvía o puede modificarse para que lo haga. Del lado de AT&T no lo verifican y siempre dejan pasar el tráfico; internamente, eso es lo que está ocurriendo.
  • Hay formas de conectarse sin el gateway de AT&T, y varios métodos están recopilados en https://pon.wiki/.

• Es un artículo muy legible y la investigación es excelente. También está bueno ver un caso en el que una gran empresa no le tira una bomba nuclear al investigador de seguridad.
  No estoy seguro, pero sospecho que las solicitudes a la interfaz local de administración de este router Nokia no se autentican correctamente. Hace poco me dieron el mismo equipo, y había configuraciones que no se podían cambiar con privilegios de administrador normal; el ISP no me dio una cuenta de superadministrador. Pero si con el inspector de la página volvía a habilitar los campos desactivados y cambiaba los valores, la API los aceptaba sin más. En ese estado, si una aplicación pudiera ejecutarse dentro de la red interna, no sería difícil tomar control del router de esa forma, aunque parece requerir condiciones bastante específicas.

  • El hecho de que Cox sea el mayor proveedor privado de banda ancha de EE. UU., el tercer proveedor de TV por cable, el séptimo operador telefónico y el ISP más popular en 10 estados me hace pensar que los ISP no deberían ser tan grandes.
    Cox es claramente un objetivo atractivo, y como muestra el ejemplo del artículo, una sola vulnerabilidad podría poner en riesgo incluso una oficina de campo del FBI. Creo que habría sido más correcto escribir “Cox afirmó haber investigado usos maliciosos anteriores” en lugar de “Cox investigó usos maliciosos anteriores y no encontró registros”.

• ¿Se puede confiar en la afirmación de que “no hubo historial de explotación previa”? Toda la red parece estar llena de agujeros como queso suizo.

  • Por eso envías todos los logs a un bucket de S3 en una cuenta de AWS con permisos solo de escritura, y haces que se necesiten tres personas para entrar a la cuenta que puede realizar otras acciones sobre ese bucket. No sé si Cox hizo eso, pero si diseñas el sistema para poder decir “no hay historial de explotación”, esa sería la arquitectura.
  • Si fuiste quien inició la conversación, no puedes quedarte fuera hasta el final. En algún momento tienes que decir: “Esta es la información que tenemos, y es mejor que antes”.
  • Si dicen “no hay”, eso podría significar que, dado que ya se encontraron equipos infectados, existen otras rutas de ataque que Cox podría conocer o no.

• Muchos routers requieren actualizar el firmware manualmente. Los routers GL.iNet tuvieron varias vulnerabilidades de ejecución remota de código en los últimos 6 meses, así que conviene revisar rápido que tu router no haya sido hackeado y, si es posible, actualizar el firmware.
  Desde el punto de vista de un usuario común, los síntomas visibles fueron una caída en la velocidad de Internet, cortes de la señal Wi‑Fi y fallas al conectar dispositivos, y que el propio router estaba conectado a Internet pero la página interna de administración (192.168.8.1) no respondía. En mi caso, el atacante instaló la app Pawns de IPRoyal para convertir el router en un servidor proxy y ganar dinero; también robó registros del sistema con el tiempo de uso y si había conexión al NAS, y tenía una shell inversa. Lo mejor para resolverlo es, en este orden: actualizar el firmware, restablecer el router para eliminar el malware, desactivar SSH y apagar accesos remotos como DNS dinámico. Si se necesita acceso remoto, se pueden evaluar opciones como Cloudflare Tunnel, Zero Trust, GoodCloud, ZeroTier o Tailscale, aunque no sé bien cuál sería la más adecuada. GL.iNet no sigue el principio de mínimo privilegio y, por defecto, ejecuta procesos como root; además, SSH viene activado por defecto con acceso root, así que parece mejor evitarlo.

• Que “no hubiera historial de abuso” podría deberse a que desde el principio no había suficientes logs o materiales de auditoría, o a que después del hackeo no quedaron logs.

  • Por lo que vi en el artículo, una ruta de ataque concreta de “reintentar solicitudes no autorizadas hasta que pasen” se ve muy fácilmente en los logs. Bastaría con una política básica de logging que registre ruta, IP y código de estado, algo cercano a los valores por defecto de la mayoría de servidores web y frameworks.
  • Aquí aplica eso de “la ausencia de evidencia no es evidencia de ausencia”.
  • O quizá mintieron. Si uno lo piensa desde la posición de Cox, ¿por qué le revelarían a alguien externo que hubo abuso en el pasado? En realidad, no tienen motivo para revelar nada.

• ¿Qué sistema de autenticación deja pasar llamadas al azar de vez en cuando? Parece realmente incompetente.

  • Una vez encontré algo así en una API de un proveedor. Habían registrado el proveedor de usuario actual como singleton en vez de por solicitud, así que a veces podías colarte detrás de un usuario autenticado.
  • Vi un bug grande parecido. La API rechazaba solicitudes no autenticadas durante exactamente 10 minutos, luego las permitía durante exactamente 1 minuto, y el ciclo se repetía indefinidamente. Me da muchísima curiosidad qué estaba pasando en el backend.
  • Según mi experiencia, esto puede pasar por culpa de un balanceador de carga. Por ejemplo, si no enruta correctamente a los servidores del pool, o si entre servidores hay diferencias de configuración o de nivel de parches.
  • También podría ser que algunos de los servidores de origen a los que se enrutan las solicitudes estuvieran mal configurados.
  • Si la API estaba detrás de un proxy inverso, también pudo haber sido un problema de caché.

• ¿Le pagaron? Esta persona básicamente salvó a Cox y les avisó de una toma total de la infraestructura de seguridad que ni siquiera era fácil de descubrir.
  Parece que no recibió nada a cambio de “hacer lo correcto”, y eso es bastante insultante. La forma en que la empresa habrá visto a alguien que llegó a sus oficinas con información importante seguramente fue muy distinta a cómo él se percibía a sí mismo. Casos como este muestran muy bien por qué nunca se debería reportar un 0day.

  • Tratándose de Cox, quizá ya tiene suerte con que no demanden a la persona que les corrigió el error.
  • Sam es un investigador de seguridad muy conocido, así que no me sorprendería que ganara más de 350 mil dólares al año. Este tipo de publicaciones se convierten en bastante dinero mediante el aumento de reputación.
  • Cox no paga bug bounties.

• Una pregunta que sigue abierta es cómo los atacantes capturaron su tráfico HTTP.
  Algunos CPE tienen una función de depuración parecida a un Wireshark en la nube. No sé si las imágenes de firmware de producción de Cox incluyen algo así. Normalmente hay firmware de producción y firmware de pruebas por separado, lo que hace más difícil probar problemas del entorno de producción. Cox debería poder verificar qué versiones de firmware hay en campo; un ISP puede actualizar automáticamente firmware que no coincide con una versión específica, y como es un módem de Cox, es muy probable que también tengan el firmware. Si era firmware de depuración, me da curiosidad cómo se instaló y cómo siguió ahí.

  • En Linux, si creas un socket con PF_PACKET, puedes interceptar el tráfico de todas las interfaces. Es como un tcpdump de bajo nivel.
    Sería fácil interceptar todos los datos del puerto 80, parsear los encabezados HTTP y hacer lo necesario. Aunque no tengo claro por qué alguien reproduciría las solicitudes.
  • Si es HTTP y no HTTPS, cualquier persona o equipo en la ruta puede ver las solicitudes.
  • Otra razón más para no confiar en equipos provistos por el ISP ni usarlos. Administración remota del ISP: no, gracias.

• Es una de las razones por las que no deberíamos recibir con entusiasmo los módems de cable provistos por el ISP con Wi‑Fi integrado, y por las que hay que asegurar bien los endpoints y servicios dentro de la LAN. Como mínimo, se necesita TLS y DNS over TLS en el tramo módem/ISP.
  Yo simplemente lo dejo en modo bridge, apago el Wi‑Fi y hago que todo el funcionamiento de red quede a cargo de mi propio equipo. El último módem alquilado al ISP que tuve no recibió actualizaciones de firmware durante casi 10 años, aunque gracias a eso fue muy estable.

  • También hay un contraargumento. Un ISP con más de un millón de clientes tiene incentivos para actualizar los gateways domésticos “para siempre” con el fin de reducir costos de inversión en infraestructura.
    Free, donde trabajo, es un ISP francés y también ofrece gateways domésticos en Italia a través de Iliad; incluso seguimos actualizando equipos lanzados en 2011. Corren Linux 6.4 reciente y ofrecen funciones modernas como airtime QoS, actualizaciones de la app móvil y varias funciones de software.
  • Los routers son los dispositivos IoT más explotados del planeta, y muchas veces las vulnerabilidades de firmware permanecen durante años porque los usuarios finales no los parchean. Si el ISP puede empujar parches al router y retirar equipos que no se pueden parchear, incluyendo el hecho de que la propiedad sea del ISP, es una ganancia neta para la ciberseguridad.
  • Yo también lo dejo en modo bridge y con el Wi‑Fi apagado. Por casualidad logré que me instalaran un módem simple, sin funciones de router ni punto de acceso; no sabía que todavía existieran equipos de propósito único así.
    Compré un router relativamente decente, instalé OpenWrt y lo conecté a la red en bridge a través del equipo del ISP, y funciona bien. Ahora uso HTTPS incluso dentro de la LAN.
  • Le dije al ISP que, si no me dejaban usar mi propio router, me cambiaría a otro ISP.