Hackeo de millones de módems e investigación de quién hackeó mi módem

• Hace 2 años, mientras hacía pruebas de vulnerabilidades en casa, experimenté algo extraño
• Levanté un servidor HTTP en una instancia de AWS para descargar un archivo desde un servidor vulnerable
• Todo parecía estar bien configurado, pero justo cuando intenté volver a la prueba de vulnerabilidad, apareció un registro inesperado
• Alguien interceptó y volvió a enviar la misma solicitud HTTP 10 segundos después entre mi red doméstica y la instancia de AWS
• Ese tráfico no debería haber sido accesible y no debería haber existido ningún intermediario
• Mi pensamiento inmediato fue que mi computadora había sido hackeada y que un atacante estaba monitoreando activamente el tráfico
• Verifiqué si ocurría lo mismo en el iPhone, y una dirección IP desconocida interceptó y reenvió tanto las solicitudes HTTP de la computadora como las del iPhone
• Parecía muy probable que uno de estos hubiera sido comprometido: el ISP, el módem o AWS
• Para descartar la idea absurda de que AWS había sido hackeado, levanté una instancia en GCP y ocurrió lo mismo
• La única posibilidad era que el módem hubiera sido hackeado, pero ¿quién era el atacante? Al consultar al propietario de la IP, resultó pertenecer a DigitalOcean
• Esa IP había sido usada en los últimos años para varios sitios de phishing y servidores de correo
• Como el dispositivo comprometido seguía funcionando, lo desconecté y lo guardé en una caja
• Fui a una tienda de Cox, devolví el módem comprometido y recibí uno nuevo
• Después de instalar el nuevo módem, el comportamiento extraño se detuvo, pero no supe exactamente cómo había sido comprometido
• Tres años después, durante unas vacaciones con amigos expertos en seguridad, terminé contando este incidente, y les interesó empezar a investigarlo
• Al revisar los dominios registrados por la dirección IP, encontraron una gran cantidad de dominios generados algorítmicamente, lo que sugería un servidor de C&C
• El atacante realizaba varias actividades maliciosas desde la misma IP, pero no fue suspendido en 3 años. Era difícil entender su intención
• Como el nuevo módem era del mismo modelo, también consideraron la posibilidad de que el atacante lo hubiera vuelto a comprometer
• Prestaron atención al protocolo TR-069, mediante el cual el ISP puede administrar los dispositivos. Si se ataca la infraestructura de herramientas de soporte, sería posible tomar control del módem
• Analizando el JavaScript del portal empresarial de Cox, descubrieron más de 700 rutas de API. Entre ellas, las API con más funciones de acceso a equipos y cuentas de clientes eran accountequipment, datainternetgateway y account
• Encontraron una vulnerabilidad que permitía eludir la autenticación. Repitiendo solicitudes HTTP, era posible ejecutar comandos sin autorización
• Confirmaron que podían comunicarse directamente con el equipo de cualquier persona mediante la dirección MAC. Cox da servicio a millones de clientes
• Demostraron que podían sobrescribir la configuración del equipo, acceder al router y ejecutar comandos en el dispositivo, obteniendo privilegios similares a los del equipo técnico de soporte del ISP
• Esta vulnerabilidad permitía, sin condiciones previas, modificar la configuración de millones de módems, acceder a la PII de clientes y obtener privilegios al nivel del equipo de soporte del ISP
• El escenario del incidente era el siguiente
  1. Buscar clientes empresariales de Cox mediante la API
  2. Obtener la PII del cliente, como dirección MAC del equipo, correo electrónico, número de teléfono y dirección, usando el UUID
  3. Consultar la contraseña de Wi‑Fi y los dispositivos conectados usando la dirección MAC
  4. Ejecutar comandos arbitrarios, cambiar propiedades del equipo y secuestrar cuentas
• Reportaron la vulnerabilidad a Cox, y en 6 horas bloquearon la API y empezaron a corregir el problema de autenticación
• De las más de 700 API expuestas, muchas ofrecían funciones administrativas y todas tenían el mismo problema de permisos
• Este caso muestra la debilidad de la capa de confianza entre los ISP y los equipos de los clientes
• Todavía me intriga exactamente cómo fue hackeado mi módem. Tampoco entiendo por qué el atacante reenviaba el tráfico
• Se agradecen teorías u opiniones

Opinión de GN⁺

• Vulnerabilidad de seguridad: Este artículo muestra cuán grave puede ser el impacto de una vulnerabilidad de seguridad en un ISP. En particular, la capacidad de cambiar remotamente la configuración de los dispositivos puede ser explotada.
• Seguridad de API: Destaca la importancia de la seguridad de las API. Las vulnerabilidades como la evasión de autenticación pueden provocar problemas de seguridad graves.
• Protección de datos de usuarios: Advierte sobre el riesgo de que la información personal de los clientes y la configuración de sus dispositivos queden expuestas con facilidad. Los ISP deben adoptar medidas de seguridad más sólidas para proteger estos datos.
• Comprensión técnica: Al explicar los detalles técnicos de forma que incluso un ingeniero de software junior pueda entenderlos, ayuda a aprender cómo detectar y resolver vulnerabilidades de seguridad.
• Propuesta de alternativas: Para resolver problemas como este, es importante usar equipos de red y protocolos de seguridad más seguros. También se pueden considerar otros ISP u otras soluciones de seguridad.

[GN⁺]

Comentarios de Hacker News

• Me impresionó que Cox respondiera de forma responsable, sin negar el problema ni atacar al mensajero. Me gustaría leer un artículo de seguimiento sobre cuál era el bug.
• Es incómodo cuando un ISP obliga a usar su propio módem o router. Mi router de AT&T podría ser hackeado, pero por suerte existe HTTPS.
• Fue un excelente artículo y una gran investigación. Parece que la interfaz local de administrador del router de Nokia no se autentica correctamente. No podía cambiar cierta configuración, pero pude alterar la página para modificarla.
• Muchos routers requieren actualizaciones manuales de firmware. Los routers de GL.iNet tuvieron recientemente una vulnerabilidad de RCE. Se recomienda actualizar el firmware y tomar medidas como desactivar el acceso por SSH.
• Sigo teniendo dudas sobre cómo el atacante interceptó el tráfico HTTP. Cox debería poder verificar la versión del firmware y resolver el problema mediante una actualización automática.
• Cox afirma que esta vulnerabilidad no se había explotado antes, pero cuesta creerlo. La red parece muy descuidada.
• Es impactante que se haya encontrado una vulnerabilidad tan grande en una gran empresa tecnológica. El artículo es excelente, pero esta vulnerabilidad es imperdonable.
• Me pregunto si hubo alguna recompensa para la persona que reportó la vulnerabilidad. Hizo una gran contribución, pero parece que no recibió nada. Eso es muy insultante.
• La razón por la que Cox afirma que no hubo explotación previa probablemente sea la falta de logs o de datos de auditoría.
• El contenido del artículo es excelente, pero un atacante decidido podría hacerse pasar por un técnico de Cox para obtener acceso. Los ISP deberían implementar una configuración que desactive el acceso remoto de forma predeterminada.