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 ONONo 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ó todoPero 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.
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 RiesgosEl 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 problemaLa 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...
