ASKEY R3505VW n55 (Changelog y un pequeño análisis)

Highlighted
ASKEY R3505VW n55 (Changelog y un pequeño análisis)

Sé que la firmware n55 para nuestro ASKEY lleva algún tiempo ya rodando, pero por ausencia y tiempo no había podido meterle mano. Realmente no sé si está ya en distribución general, o como pasó con la n53 ha empezado de forma progresiva y lentamente.

 

En cualquier caso, y como he hecho en otras ocasiones, un pequeño análisis (no oficial) de los cambios de esta versión FRENTE a la n53, la anterior. Y como siempre, recordar que algunos datos pueden no ser completamente correctos y existir algunos otros cambios que no he cazado, aun no he terminado de analizarlo todo.

 

CHANGELOG n53 -> n55
(Router: 3.4.11-rt19+. Compilación Jun 12 18:15:51 CST 2019)
(Qntena: 2.6.35.12. Compilación Mar 11 15:41:48 CST 2019)

 

Cambios Internos:


-La Shell limitada sigue más o menos igual, sin grandes cambios. Oficialmente, solo se puede saltar de Shell con telefonica:telefonica, siempre que el acceso sea desde WAN y habilitando un flag en la configuración del Router

-Cambio en la encriptación del archivo de configuración (Ver Análisis)

   -Usa el número de serie (ASKYXXXXXXXX) de la ONT, único para cada unidad.

-Añadido Avahi (mDNS), no parece que se esté usando aun, si lo es, sería solo para SHGW

-Remodelación importante en SHGW (Security Home GateWay) aka "conexión segura" y gestión por la App

   -Añadido libevent y fnetlink_log para registrar/loggear tráfico de red

   -Configuraciones y datos de SHGW pasan a cifrarse con sqlcipher en vez de sqlite3

   -Aun investigando... en mi unidad tengo deshabilitado totalmente SHGW

-Fix para compatibilidad con las OLT Huawei 5800 (Ver Análisis)

-Timeout de deautentificacion 20seg, fix para algunos dispositivos WIFI

-Ajustes en la configuración interna de Roaming (SONIQ)

-Actualización 1º y 2º fase Bootloader (u-boot y cferam)
-Actualización del Kernel y de la imagen del quantenna

-Actualización de la mayoría de binarios/librerías/módulos

-Se impide el uso del SSID "Quantenna", se usa para SONIQ y los repetidores de Movistar

-¿Se soluciona (por fin) el acceso a las DNS de Cloudflare (1.1.1.1)?

-Quantenna: Añadida tabla de potencia para Colombia (Ver Análisis)

-Quantenna: Acceso Telnet/Web posible sólo modificando el Firewall que bloquea el acceso a la IP 1.1.1.2 donde se levanta el servicio.

---------

 

Cambios Interfaz Web:

 

-Numerosas correcciones menores en las interfaces Web, sobre todo en la de Movistar (simple)

-Se impide ocultar el SSID si está asociado a un repetidor

 

-------------------------------------------------------------

 

Análisis

 

En pocas palabras: Esperaba bastante más después de más de un año.

 

 

Sin volver atrás

En comparación con la versión anterior, no nos trae grandes novedades (para bien y para mal), quitando uno o dos fixes que más de uno se alegrará. Realmente el aspecto más negativo de esta nueva versión no es que hayan añadido muchas nuevas restricciones o cambios que puedan ser negativos para el usuario, sino más bien que no han dado marcha atrás en los aspectos más lesivos que nos trajo la fatídica n53.

 

Por un lado, seguimos encontrándonos el mismo capado de opciones dentro de la configuración avanzada, la cual prácticamente no se ha tocado. Se sigue apostando por el Roaming y el Band Steering por defecto, y aunque es verdad que han refinado aspectos de estos, sigue el mayor problema: Que por defecto se habilita. Esto podrían solucionarlo en cuanto quisiesen, simplemente modificando desde la central la plantilla de configuración por defecto que se carga al cliente, sin tocar la firmware.

 

Encriptación del archivo de configuración

Quitando aquello que no se ha revertido, el nuevo tirón de oreja va en el empecinamiento de querer complicar las cosas al usuario. Como todos sabemos, originariamente el archivo de configuración que se guardaba podía modificarse y teníamos al menos un lugar donde configurar a mano nuestro equipo. Desde la n43 se comenzó a cifrar, aunque desde el primer día expuse y enseñé como desencriptarlo. En esta ocasión han cambiado el sistema de abordarlo, y en vez de usar una key genérica, esta es extraída de un dato estático y único de cada Router: En este caso es el número de serie de cada ONT integrada (no confundir con el SN del Router).

 

Desde un punto de vista de la seguridad, coincido totalmente en usar una key única asociada de algún modo al dispositivo, en este caso por ejemplo el SN de la ONT. De lo contrario un cifrado pierde su utilidad si todas las unidades usan la misma clave... lo mismo pasaba originariamente con las contraseñas por defecto. El problema es que el usuario base no va a tener opción tampoco de conocer ese SN si no es accediendo de forma "ilícita". Además esto tiene otro problema añadido, si un usuario tiene configurado de forma extensa su dispositivo y, como pasa muchas veces, necesita una sustitución, no podrá restaurar los ajustes.

 

De todos modos el mayor problema es que, aunque es cierto que se gana en seguridad el cifrar el archivo de configuración, al usuario medio se le impide poder modificar y jugar con ello, cosa que a veces es más que necesario, como hemos visto muchas veces en el foro.

 

