Cómo Hackear un Router de Casa para conseguir la Password SIP: Una PoC Just for Fun! - Long Version -
 |
| Figura 1: Cómo Hackear un Router de Casa para conseguir la Password SIP: Una PoC Just for Fun! - Long Version - |
- Esta Historia se contó a modo resumen en ElLadoDelMal pero con el nacimiento de HackingHomeDevices me decidí a premiarla con la versión larga - .
Señoras y señores, Hackers, ahí va el artículo con su combo de White Paper + Vídeo:
La comodidad genera despreocupación de ciertas cosas elementales, cosas como la de estar conectados al mundo digital mediante Internet, que apareció como una especie de “carril” adicional hacia el acceso del conocimiento, complementándose al contenido físico.
Aún recuerdo el primer chisme que tuve y que era capaz de darle forma a la voz telefónica, el U.S. Robotics 56K faxmodem, donde se apreciaba un surfista saliendo de una pantalla CRC en la caja. Claro que, la configuración de ese entonces no era “Plug-and-Play” ¡tenías que aprender a “surfear” antes de poder explorar el “mar”!
Con el paso del (breve) tiempo, la infraestructura permitió transformar a esos módems en equipos más sofisticados, lo que ya bien conocemos cómo router (para hacerlo entendible) pero yo lo veo más cómo un “All-in-One” de equipo de red, porqué no sólo es un enrutador; es también switch y firewall y… ¿por qué no? hasta conversor de medios (de fibra a Ethernet o ONT).
Un solo módem e incontables “routers” son los que han pasado ya por mis manos. En este artículo, me gustaría centrarme en los modelos de router que ofrece el ISP de Adamo, y no se trata de hacer una comparativa a modo “review” de lo mejor y peor de cada uno, se trata de cómo hallé “mi tesoro” ahí dentro. No obstante, eso no fue lo que me convenció para despedirme de Movistar - pero no quiero que se ponga celoso - :P, ya sabéis que la vida da muchas vueltas… lo hice por motivos personales (algo así como… ¿amor a primera vista?) lo que no significa, que me haya ido por “malos royos” ni para siempre…
Adamo lo tuvo fácil, aprovechó la infraestructura de fibra de mi hogar, y es que, Telefónica pone buen material (ojo ¡dicho por ellos!). Les facilité los accesos (ubicación de dónde conectar ONT + router) para que puedan operar con mayor comodidad. Deben hacer su trabajo siguiendo sus protocolos, y asegurar de que la línea llega con fuerza, etc. A lo que yo les iba haciendo bastantes preguntas:
¿Puedo poner un router neutro?
¡Claro! El puerto 4 está en modo bridge.
¿Lo capáis mucho?
No tranquilo, puedes abrir tus puertos y tal.
¿Alguna incidencia a destacar que recordéis cómo “muy heavy”?
Tuvimos intermitencia temporal, un cliente nos estaba haciendo un bucle, pero eso fue muy al principio…
Puesta en Marcha
La ONT era un dispositivo aparte, marca FiberHome y un cable Ethernet de categoría 5e que se conecta al puerto WAN del router. El router en cuestión es un Inteno EG200 y está basado en OpenWRT (Buen cacharro a simple vista). Yo estaba bastante deseoso de “meterle mano”, ver las diferencias y funcionalidades que tenía respecto al de Movistar, pero esa parte la dejaremos para más adelante, ahora quería tener mi VoIP igual cómo lo tenía antes, es decir, puesto en mi equipo haciendo de cliente SIP además de tenerlo en un teléfono convencional.
Lo primero fue realizar los típicos tests de velocidad, luego coger el teléfono (el que iba pinchado al rj11) y hacer algunas pruebas (llamar a móvil, de móvil a casa…). Todo funcionaba bien, no había nada de congestión en la “autopista”, al menos, en las horas en las que “circulé”.
¡SIP! ¿Dónde te escondes?
Necesitamos saber la configuración de nuestra VoIP para sacarle el mayor provecho a este servicio (recordar, que esto lo estamos pagando aparte). ¿Por dónde empezamos? Si esto fuera el juego del escondite, miraría primero en su zona de confort, vayamos pues a por su IP.
 |
