En este artículo, describo la forma en la que he conseguido leer el contenido de peticiones TR-069 vía HTTPS desde mi router F680 un servidor ACS (Auto Configuration Server) de mi compañía con el fin de analizar su funcionamiento y validar que el proyecto que estoy desarrollando funciona.
Este proyecto es un cliente de TR069 que tiene como objetivo emular distintos dispositivos de hardware usando un sencillo fichero de configuración, es decir que puedo emular ser un F680, un Sagecom FAST 5657, un ZTE 521, etc… Esto es muy útil para emular hardware, integrarlo en flujos de tests sin tener que disponer un «cacharro» encendido con el consiguiente consumo eléctrico y de espacio físico, además de la versatilidad, claro.
Para llevar a cabo esta prueba de concepto, he usado un router ZTE F680 V2 con firmware V2.0.10P2T4I
El software utilizado es:
Confirmar que tenemos acceso al panel de gestión del router
Lo primero que necesitamos es comprobar que tenemos acceso de admin o de user 1234 a nuestro router, para ello nos logeamos en el router, simplemente para confirmar que tenemos permisos. En esta aproximación necesitamos hacer un cambio en el DNS configurando una resolución estática para un nombre host específico, para ello podemos usar el usuario 1234 o admin.
Para tener un mayor control probando esta aproximación es recomendable que tengamos acceso con el usuario admin ya que nos permite modificar parámetros del servicio TR069.
usuario admin password admin
usuario 1234 password 1234
http://192.168.1.1/
Hay que tener en cuenta de que estos pasos han sido realizados usando un dispositivo ZTE F680 v2 con versión de firmware V2.0.10P2T4I. Cada versión de firmware puede funcionar de manera distinta, corrigiendo fallos, eliminando características, limitando permisos, o «escondiendo» algunas páginas de administración, etc..
Capturar tráfico con wireshark
Para capturar paquetes vamos a usar wireshark, ya que mitmproxy no tiene ese soporte de guardado de paquetes capturados o al menos yo no lo he encontré, así que uso directamente wireshark
sudo wiresharkPonemos a capturar paquetes en el dispositivo «any» que captura todo, simplemente por comodidad. Si quieres optar por seleccionar tu interface ethernet o wireless, los nombres pueden ser distintos a los de la captura de pantalla.
Dejamos wireshark filtrando por cualquier petición que use el puerto 10302 usando el siguiente filtro:
tcp.port == 10302
Configurar nuestro «man in the middle»
Usaremos mitmproxy en configuración reverse proxy, esta configuración reenvía a un host predeterminado cualquier petición que nos llegue a un puerto en el que escucha nuestro mitmproxy.
De esta manera mitmproxy simula ser el servidor de destino, el cliente se conecta a mitmproxy suponiendo que es un servidor confiable, y mitmproxy reenvía el tráfico de nuevo hacia el host final real, haciendo él mismo de cliente. Estando en el medio del intercambio de tráfico, mitmproxy lee el contenido de las peticiones y las reenvía al destino final, siendo así interceptado el contenido de una petición HTTPS, vamos lo que es un «man in the middle (m.i.t.m)»
$ SSLKEYLOGFILE="$PWD/.mitmproxy/sslkeylogfile.txt" mitmdump -p 10302 -m reverse:https://acs.mioperador.com:10302 -kExplicaciónde los Argumentos:
- SSLKEYLOGFILE: Es una variable de entorno que nos permite indicar en qué ruta guardamos las claves ssl, esto es imprescindible para poder descifrar tráfico TLS. Ver https://docs.mitmproxy.org/stable/howto-wireshark-tls/
- mitmdump: usamos la herramienta de dump, no queremos interacción con paquetes
- -p 10302: Ponemos a escuchar en el puerto 10302
- -m reverse: En modo reverse proxy lo que hacemos es que todo el tráfico que llegue a nuestro puerto 10302 lo reenvíamos al host que hemos configurado
- -k: Aceptar certificados no válidos. Este certificado se refiere al certificado remoto al que enviaremos las peticiones. En el caso del acs de nuestro proveedor, es un certificado autofirmado
Quiero dejar muy claro que esto es posible ya que el cliente de TR069 de mi router no valida el certificado. Si la implementación que contiene el dispositivo validase el certificado, la conexión hacia el mitmproxy no se realizaría y no sería posible realizar el ataque.
Supongo que esta práctica de no validar el certificado es para evitar perder conectividad con los dispositivos en el caso en que haya algún problema con el certificado o con la validez del mismo. Evaluando que cientos de miles de equipos de abonado se queden sin comunicar su estado periódicamente, sin conocer las métricas del dispositivo, o no poder ser asistidos por un operador para diagnosis… la verdad que entendería la decisión de que no validase el certificado, aunque no me parezca lo mejor.
Redirigir tráfico de TR069 a mi equipo
Este es uno de los pasos más interesantes. Agregando a mano un nombre de host que sea igual que nuestro objetivo, en nuestro caso «acs.mioperador.com» haremos que el DNS del router nos envíe el tráfico a nuestra máquina.
Es decir, «engañamos» al servicio TR069 para que nos envíe sus peticiones y no directamente al servidor «real», de esta manera podemos hacer que funcione el «man-in-the-middle»
Por supuesto, verificar que nuestra IP coincide con la hemos seteado el hostname estático. Más de una vez me ha pasado que cambiado de equipo, o por usar wireless y no ethernet, etc… he tenido otra IP configurada y no conseguía recibir tráfico.
$ ip addr
Para configurar hosts estáticos debermos tener acceso con el usuario «admin». El menú se encuentra en: Application -> DNS Service -> Hosts
confirmar que se ha generado el fichero sslkeys
https://docs.mitmproxy.org/stable/howto-wireshark-tls/
En pasos anteriores hemos levantado mitmproxy con la opción de guardado de SSL Key en una ruta, en concreto en ~/.mitmproxy/sslkeylogfile.txt
SSLKEYLOGFILE="~/.mitmproxy/sslkeylogfile.txt"
Configurar wireshark para usar SSL keys
Ya sólo nos falta poder descifrar los paquetes capturados, tan sólo nos hace falta configurar el fichero de SSL Keys que ha generato mitmproxy.
Para ello vamos al menu de Wireshark via Edit -> Preferences -> Protocols -> TLS -> (Pre)-Master-Secret log filename.
Copiamos y pegamos la ruta de nuestro fichero de SSL Keys y damos al OK
En este momento si todo ha ido bien, empezamos a ver contenido que antes no podíamos ver como URLs de peticiones y somos capaces de ver contenido cifrado o descrifrado de paquetes.
Volcar toda la conversación a un fichero de texto
Ahora ya podemos localizar una petición cifrada, están nombradas como TLSv1.2, seleccionamos con el botón derecho -> Follow -> TLS Stream
Ahora ya podemos ver el contenido descrifrado de la comunicación entre nuestro router y el servidor acs
He seguido los pasos correctamente pero no recibo tráfico
Para evitar problemas de IPs dinámicas en la red local y para evitar perder paquetes haciendo pruebas, recomiendo usar cable ethernet y no wifi, simplemente por que el interface de red se levanta mucho antes y más rápido que el adaptador wireless. Además también podemos configurar una IP estática en nuestro equipo para no tener que esperar al DHCP.
Si está todo correcto y no nos llega nada de tráfico podemos «forzar» a reiniciar el servicio de TR069 del cliente. Para ellos podemos hacer varias cosas, una es cambiar la URL del ACS, ya que parece ser que cuando se cambia la URL se realiza una especie de reset del servicio. No conozco muy bien el impacto pero es más inmediato recibir tráfico cuando se realiza ese cambio. Podemos por ejemplo cambiar de https a http, guardar y volver a setear la url con https. Debería llegar tráfico en pocos segundos.
Además los continuos intentos fallidos del servicio de TR069 por conectarse al servidor generan un exponential backoff que nos retrasa el siguiente intento de conexión dejándonos a la espera durante largos periodos. Puedes probar cambiando la URL del ACS y esperar a que funcione.
Recuerda que siempre puedes reiniciar el router o CPE, el tiempo de arranque es aproximadamente 1 minuto y no necesitas realizar ninguna configuración.
Dejo adjunto una captura de pantalla de la sección de configuración de TR069, que está localizada en Administration -> TR069 -> basic
Muy recomendable también si vamos a estar trabajando activamente en el router, es dejar el Periodicd Inform Interval bajo, como a 60 o 120 segundos, para no tener largos periodos de espera.
Alternativas
Usar nuestro propio servicio de DNS
Configurar DNS1 redirigiendo a nuestro equipo local, con dnsmasq. En nuestra configuración de resolución de nombres ubicada en la misma que usa el sistema /etc/hosts agregamos una entrada acs.mioperador.com con nuestra IP.
El resultado es el mismo, la aproximación similar, usar el DNS para suplantar al ACS, pero usamos nuestro propio servicio DNS. Esta aproximación es útil si en el panel de control no tenemos permiso para configurar hosts estáticos.
Deja una respuesta