Aun estoy desgranando el cifrado, imagino que será AES y usará el SN como Key, también me ha parecido encontrar lo que sería la salt, aunque no descarto aun que se esté usando otro esquema. En cualquier caso, usando el SN como key, imposibilita cualquier tipo de herramienta genérica para el desencriptado, ya que ahora dependerá del SN de cada unidad, y sin acceso interno al sistema no se puede extraer. Solución?? En caso de no poder sacar el SN dela ONT, Fuerza Bruta

 

La única solución real es usar fuerza bruta para el SN. Cuando tenga tiempo, y una vez tenga revertido el cifrado completamente, se puede forzar el SN. El SN tiene un formato bien determinado:  "ASKYXXXXXXXX" Siendo cada X un valor hexadecimal. Eso es, en el peor de los casos tenemos 4Bytes que adivinar. 4Bytes codifican 2^32 posibilidades, algo más de 4000 millones permutaciones, y casi podríamos poner el Byte de más peso a 0. En cualquier caso, en el peor de los casos hablaríamos de un cifrado AES256 salteado del que tendríamos que probar como máximo 2^32 posibilidades. Así que a menos que se usase una derivación de key (KDF) compleja (cosa que dudo), un equipo actual lo resolvería en segundos/minutos. Esto hace posible crear una pequeña utilidad en que primero "calcule" el sn de cada unidad a través de su cfg, y posteriormente cifrar/descifrar ya conociendo el sn. Lo dejo apuntado como tarea para el futuro.

 

 

SHGW

Movistar sigue apostando fuerte por esta tecnología. Personalmente me parece un error por varios motivos. Recordemos que SHGW es una suite de seguridad  implementada directamente en el Router a modo de Firewall/Antivirus y control.

 

Esta idea no es nueva y muchos equipos del mercado lo permiten. El problema es que una vez que se está usando este sistema, puedes dar por acabada tu privacidad en la red, y en el mejor de los casos la protección que brinda es relativa. Esta suite requiere de servicios online que os puedo asegurar van a recibir para empezar cada URL que visitéis. Sin contar claro está con posibles problemas de rendimiento.

 

Movistar no lo habilita por defecto, creo recordar. Eso sí, automáticamente se habilita al usar por vez primera la aplicaicón móvil, ahora esta te advierte y solicita consentimiento expreso para tratar tus datos. También se usa de forma conjunta cuando se contrata "conexión segura".

 

¿Y po rqué digo que su utilidad es relativa? Bien, es muy cómodo poder centralizar la seguridad de toda la red de forma simple, pero el 99% de los problemas de seguridad no se basan en acceder a una web maliciosa, sino en descargar e instalar un archivo no confiable, es la ingeniería social y el no tener los equipos actualizados. Da igual la suite de seguridad que uses, no van a impedir un ramsonware que te entra por descuidado.

 

Por otro lado está la cuestión de los filtros. Los ISP y las empresas de seguridad han usado siempre DNS para conocer los sitios accedidos, e incluso imponer restricciones a que sitios se visitan. Los dos mayores navegadores (Firefox/Chrome) ya implementan DoH/DoT, y empezarán a habilitarlo por defecto pronto, con lo que el negocio de conocer que páginas visitamos se acabará pronto también, quiera o no quiera el ISP o la empresa que nos venda la suite de seguridad.

 

No he analizado demasiado todos los cambios nuevos de la suite , con lo que no pudo decir si han sido para mejor o para peor...

 

 

Fix para OLT Huawei 5800
Las ONT son nuestras unudades de fibra, o las tenemos integradas como en el HGU o las tenemos de forma independiente. Las OLT son el otro extremo, donde nuestras ONT en último término están conectadas. Bien, pues por lo que se ha visto era imposible que los usuarios con el Askey y que estuviesen conectados a estas OLT, pudiesen alcanzar los 600/600. Estas OLT son relativamente nuevas, pero en cualquier caso es imposible saber a priori que equipo tenemos al otro lado.

 

Esto es una gran noticias, porque de ser cierto muchos de los compañeros podrían caer en este cupo, es decir, usuarios que por culpa de esto, aun teniendo contratado 600/600 no podían llegar a dichas velocidades. Eso no queire decir, ojo, que todos los problemas de velocidad que se puedan tener sea  debido a esto. Pero sin duda es una buena noticia. Lo que me hubiese gustado es que se hubiese conocido públicamente el problema, al final la mejor política es la que explica, aunque tarde más/menos en resolverlo.

 

 

CloudFlare

Desde hace ya tiempo los usuarios con HGU no han podido usar las DNS de cloudflare, particularmente 1.1.1.1 debido a que el Router los usa internamente. En la n53 se creía que estaba resuelto, pero pronto nos enteramos por compañeros que esto no era así. De nuevo se plantea la misma dinámica... parece ser que esta vez sí que se podrá enrutar dicha dirección? Por como tengo ahora mismo configurado todo no he tenido tiempo de resetear y comprobar, aunque internamente no he apreciado grandes cambios al respecto, de echo la comunicación entre el SoC Quantenna y el Router se siguen comunicando por 1.1.1.2 (Quantenna) y 1.1.1.1 (Router). Aun con todo, parece que sí, ya que la dirección 1.1.1.1 no está en la tabla de rutas... otros compañeros podrán asegurarlo pronto.

 

 

Saludos.


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 1 de 2
170 Visitas
1 RESPUESTA 1
Re: ASKEY R3505VW n55 (Changelog y un pequeño análisis)

Buenos días @Theliel

 

Gracias por el análisis tan extenso.

 

Un saludo.

 

Alejandro.



Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.

 Si necesitas contratar Fibra Ópticacomprobar tu cobertura Adsl y Fibrao ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es 

Solución aceptada.png
Mensaje 2 de 2
114 Visitas