Figura 2: Consultando la configuración SIP en router |
Se observa en la Figura 2, que falta una letra en la dirección URL (a estas alturas, el navegador nos lo pone bien sencillo con las llamativas pistas). Aunque haya llamado la atención, nos lo anotamos cómo deberes para poder dar prioridad antes a nuestra “misión” principal. Accediendo a la pestaña STATUS y sección Voice, podemos leer el usuario (User) ******.voip.adamo.es (donde * está formado por números) y el Domain de registro 91.126.224.9 pero nada más, salvo los logs de las llamadas que se efectúan.
Tenemos que seguir con su rastro... Si queremos más pistas, seguramente Internet esté lleno de foros donde poder consultar. Así lo hemos hecho siempre ¿no? Seguro que alguien habrá dado con la clave.
El primer foro con una sección dedicada a Adamo, es el de bandaancha.eu. Un post reluce su “chincheta” con el título: Datos SIP y VLANs de Adamo y más curiosidades. Se obtienen casi todos los parámetros excepto el de la password SIP… Bueno, vamos a ver si “tenemos suerte” buscando otro post de nuestro interés en el mismo foro.
Y he aquí otro post que no pinta nada mal: Cómo acceder al router inteno DG200A-AC como admin, paso a paso. Es estilo tutorial, con sus imágenes y todo del mismo user (bajo el Nick @djcool) que también proporciona los datos SIP del post fijado (este, pero, parece estar desanclado).
Lo probamos con toda ilusión pero rápidamente los errores se hacen con el protagonismo de la situación a velocidad de “ransomware” a pesar de que las instrucciones se hayan seguido al pie de la letra. El fallo parece haberse resuelto por Adamo y en cooperación con la gente de Inteno (la marca del router)…
Había sido un buen “intento” el descartar las posibilidades fáciles de primera instancia. El nivel de dificultad ahora ha ganado un +1 y la cosa se empieza a poner algo más turbia. Le damos una vuelta a la situación, se trata sólo de un parámetro “clave”.
Information Gathering
El router y ONT ofrecidos son dos “piezas” separadas. La división está hecha para vencer si seguimos la estrategia del concepto; “divide y vencerás”.
Usamos un TAP para hacer un Man-in-the-Middle para ver si podemos captar algo de lo que “router dice a ONT o viceversa” (capturar el tráfico en ambos sentidos). En concreto usé el Throwing Star LAN Tap Pro para este trabajo. Preferí tener la versión Pro porque, aunque sea fácil soldar “cuatro cositas”, no quiero tener un mal presentimiento de que no estuviera bien montado/soldado…
Antes de usarlo, debemos de conocer bien a la nueva herramienta adquirida. Es un TAP pasivo (no necesita corriente adicional) y funciona a 100 Mbps o Fast ethernet en lugar de Giga o 1000 Mbps, pero es capaz de “calmar el discurso” entre ambos extremos yendo a 100. Teniendo esto en cuenta, se necesita lo siguiente para tener éxito:
3 cables de ethernet adicionales. 1 para monitorear un sentido (la ida). 1 para monitorear el otro sentido (la vuelta). Y el último se usa para conectar ONT y router, quitando el suministrado que va de la ONT al puerto WAN del router (este es el que reutilizaremos), desanclamos o bien el puerto del ONT o el del router e insertamos el último cable de manera que el TAP quede en medio.
 |
Figura 3: Esnifando con el TAP |
1 tarjeta de red adicional. Una opción cómoda, es usar una NIC por USB (para más movilidad, sobre todo en portátiles), que si es a 3.0, irá a velocidad de Giga (para este caso no es necesario, pero si no dispones de una, vale la pena cuidar ese detalle…).
Será bueno ayudar en la “negociación” dentro de lo posible… para ello, forzaremos a que la velocidad de las dos tarjetas de red vayan a 100 Full Duplex y… ya que estamos, les quitamos el protocolo TCP/IP, sí, has oído bien, el equipo que va a monitorear no lo necesita, wireshark lo “digerirá” mejor.
 |
Figura 4: Cambiando velocidad de NIC a 100 y quitando protocolo TCP/IP |
Por último, tener un sniffer cómo wireshark. Se pueden tildar las dos interfaces de red para que capturen por ambas, así luego no hay que andar con correlaciones de ningún tipo.
Todo listo para darle al “play” pero antes de pulsarlo, es bueno saber que sí lo hacemos en un Windows, probablemente no podamos ver frames de VLAN taggeados (vamos que no podremos distinguirlos), Linux viene más preparado, al menos en Kali. No tiene mayor importancia, si un paquete está desprotegido (usando protocolo http por ejemplo), se delatará de igual manera. Recordar que estamos situados en un trunk o tagged lo que significa, que pasa más de un “rio” (vlan) por el cable.
El “viento” fluctúa de la siguiente manera en esta “estrella ninja”.
 |
Figura 5: Dirección que toman los paquetes en el TAP |
¡Ahora sí! ¡Que llueva paquetes! Encendemos ONT, luego router. Si se ha seguido el “setup” mencionado, puede tardar un poco, ya que tienen que negociar ambas partes para ponerse a “100”. Según las NIC que se tengan, puede verse el par de luces “haciendo ojitos” (en las del monitoreo) o bien puedes entrar en la página del router, que sin dar alarma alguna, te dirá su estado ;) .
 |
Figura 6: Estado de la auto-negociación en la WAN del Inteno |
 |
