ONO: La insegura estructura de la red de clientes

Por eso de que como a muchos de vosotros me preocupa mi seguridad, desde hace tiempo vengo estudiando las distintas redes de operadores de internet (ISP) nacionales, así como sus dispositivos, y estructuras de conexión de las que soy usuario. No tardé en empezar a darme cuenta de las flaquezas en dichos sistemas y fue por ello que he empezado a escribir distintos artículos sobre diversas vulnerabilidades encontradas en aquellos que me ofrecen servicio de manera insegura, ya sea por hacerlo con sistemas que tienen vulnerabilidades conocidas o por una mala arquitectura de las redes. Tal vez así nos lleguen a brindar un servicio de mayor calidad y con unas mínimas garantías de calidad y seguridad.

El primer artículo trató sobre algunos proveedores, sobre todo de la costa azul, que ofrecen sus servicios mediante enlaces inalámbricos sobre banda licenciada en 2.4 o 5 Ghz. Le pedí al gran Chema Alonso, del que soy fiel seguidor, que debido a mi poco poder mediático a ver si podía hacerme un hueco en su blog, pues después de contactar con distintos operadores para que lo solucionasen - y tras varios meses  - nadie había puesto solución a ello. Él accedió, y gracias a eso muchos de esos proveedores rectificaron sus políticas en este aspecto, aunque he decir que todavía a día de hoy muchos que no lo han solucionado. Recomiendo a los responsables de la AGPD (Agencia de Protección de Datos) y a los del CMT (Comisión del Mercado de las Telecomunicaciones en España) echar un ojo a dicho artículo:

- AirOS vulnerables: ISPs sin actualizar en España

Hoy quiero hablar de otro operador bien conocido, nuestro querido ONO. Desde hace unos 9 años soy cliente de dicho operador, aunque he de confesar que también estuve unos 3 años con servicios gratuitos gracias a nuestras queridas direcciones MAC y un modem con Sigma que modifiqué hace unos cuantos años y que todavía tengo. Eso sí, esto era cuando con 17 años no tenía ni un duro y mis padres solo tenían la TV pública :-).

Fallos conocidos de la red de ONO

No voy a explicar cómo está estructurada una red HFC como la de ONO o qué equipos CMTS usan, pues para eso os remito a la Wikipedia para que comprendáis un poco el funcionamiento de dichas redes si te faltase algún conocimiento para entender bien el proceso del artículo - que también tiene que ver con el funcionamiento de Ethernet.

Desde hace ya mucho tiempo es conocido que es posible escanear direcciones MAC de los clientes que se encuentran bajo el mismo nodo con cualquier aplicación como nmap, hping, etc... sólo poniendo el router en modo “bridge” o mediante algún otro dispositivo como Mikrotik o lo que sea. Con este último yo he realizado esta prueba consiguiendo no solo ver las direcciones MAC de equipos en mi mismo rango de direcciones IP sino de otros rangos cercanos, y esto nos da una pequeña idea ya de cómo puede estar implementada la red.

Otro punto de ineficacia son los modems que montan. Muchos de sus modems son accesibles por defecto por SSH o Telnet con las contraseñas también por defecto a través de la dirección IP pública, cuando debería estar limitado a la dirección IP privada. En una auditoria de seguridad que realicé a una empresa de mi amada ciudad “León”, donde más o menos tenían un nivel bueno de protección bajo las pruebas que realizamos, al final se encontraron con todo su tráfico redirigido a nuestra web corporativa a través de un ataque contra los DNS gracias a las configuraciones de ONO, lo que nos hizo ganarnos varias medallas por la auditoría.

Figura 1: Accediendo a un modem ONO con usuario y password por defecto

El suceso que motivó todo

Pero lo último ha sido mucho más divertido. Resulta que probando un software de VoIP (3CX), me dispuse a montar montar un dominio completo bajo Windows Server 2008 R2. Cuando tenía el dominio montado me puse a configurar un servidor DHCP para la telefonía, porque quería probar el aprovisionamiento automático de los teléfonos en dicho software, y en cuanto levante el servicio “flipé en colores”. Resulta que un equipo me había solicitado un dirección IP y yo no tenía conectado nada todavía al switch. Lo primero que pensé fue que algún espabilado me había trincado la WiFi de pruebas, pero ¿cómo me iban a romper algo del tipo WPA2-AES “ocke9u3iafa0c4bio84@@@2ompd”? Tenía que haber otra explicación.

Figura 2: El cliente que se coló en el servidor DHCP

Para resolver el misterio me puse con Wireshark a ver que estaba pasando por mi laboratorio, y pude ver un montón de paquetes de tipo IGMP, solicitudes DHCP, etcétera de redes que no eran la mía. El culpable era el modem, que por algún motivo no filtraba o bloqueaba el tráfico broadcast y algún otro, que venía del puerto “WAN” - por llamarlo de alguna forma para que nos entendamos-.