Figura 7: Capturando autenticación digest |
Pero no es lo suficientemente llano el “camino”… Se captura el hash, autenticación digest, significa que debe de hacerse un ataque de fuerza bruta y sabemos que eso puede tardar un tiempecito. Sí se observan parámetros valiosos y que sabíamos por el foro, pero nada que no sepamos ya. Puedes jugar grabando tus conversaciones telefónicas, esto lo dejamos fuera del alcance aquí.
Somos
impacientes y queremos resolverlo, sino a velocidad de fibra a
velocidad ADSL
(a la de módem 56K ni se nos pasa por la cabeza :P).
Quizá
el truco esté en usar algo de “voz”.
Social Engineering
Los servicios de soporte técnico de los ISP no suelen atender peticiones que no estén dentro del alcance o del protocolo estipulado que se centra en resolver averías en relación a sus dispositivos asociados, pero veamos a ver si se “enrollan” un poco :P .
Descolgamos el teléfono para dar paso a la batería de palabras:
Nos autorizamos con DNI, nombre, apellido… y…
¿Podrías por favor facilitarme los datos SIP para configurarme la VoIP?
Que quieres, ¿configurar un teléfono VoIP?
Sí, y bueno ponerlo con un cliente SIP en el PC.
Lo siento pero no estamos autorizados a dar esos datos…
Vaya hombre, oye y ¿no me puedes dar alguna pista de cómo sacarlo? Sólo me haría falta la contraseña SIP, es un dato que me pertenece, y así puedo aprovechar más la tecnología VoIP.
En internet se habla de cómo hacerlo.
¿Ah sí? Ei pues… yo he estado mirando, y no he logrado nada… Se habla de un exploit en un foro, para tener acceso Admin, pero ya está parcheado.
Hay otras formas de sacarlo.
Mmm ¡Ah vale! Tú te refieres por el puerto serie RS232 vía USB-TTL eh? Que soy informático :) .
No, no va por ahí…
¡Ok! Bueno, pero entonces, ¿me podrías dar alguna pistilla de cuántos caracteres se compone la contraseña ni que sea? A mí me dijeron que podía...
De acuerdo eso sí te lo puedo decir.
¿Tiene pinta de ser de 8 verdad? (ya os contaré porque lo deduje).
Mmm sí correcto, son 8.
Y me puedes decir si son mayúsculas, minúsculas…
Eso ya sí que no te lo puedo decir…
Vale vale, bueno oye, ¡muchísimas gracias por todo! :D .
Bueno, yo creo que sacamos bastante tajada al fin y al cabo. Sabemos que la password tiene 8 dígitos. ¿Cómo pude intuirlo?
Cuando te das de alta, te envían un SMS a tu terminal con el contenido de la URL, user y password para consultar tu facturación.
 |
Figura 8: SMS de alta enviado por Adamo |
El Foro y El Forastero
No solía hacerlo, pedir ayuda no es nada malo y no dudé en “alistarme” a la banda ancha.
Lancé mi primer post con la esperanza de que alguien cómo el impulsor de ese hilo (@djcool) me diera alguna “limosna” sobre la pass. Y nada, seguía la calma en ese tipo de océano, todo parecía de un mismo “color”, muy estático. Pero eso sí, el debate seguía, al ritmo de estrellas fugaces (un ritmo nada estresante). Me sentía como en casa, desconectado, bien recibido…. Se sacan cosas positivas siempre de todo.
Mi Nick es @dSStripanteL (sigo allí, y fui para quedarme :D). El significado es una mezcla entre mi primera cuenta de correo de “ron-miel”, jeje un Hotmail perdón (es que el nombre invitaba a hacer varias rondas de palabras chistosas), y por “destripar”/ romper el SSL, que fue lo que intenté hacer como mi “next step” (¡o level!).
Machine-in-the-Middle
Esta vez vamos a emplear máquinas para hacernos con el botín en lugar de humanos (por si algo sale mal en el experimento :P). No es exactamente lo mismo que un “Man-in-the-Middle”. Encontré la información de este método en las configuraciones de captura con wireshark.
Me cercioré de un tráfico cifrado que iba por el puerto 5223 (poco común, pero cifrado).
 |
Figura 9: El tráfico cifrado en 5223 bajo TLSv1 |
Mi idea era manipular el tráfico, rompiendo así el SSL (me dio bastante “guerra” para que engañarnos…). De la captura, pude sacar tres certificados y obtener el nombre host que atacaba esa IP, que es inteno.adamo.es. Los certificados se ven mejor a modo extensión .crt, tal que así:
 |
Figura 10: Certificado Root -> Intermediate -> Client |
La teoría era clara, la ID VLAN es la 603, debíamos de crear un “puente” (bridge) para estar en esa vía y luego utilizar alguna herramienta para intentar su rotura (o crear una “gotera”). Esto no se trata de https, por lo que SSLStrip no servirá… pero su casi gemela SSLsplit parecía que sí.
Seguramente el término de bridge os sea más familiar cuando la intención de su uso ha sido enlazar una red cableada con otra sin cablear (WiFi) para aquellos casos de dispositivos aislados de su Gateway con necesidad de disponer conexión a internet (por ejemplo). Para entender su función mejor, yo me imaginaba que era como empalmar un cable eléctrico con cinta aislante, porque no deja de ser como una extensión de cable, pero en términos de networking, me gusta más la idea de atribuirle el sinónimo de switch, porque así es como se comporta, como un dispositivo operando en la capa 2 (ej. Si existe un servidor de DHCP en una de las NICs del bridge el dispositivo que se conecte en la otra NIC obtendrá una IP, siempre y cuando el dispositivo conectado esté por DHCP claro).
Antes de empezar a darle instrucciones a la “máquina del medio” (una Kali Linux), que sepáis que obtuve un error con el SSLsplit. Error en las rutinas de OpenSSL y como no quiero que os frustréis en el primer intento, os comento lo que a mí me funcionó. Deberemos de cambiar un par de valores en el archivo de configuración de openssl.cnf.
 |
Figura 11: Permitiendo TLSv1 en OpenSSL |
Démosle ya un cambio de “look” a la máquina introduciendo lo siguiente por consola (comentarios incluidos):
# Generamos el certificado ca para SSLSplit
openssl genrsa -out ca.key 2048
# En el common name le pondremos *.inteno.adamo.es lo demás puede ser cualquier país, ciudad…
openssl req -new -x509 -days 1826 -key ca.key -out ca.crt
# Creando las VLAN 603 de datos en las 2 NIC
ip link add link eth0 name eth0.603 type vlan id 603
ip link set eth0.603 up
ip link add link eth1 name eth1.603 type vlan id 603
ip link set eth1.603 up
# Creamos el Bridge y le añadimos la VLAN 603 que fue creada en ambas NIC
ip l a name br0 type bridge
ip l set dev br0 up
ip l set dev eth0.603 master br0
ip l set dev eth1.603 master br0
# Deshabilitamos las peticiones ICMP de redirección para ser más transparentes, ya que no queremos dar a conocer posibles rutas como lo haría un router
sysctl -w net.ipv4.conf.all.send_redirects=0
# Habilitamos el Forwarding en la Capa 2
modprobe br_netfilter
echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
# Activamos el Forwarding en la Capa 3 -no es necesario para ipv6 ya que no se vio tráfico en ese ámbito para dicho puerto-
sysctl -w net.ipv4.ip_forward=1
# Redireccionamos el tráfico que se dirige al Puerto 5223 hacia el SSLSplit que escuchará en el 8443 para manipularlo
iptables -t nat -A PREROUTING -p tcp --destination-port 5223 -j REDIRECT --to-ports 8443
# Si todo fue bien hasta ahora, conectamos los cables de red
# Pedimos que se nos otorgue otra IP publica en la interfaz del puente -br0-. Sí, eso se puede hacer, lo necesitamos para redireccionar el tráfico por esa nueva IP publica recibida por cortesía de Adamo, sino, no podremos salir por ningún Gateway estando en modo bridge, deben de darnos “paso” y eso lo conseguimos vía dhcp
dhclient br0
# El “truco” ahora está en configurar una IP del tipo pública como secundaria en el -bridge- dentro del rango de la WAN del router, sino, no podríamos interceptar los paquetes -Un modo de sacar/saber la IP pública es verlo en la página principal del router Inteno cómo se muestra en la Figura 6 en el status de la WAN, otros métodos tenemos bien; por vía web como en whatismyip.com o similares servicios o bien también por una de las vías que más me gustan, haciendo uso de una consulta dns, tal que: nslookup myip.opendns.com resolver1.opendns.com Eso te devolverá la IP pública. Como apunte, es una buena forma de saber -imaginémoslo- si te están interceptando la comunicación por el puerto 80, 443. Si lo que dice la status de la WAN y la consulta DNS que hemos visto no coinciden con la IP pública del servicio web, entonces malo…
# Pues eso, que asignamos una nueva IP pública en el rango, se puede poner una /16 según como se vea para cerciorarse que se verán para “darse un abrazo al menos”. Es bueno hacer un ping contra el router Inteno para ver que la latencia es de 1 o menos milisegundos, de ser así querrá decir que se están viendo OK -deben haber más de menos de 1 ms- ¿y sino? Pues será un cliente de Adamo :D .
ip a a 91.126.X.Y/16 dev br0
# Usamos SSLSplit para interceptar el tráfico. Podemos decirle que sólo emplee el TLSv1 con el parámetro -r. El -M nos guardara las “master keys” en formato de SSLKEYLOGFILE -va bien para introducirlo en wireshark- y el -X una captura ya desencriptada, es la opción más asequible. Estos dos parámetros no son mandatarios.
sslsplit -D -k ca.key -c ca.crt -M logsplit.log -X split.pcap ssl 0.0.0.0 8443 -r tls10
El resumen gráfico de todo esto lo mostramos en la figura siguiente para dar forma y colorido:
 |