Figura 3: Tráfico no esperado de IGMP en Wireshark

¿Qué estaba pasando realmente?

Lo primero que hice fue lanzar un escaneo a éste equipo tan gracioso que había atravesado mi modem robándome una dirección IP, y todos los puertos aperecían filtrados o cerrados, menos el puerto 80. En cuando lo puse en mi navegador ¡Sorpresa!: Un portal de configuración para un Hitron CDE-30386.

Figura 4: El portal de administración de Hitron

El tema estaba en que para mi red interna, justo detrás del modem, me puse el rango de direcciones IP 10.10.X.0/24 sin servidor DHCP, y resulta que este rango lo emplea ONO en alguna subred desde algún CMTS para entregar el archivo de configuración vía TFTP, enrutar el tráfico de los modems de ese rango, etcétera. Por explicarlo fácilmente, es una subred de ONO que permite la gestión y administración de los modems, y que es "supuetamente" transparente para los clientes.

¿Y si se escanea todo el un rango como 10.0.0.0/8?

Pues a eso me fui, y ¡madre mía!. Resulta que podía llegar a miles de routers de clientes dispersos por toda España. Si entraba en cualquiera de ellos y miraba su dirección IP pública, y luego intentaba entrar a través de ella, el modem no me dejaba. Tras analizar este comportamiento llegué a la conclusión de que es un subred de ONO que se utiliza para gestión y soporte, y todos los modems vienen preparados para permitir el acceso desde esa red sin ninguna restricción al puerto 80. Además, después de haber creado un pequeño programa en Java que me analizó todos los modems que encontré en 10.0.0.0/8, un 90% de ellos tenían la password por defecto.

Esta es gordísima...

Resulta que analizando las direcciones IP públicas de los modems y haciendo un whois, podía ubicar donde estaba aproximadamente ese router, y así elaborar una lista de cada una de la subredes encontradas en el rango 10.0.0.0/8 y colocarlas en una ciudad o zona. Algo que sería muy útil en un pentest. Pues así fue, después de analizar los distintos modems que usa ONO para poder extraer de las peticiones “Http” la dirección IP pública y asociarlo a la subred en cuestión. He podido elaborar un pequeño mapa de ciudades y subredes.

Figura 5: Whois con posicionamiento GPS

Probando ya la efectividad de la idea, me dispuse a realizar un auditoria bajo demanda de una empresa, de la que sólo diré que trabaja con temas financieros. Y vaya si me funcionó. En esta ocasión configuré el modem temporalmente con una DMZ apuntando a un Windows Server 2003 que actúa como Domain Controller, y realizando un escaneo contra la dirección IP externa fue coser y cantar ver la falta de actualizaciones y jugar con él.

Posibilidades y Riesgos

El daño que se puede causar es muy alto. Por ejemplo desde ataques ARP-Spoofing, MITM, etc... contra la propia red de ONO, o incluso montar un servidor TFTP y suplantar los archivos de configuración. Podríamos perfectamente entregar direcciones IP a clientes de “Talavera de la Reina”, tal y como se muestra en la foto, montar un servidor DNS y hacer...bueno, todo lo que se puede hacer con un Rogue DNS.

Otra cosa que pruebo a veces en las auditorias que hacemos, es mandar un email con una imagen alojada en un servidor, y ver si la dirección IP desde la que me solicitan esa imagen cuando abren el correo coincide con una de ONO. Si es así compruebo de dónde viene esa dirección IP pública y busco la subred que corresponda para ver si doy con el modem que la tiene asignada.

Solución al problema

La verdad es que el fallo es tan evidente, y tan fácil de descubrir, que el número de personas que puede conocer esto es altísimo. Preocupado por ello, he llamado a ONO e incluso he ido a una de sus oficinas, desde hace ya unos cuantos meses en varias ocasiones. Me pasa lo mismo que la otra vez cuando publiqué el artículo de AirOS, y es que cuando intento que alguien lo solucione me tachan, a mi parecer, de loco, así que he optado por volver a publicarlo, a ver si se arregla. La solución no es muy compleja, ya que existen los Firewall y no es tan complicado configurarlos correctamente para que de verdad se filtren bien las conexiones.

Figura 6: Modelo de cable modem

Mientras espero que ONO resuelva esto, estoy trabajando en un programa en Java - para demostrar el impacto que puede tener este fallo - que recoja direcciones MAC, direcciones IP, direcciones IP públicas, módelos de modem, etcétera... sobre los rangos 192.0.0.0/8, 172.0.0.0/8 y 10.0.0.0/8. Aunque soy algo novato programando y me llevará unos cuantos días pulirlo - a no ser que alguien se preste a echarme una mano a cambio de una cecina y un chorizo rico rico de mi tierra) >:-) -. Para el que quiera el rico embutido...

Gracias a todos.

Autor:
Gerard Norton
gerardnorton@hotmail.com