Figura 12: Estructura Machine-in-the-Middle entre router y ONT en VLAN 603 |
Cuando el tráfico pasa por una u otra tarjeta, se filtra empleándose la VLAN que marcamos cómo 603, por lo que, sólo podrá viajar esta VLAN ID por el puente.
Nota: Si no le decimos al puente que le dé una ojeada a sus iptables, sólo se limitaría de pasar el tráfico de una NIC a la otra empleando las direcciones MAC.
Ahora viene cuando nos llevamos un buen chasco, y es que todo lo que hemos desplegado no ha servido para encontrar nada relacionado con la SIP…
Se vio que el tráfico por el puerto 5223 fluía cada “x” tiempo pero al comprobarse la huella digital de los certificados, se deniega el paso y se rompe la comunicación continuamente. Si no se comprobara, posiblemente funcionaria pero no es nuestro caso. Así que… ¡Toca cambio de planes nuevamente!
Los Exploits
En el foro de BandaAncha ya hubo un método que se aprovechaba de un exploit para acceder con el usuario Admin al router Inteno. A lo que me pregunté… ¿Y no habrá más? Sí, había más. Quien estuvo jugando con estos dispositivos de Inteno fue Neonsea.
En los exploits empleaba el uso de WebSockets y los automatizaba con Phyton. Llegó a sacar a la luz 5 CVES: CVE-2017-11361, CVE-2017-17867, CVE-2018-10123, CVE-2018-14533, CVE-2018-20487
Sabiendo que el primero estaba ya parcheado (el empleado en el foro; CVE-2017-11361) y cómo hay tantos, pues casi seguro que tendremos suerte. ¡No creo que al fabricante le haya dado tiempo de arreglarlo! Pues chapó por Inteno, porque sí, los había arreglado todos…
Desde que tengo Adamo ya se me había actualizado el firmware del router, todos los exploits fueron testeados en el: EG200-WU7P1U_ADAMO3.16.4-190226_1650
En la numeración se observa 190226, parece que es la fecha del firmware (26 de febrero del 2019), y no hay ningún exploit de Neonsea que sea posterior :( .
Me intrigaba saber cómo podía comunicarme con los sockets cómo Neonsea hacía, pero en lugar de hacerlo con Python, usar algo manejable (seguir “jugueteando”) para poder deshacer cambios e inserciones a modo de prueba y error.
Jugando con los WebSockets
Una de las herramientas que más me gusta para llevar a cabo esta comunicación es curl. Lo malo es que para interactuar con el Inteno, al utilizar ubus (OpenWrt micro bus architecture), se necesita un plugin.
Cuando te acomodas a una herramienta, el paso para habituarse a otra de nueva conlleva tiempo para su adaptación, y puede inquietar un poco (sobre todo cuando se gasta tiempo sin sacar pista alguna).
Los WebSockets, están relacionados con los entornos web, pensando en ello, la ayuda podría provenir haciendo uso de las herramientas del desarrollador del navegador, las del Firefox mismamente que es con el que más me codeo. Encontramos ejemplos y descripción del funcionamiento en la MDN web docs de Mozilla.
Convertimos a nuestro Firefox en un auténtico cliente WebSocket, sacamos jugo de su buena referencia y así lo plasmamos:
Creando el socket con su correspondiente protocolo.
var superSocket = new WebSocket("ws://192.168.1.1/", "ubus-json")
Log, muestra las respuestas por cada mensaje enviado.
superSocket.onmessage = function (event) {console.log(event.data)}
Solicitando un id de sesión haciendo un login con el usuario del router (user) y su contraseña del WiFi que viene por defecto.
superSocket.send(JSON.stringify({"jsonrpc":"2.0","method":"call","params":["00000000000000000000000000000000","session","login",{"username":"user","password":"wifis-password"}],"id":0}))
La respuesta contiene la id de sesión bajo el parámetro “ubus_rpc_session” que lo usaremos para nuevas peticiones que deseemos hacer.
 |
Figura 13: Obteniendo la id de sesión |
 |
Figura 14: Flow de la comunicación WebSocket usando un navegador |
 |
Figura 15: Listando los comandos que brinda y ejemplo de ejecución |
superSocket.send(JSON.stringify({"jsonrpc":"2.0","method":"list","params":["tu-id-de-sesion-aqui","*"],"id":999}))
La respuesta en rosa, nos devuelve los comandos con sus servicios y opciones, sabremos donde acaban las opciones de un servicio por sus paréntesis {}. En el ejemplo de la Figura 15, se muestra el estado del asterisk, que brinda dos opciones; el “status” y los “códecs”, tal que:
"asterisk":{"status":{},"codecs":{}}
En este caso se ha consultado la de “status”. Si la opción del servicio contempla paréntesis vacíos, significa que no requiere de un valor adicional.
Vemos la respuesta reflejada en color negro de texto.
Tenemos unos pocos comandos para seguir “jugueteando”, aburrir no nos aburriremos, pero… ¿Nos divierte este juego? Paciencia…
De vuelta al Mar con Wireshark
Demasiada info la que se obtiene vía WebSockets, necesito un “chapuzón” para aclarar las ideas (y aprovechar al máximo el calor que nos dejó el verano).
Otra petición capturada con Wireshark por HTTP, me llamó la atención porque, a pesar de estar en claro, se trataba de un fichero con contenido ilegible y con extensión .enc (¿eing?).
 |
Figura 16: Petición GET, HTTP del fichero .enc |
Esa extensión .enc tiene toda la pinta de tratarse de un archivo encriptado y debe de contener algo valioso que Adamo no quiere que sepamos. Podemos suponer que se podría haber encubierto el archivo ocultándolo bajo HTTPs y evitar su encriptación (o hacerlo todo para fortalecerlo x 2), igual había alguna incompatibilidad o era costoso de implementar. De momento nos quedamos con la “caja fuerte” y sin su “llave”.
Centrémonos en el .enc y lancemos la “caña de pesca” a ver que sale. Echamos una búsqueda del término .enc en packet bytes y…
 |
Figura 17: URI + .enc en el protocolo DHCP/BOOTP |
El Algoritmo
En “algún” manual de un dispositivo Inteno se escondía el algoritmo usado para encriptar este fichero, empleando 3DES.
El proceso para encriptar un XML de configuración se describe detalladamente en su página 10:
 |
Figura 18: Mecanismo de encriptación usando 3DES |
En la página 54 se aprecia su formato y tabla de ejemplos.
 |
Figura 19: Modo de emplear el archivo .enc y ejemplos |
Empezaba a notar destellos de ese 3DES, es como con un HTTP que daña a la vista sin una “s” (cómo una gran falta de ortografía), una letra no me cuadraba del todo… ¿Qué es un 3 sin el DES? ¿Otro algoritmo pero de versión anterior…? Ahora que hago más memoria… ¡Ese “des” fue destapado en una llamada en los WebSockets! De todas formas, ¿cómo va a servir? Si solo le pedí al router que me diera algo de información al respecto… Se lo pedí sin forzar, naturalmente.
 |
Figura 20: Obteniendo la llave 3DES vía WebSockets |
En el manual del Inteno XG6846 la convierten a hexadecimal usando la herramienta xxd, haciendo: echo $1 | xxd –p (donde $1 es la “des”).
Tenemos el dilema de cómo hacer el paso inverso o “ingeniería inversa”.
Hay veces en que las búsquedas te ponen del lado de la suerte sin pulsar el botón (Voy a tener suerte) en el buscador google. Encontramos a otra persona des-encriptando contra un distinto Inteno de otro ISP.
Daniel Vindevåg es quien lo hizo, colgó un sitio web para hacerlo cómodamente en un formulario. ¿Qué te da algo de mal rollo cómo me dio a mí porque no sabes dónde irá a parar tu aprovisionamiento? No te preocupes, es normal y él también lo pensó, por lo que si añades .txt al final de la url tienes el código para que lo montes en un servidor localizado tuyo o ver los comandos (a mí me resultó más cómodo esto último) y ganarle ventaja al “ladrón del tiempo”.
El acertijo se resuelve con este comando:
openssl enc -d -des-ede -nosalt -K $key -in $encrypted_file -out $decrypted_file
Bastante similar al que se comentaba en el manual del XG6846 y el encriptado observado en la Figura 18. Las únicas diferencias son la opción –d en lugar del –e y la ausencia del –iv.
Daniel lo des-encriptaba sacando la llave des de su router de la siguiente url: http://192.168.1.1/xmlprov.html . Y obtenia un archivo .txt.
Pues nosotros vamos a coger nuestra MAC.enc a ver que vemos...
Pasamos a hexadecimal (como ya vimos anteriormente) con ayuda de la herramienta xxd.
No dio error, ¡genial! Pero ¿Por qué el contenido sigue estando ilegible? La operación la repetimos numerables veces, probando otras opciones a ver si “sonaba la flauta”.
No os vais a creer lo que era… Todo estaba bien, la desencriptación había tenido éxito lo que… nos encabezonamos en creer que era un fichero puro de texto, y en realidad se trataba de un ¡¡.tar.gz!! (Gritos de alegría y conmoción sin igual).
Fue cuando probé con 7zip un tanto desanimado, vi que se iba abriendo paso, sólo faltaba escucharse de fondo un “access granted”. Con el aprovisionamiento abierto, Iba haciendo “scroll” hacia abajo, más abajo. ¡Ya casi se nos acaba el “rollo de papel”! Y la última línea del fichero me sacudió como un rayo penetrante que cosquilleó todo mi yo, - mírala… la “8 ojos” jajaja. A la próxima utilizo un editor HEX cómo el notepad++ con su respectivo plugin y verificar la lista de firmas de archivos.
- You Win -
Hackea tus Provisiones
Esto es el “tutorial”, la PoC para demostrar paso a paso cómo se hace: Let’s GO!!!
Espera, ¡STOP!. Antes de adentrarnos de lleno con la parte práctica, no va mal una visual del asunto ;) .
 |
Figura 21: Escenario del proceso de Hacking |
Ahora sí, GO!!!
Lo primero, mostramos el entorno de trabajo.
 |
Figura 22: Mostrando versión de OS de Kali Linux |
Tras hacer MitM entre el router y la ONT cómo vimos en la Figura 3 del artículo, abrimos el fichero de captura .pcap en busca de la URL provisionada.
 |
Figura 23: Abriendo el archivo de captura |
- El fichero .enc lo recogemos usando wget con el parámetro -U para usar el mismo User-Agent observado en la captura de la Figura 16.
 |
Figura 24: Obteniendo el .enc con wget |
Abramos la página web del router con Firefox.
 |
Figura 25: Abriendo la página de login del router |
 |
Figura 26: Abriendo las herramientas del desarrollador en Firefox |
 |
Figura 27: Creando el WebSocket y activando el logging |
 |
Figura 28: Obteniendo un id de sesión |
 |
Figura 29: adquiriendo la llave 3DES |
 |
Figura 30: Usando la herramienta xxd para pasar a HEX |
Desencriptemos el archivo con la ayuda de la herramienta openssl. -d indica desencriptación, -des-ede es, dos triple DES EDE en el modo ECB, -nosalt es para no usar rutinas de derivación en la clave, -K es la llave en formato HEX, -in la entrada del fichero encriptado, -out la salida del mismo fichero pero ya desencriptado.
 |
Figura 31: Desencriptando el fichero .enc usando openssl |
 |
Figura 32: Untar el fichero desencriptado |
 |
Figura 33: Mostrando el contenido de Provisioning.conf |
Y un vídeo sobre lo visto, esta vez en castellano con subs y textos en inglés (international mode ON). No hubiera tenido tal buen aspecto sin la ayuda de Esther Martínez (la chica que señala con el dedo en el vídeo), que se lo curra para dejar unos acabados más pulidos (que esto de los vídeos creerme ¡Que tiene su miga!).
Nota: Hasta el segundo 37, Se hace mención especial a la gente del foro de Banda Ancha. Prometí compartirlo con todos ellos si tenía éxito extrayendo el password de la SIP.
También realicé este “paper” para dejar constancia con la PoC vista aquí y lo que se exige como consumidores/clientes de un ISP.
Figura 35: Call your key to phone all de Gerard Fuguet
Y más tarde, se otorgó el CVE ID: CVE-2019-13140
¡Bonus Track!
Este es mi segundo CVE otorgado, me gustaría compartir esta particular experiencia y guiar por todo el proceso por el que he pasado en el reporte de la vulnerabilidad, porque reconozco que con el primer CVE fui un poco “a salto de mata”.
Cómo primer paso, cuando se sabe de una anomalía y hemos visto como “explotarla”, hay que notificarlo al proveedor. En este caso, el fichero .enc sale del router y el fabricante de éste es Inteno. Vayamos a la página web en busca del contacto.
 |
Figura 37: Intenogroup: Información de contacto |
Le escribimos y rebota de nuevo a nuestras manos con efecto “boomerang”.
 |
Figura 38: Contactando con Intenogroup |
Y allí va Adamo a “relevarlo”.
 |
Figura 39: Email por Maxim Triay, CTO de Adamo |
Por supuesto, les pasé mi investigación, el “White Paper” y me ofrecí también en ayudar en lo que hiciera falta.
 |
Figura 40: Cooperando con Adamo y premio al “canto” a cambio
No pedí nada a cambio por colaborar, lo hice con toda voluntad y me regalaron 2 meses gratis, es un detalle la verdad :) .
Hice bastante hincapié en el CVE otorgado para que se hiciera un “trackeo”/seguimiento adecuado del fallo.
Cuando solicité el CVE, resulta que lo pedí en mitad de una ventana de mantenimiento (ley de Murphy total ¿eh?). Al solicitar el CVE, puedes hacerlo por varias vías, yo prefiero usar el formulario por la vía web. Con el anterior, tardó relativamente poco (unas horas) en recibir un email con el número que le asocian, esta vez pero, pasaban dos días…
 |
Figura 41: Auto-Respuesta del CVE, solicitud de más info y obtención del mismo |
Vale… quizá esperan a que lo publique en otro sitio para ir acorde con el proveedor para su divulgación. Me esperé hasta que Adamo diera “luz verde”.
Me llega otro email del dominio de Adamo de Joan Cano (network enginer), comentando que tiene un posible fix, un tipo de beta que no estaba vinculado a un número nuevo de firmware.
 |
Figura 42: Pre parche/fix del Inteno |
Pasan unos días y el parche definitivo ya ha llegado, remotamente hacen el “deploy” y como son precavidos, dejan el anterior como backup en el “banquillo” de memoria del router.
 |
Figura 43: Arriba; firmware activo. Debajo el firmware inactivo de respaldo |
Estamos preparados para su divulgación, aprovecho un tweet mío enlazando un comentario y me hago con el link.
A través del formulario del CVE, escogemos la opción: “Notify CVE about a publication”
 |
Figura 44: CVE: Notificación para una publicación |
 |
Figura 45: Contestación e inicio de la publicación del CVE-2019-13140 |
Yo tengo mucha cabezonería y deseaba ver figurado el paper en la referencia, así que lo subí a Exploit Database para completar el pack junto al exploit. Se cuelga, solicito un update del CVE, “again” por formulario, y acaba aceptándose para su ingreso, recibí un email confirmándolo.
 |
Figura 46: Actualización de referencia del CVE |
 |
Figura 47: En espera de reanálisis tras actualizarse la referencia |
El histórico o llamado Timeline fue:
2019-06-29 - White Paper done
2019-07-01 - CVE assigned
2019-07-09 - Notified to Inteno
2019-07-11 - Adamo aware and ask for detailed info
2019-07-12 - Info facilitated
2019-07-25 - Early patch available and applied (Cooperation starts)
2019-07-26 - Tested and failed (VoIP not working)
2019-08-27 - New firmware available
2019-08-30 - Firmware EG200-WU7P1U_ADAMO3.16.8-190820_0937 applied on router
2019-08-31 - Tested OK
2019-09-04 - Disclosure published
Reflexiones Finales
Creía que Movistar era de lo más restrictivo con los dispositivos que brinda a los clientes… y resulta que no, todo lo contrario. He podido hacer más cosas a mi “aire” con ellos que con cualquier otro operador… Supongo que el temor encoge/restringe protegiendo a los suyos ante cualquier exposición peligrosa. ¿Pero cómo proteger? ¿Estaríamos más seguros si nos quedásemos en casa todo el día sin salir al exterior? Sí uno decide hacerlo, es totalmente libre de acogerse a lo que quiera, pero que tenga al menos la opción de abrir la puerta. El router de Inteno que Adamo brinda no da la opción de cambiar la contraseña, si alguien la adivina, si alguien sabe su “secreto”, hasta que no se cambie de dispositivo, no hay nada que hacer… Y es una pena, porque son equipos que no están nada mal. Se desaprovechan muchas características por la decisión de acotamiento de funciones.
El password de la WiFi cumple con los criterios de robustez, solo que el hecho de “momificarse” le puede convertir en “carne de cañón”.
Solo quería aquello que me pertenecía, y sólo faltaba una parte vital para que funcionase, una contraseña para deshacer la esclavitud por la que estaba pasando la VoIP ¿Porque negártelo? Apunto estuve en adentrarme por la vía física, por consola RS232 (USB-TTL) pinchando en la placa del router, pensé que esa era mi única salida (o terminar con un trágico final, en un callejón sin salida).
Me asusté estando en la posible solución, Daniel Vindevåg cuenta su relato en su servidor ofrecido desde una Raspberry Pi. En resumen; Daniel era miembro de la Asociación Económica de Fibras Södra Kinds la cuál era propietaria de su propia red de fibra para abastecer zonas poco pobladas de Suecia. Es una red abierta, cualquier operador podía participar. Al mando estuvo Net at Once (NAO) y el jaleo empezó cuando Daniel descubrió fallos de seguridad en los dispositivos suministrados por NAO… (cómo el desencriptado del aprovisionamiento).
Le cerraron la conexión y todo acabó el 17 de enero del 2018 cuando perdió el caso ante el tribunal supremo (según cuenta). Para flipar…
Pude pensar que me podría pasar algo similar, pero sé lo que hago y sé que no es malo, es para el bien de la buena salud de la seguridad informática (¡nada que temer!).
Quise probar si era factible realizar la fuerza bruta usando HashCat una vez capturado el hash MD5 con el TAP (como vimos en la Figura 3).
 |
Figura 48: Password crackeado bajo HashCat |
hashcat64.exe -m 11400 -a 3 adamo.hash -1 ?l?u?d ?1?1?1?1?1?1?1?1
La leyenda es: -m indica el tipo de hash, la opción 11400 es SIP digest authentication (MD5) -a el tipo de ataque, siendo 3 fuerza bruta y -1 para elegir que subconjuntos de iteración tendrá cada dígito, aquí le hemos dicho que sea ?l?u?d la ?l (lower) son a-z, ?u (upper) son de A-Z y ?d (digit) es 0-9 luego hay tantos ?1 como dígitos, 8 en total para ir probando.
El adamo.hash es el archivo con el hash en el siguiente formato:
$sip$*[URI_SERVER]*[URI_CLIENT]*[USERNAME]*[REALM]*[METHOD]*[URI_PREFIX]*[URI_RESOURCE]*[URI_SUFFIX]*[NONCE_VALUE]*[CNONCE_VALUE]*[NONCE_COUNT]*[QOP]*[ALGORITHM]*[DIGEST_AUTHENTICATION_RESPONSE]
No cabe duda alguna de que la vulnerabilidad debía ser subsanada. Se ha podido ver otros mecanismos útiles para hacerse con la password SIP (malgastando un poco más de tu tiempo) como el uso de la fuerza bruta. La comunicación VoIP podría encriptarse, pero entraríamos en una discusión similar a la del email y su larga vida, porque si los dispositivos requieren de certificado se vuelve una situación un tanto tediosa para el usuario final (seguridad vs lentitud/performance) y no se llegaría a usar como se ha ido haciendo.
Al final ha ido bien que la consiguiera por mi cuenta para ayudar a hacer de este router un dispositivo más seguro. ¿Y nos contenta el parche? Quizá sería bueno: aprovisionar con la “s” al final de HTTP (HTTPS) en su url, bien también poner algún password adicional, obtenerlo vía sFTP, permitir solo rangos de IP adquiridos por Adamo, que contemple adicionalmente un único User-Agent… la experiencia nos dice que casi todo es rompible, se deben poner barreras, muros para que la penetración al deseado “botín” se haga más difícil (claro que no hay que ser pesimista y las medidas impuestas deben de ser pensadas como inmunes ante ataques, pero no confiarse y no bajar la guardia nunca).
Creo que los de NAO deben tomar ejemplo de Adamo, fijaos que diferencia, descubres algo para mejorar su infraestructura y te lo pagan… quiero decir, que no te pagan, pagas tú. Normal que se geste el miedo cuando alguien descubre algún bug. En mi opinión, para curarse en salud, es cuestión de ir informando al proveedor e ir cooperando, al no ser que pasen mucho de ti, entonces ya es decisión de cada uno la medida a imponer acorde con la situación, tiempo… un castigo que agradecerán si se asume lo cometido.
Agradecer a toda la buena gente de BandaAncha.eu, fijaron mi post del hallazgo en la sección de Adamo (alimentándose por el conocimiento de todos).
Y como pregunta final que formulo; ¿Facilitará Adamo la contraseña de la SIP a quién lo solicite?
Remember…
Be Good, Be Hackers!
Autor: GerardFuguet
