RootedCon 2023: Crónica del tercer día

 Al llegar el tercer día lo primer que fue hacer acopio de algo de merchandising.

En la sala 25, antes de empezar, presentaron una canción inédita compuesta por un amigo de la asociación y especialmente para RootedCon. 

La primera charla la dio José Manuel Vera (@jmveraortiz): "Hacker memes... ¿En serio?"

RootedCon 2023 - José Manuel Vera

Ha creado una historia enlazando memes relacionados con la seguridad, empezando por la procedencia del término "meme" y cómo se generaron en general. Su conclusión ha sido que para las campañas de concienciación los memes son una muy buena herramienta porque se recuerdan mejor.

La siguiente charla, "Atrápame si puedes" la dieron Lorenzo Martínez (@lawwait) y Juan Antonio Rodríguez (@guardiacivil).

RootedCon 2023 - Lorenzo Martínez y Juan Antonio Rodríguez

Lo primero que hicieron fue presentarse para posteriormente explicar las diferencias y similitudes que hay entre lo que pueden hacer las FCSE y un perito privado: cómo llega el encargo, formalización, cliente (juzgado, fiscalía, privado). También cómo o hasta dónde se pueden adquirir las evidencias y, por ejemplo, que uno privado no puede pedir datos a operadores de comunicaciones y la policía sólo con mandamientos judiciales. También explicaron qué tipos de casos pueden hacer los unos y los otros. Tampoco se han olvidado de la defensa del trabajo, que suele ser en el ámbito judicial: ambos tienen que convencer al tribunal. Después pusieron ejemplos de algunos casos que no salieron todo lo bien que cabía esperar. Algunos por problemas en la cadena de custodia, sospechas de alteración de evidencias (cambian muchos ficheros aunque podrían haber sido solo por actualización de sistema operativo y no el artefacto de interés). Hicieron hincapié en la importancia que tiene si aparecen otras cosas ajenas a la causa que se está investigando. Acabaron con un resumen sobre los informes periciales. "La credibilidad cuesta mucho ganarla y muy poco perderla." 

Cuando acabaron hicimos un muy pequeño descanso porque casi no dio tiempo. Por suerte sí que pudimos disfrutar de unas conchas Codan.

Después, de vuelta en la sala 25, tuvimos la ponencia "Das Bo0T..." por parte de Miguel Haro y Josué González.

RootedCon 2023 - Josué González y Miguel Haro

Han hablado de ciberseguridad industrial. Empezaron presentándose y haciendo una introducción de términos. Lo primero es la seguridad de las personas y lo siguiente la fiabilidad. Nos han mostrado una serie de libros y sistemas virtuales para aprender y probar. Además, diferenciaron entre el uso de malware normal en la industria y el malware industrial (específico para industria). Después pusieron algunos ejemplos de malware,  explicado qué son los gemelos digitales y en qué pueden ayudar o qué aplicaciones pueden tener con respecto a la seguridad: pentest, backups, inventariado, etc. Pero también explciaron los problemas y limitaciones que pueden tener los gemelos digitales. Uno de los ataques que han explicado es EvilPLC.

En cuanto acabaron Jesús Muñoz habló de ataques a redes móviles con "A malicious attacker versus 5G"

RootedCon 2023 - Jesús Muñoz

Hizo una introducción muy rápida sobre telefonía móvil y cómo se conecta un móvil con su SIM a la antena, el servicio y la base de datos de usuarios (SIMs y terminales). También desglosó la seguridad según las generaciones de telefonía móvil para centrarse en el 5G. Uno de los ataques mostrados era contra las tarjetas SIM, preocupante porque es un servicio que se usa muchas veces para la doble autenticación. Uno de los posibles ataques están los clonados de tarjetas pero hoy hay que ponerles unos parámetros muy específicos para que funcionen, entre otros la clave de operador, la cual no se puede obtener (fácilmente). Lo más rápido y fácil es conseguir un duplicado de tarjeta. El siguiente ataque que explicó fue el de hacer una estación base falsa aprovechando SDR. Después mostró en vídeo cómo configuró una estación base falsa y cómo se conectaba un móvil contra esa estación. Se vio cómo la transmisión del móvil se podía ver en claro desde el wireshark que tenía la estación base falsa. Lo siguiente que pudimos ver un ejemplo de GPS spoofing con SDR. 

Al acabar esa charla nos fuimos a comer y a la vuelta regresé a la sala 25, donde Tomás Isasia (@TiiZss y @tisasia) expuso "Firm to the future, firm from the past"

RootedCon 2023 - Tomás Isasia

Lo primero que hizo fue presentarse para después hacer una introducción de lo que nos iba a contar. La primera parte fue explicar cómo surgió la primera firma digital en 1976 y cómo en 1995 apareció la primera CA en España. Hay tres tipos de firmas: simple, avanzada y cualificada (que es equiparable a la manuscrita). Además, la cualificada tiene que tener varias características. Uno dispositivo cualificado puede ser un DNI, pero cada dos años hay que renovar el certificado que guarda o también otro dispositivo puede ser un USB criptográfico que únicamente puede guardar certificados. Nos contó varios formatos existentes; CMS/PKCS#7 (embebido y disociada), S/MIME, orientado a documentos XML o el propio de Adobe basado en PKCS#7 que puede ser una firma o más por fichero. Lo importante es que podría incluir timestamp. También explicó otros formatos: XAdES, XAdES y el PAdES. Continuó contando cómo funciona el proceso de firma y su verificación. La pregutna que se hizo y que le llevó a hacer la investigación era saber si realmente se verifica la fecha y hora que se le pasa al firmar. Por lo que mostró varios ataques conocidos a firmas digitales. Después hizo una serie de demos, entre las que estaba una en la que firmaba un documento con una hora en la que nos estaba hablando en directo y no estaba delante del ordenador. Otras PoC fueron firmar con una fecha anterior a la existencia del certificado o ficheros con firmas cuya fecha y hora están  en el futuro. Finalizó contando las situaciones en las que puede saltar una alerta por la incoherencia entre fechas. Tomás invitó a Lorenzo (Martínez) a que explicara por qué se puede identificar en un forense que se ha aplicado esta manipulación.

Después se hizo una ponencia sobre computación cuántica en la que explicaban cómo afecta a la ciber seguridad, por parte de Mario Muñoz, Gustavo A. Lara, Jesús Domingo y Francisco González

RootedCon 2023 - Mario Muñoz, Gustavo A. Lara, Jesús Domingo y Francisco González

Diferenciaron entre ordenadores corrientes y cuánticos. Los ordenadores cuánticos ponen tener el estado 0, 1 o los dos a la vez, es lo que se conoce como "el principio de superposición". También explicaron en su introducción a la computación cuántica cómo son los estados cuánticos de los "qbits" y cómo suceden. Los ordenadores cuánticos necesitan muchos parámetros para funcionar como tal o en caso contrario acaban dando resultados erróneos. Contaron que mezclar resultados de uno cuántico con la tradicional se le llama "hibridación". Tampoco se olvidaron del rendimiento de estos sistemas, aunque también afirmaron que no es correcto compararlos directamente por el uso al que los cuánticos suelen estar destinados. Después enumeraron algunas limitaciones y retos que tienen estos sistemas. Continuaron con las implicaciones que tienen respecto a la ciberseguridad, como esa afirmación de China que dice que han roto un RSA de 48 bits con un ordenador de este tipo. Tampoco se dejaron en en el tintero algunas consideraciones relacionadas con la seguridad, tanto las buenas como las no tan buenas. Y por último mostraron algunas soluciones que han hecho empresas grandes, haciendo hincapié en Azure Quantum.

Cuando acabaron nos fuimos a descansar media horita.

De nuevo en la sala 25, y antes de empezar la charla, la organización habló de la "hacker night" y dieron los números de cuántos researchers participaron, cómo lo hicieron, etc. 

RootedCon 2023 - Hacker Night

Según nos comunicaron, se encontraron unas 70 vulnerables. Eso sí: todos los investigadores firmaron un NDA antes de empezar el reto. Incidieron en que la calidad ha subido muchísimo con respecto a años anteriores. Además, mostraron los ganadores de un premio en metálico por la calidad de sus informes.

La siguiente charla la hizo Pablo San Emeterio (@psaneme) y se titulaba "Flutter inspection challenges".

RootedCon 2023 - Pablo San Emeterio

Lo primero que hizo fue preguntar si alguien sabía qué es "Flutter", el cual se trata de un framework de desarrollo de aplicaciones para que el resultado sea multiplataforma. Además permite quitar el ssl pinning. Nos habló de genymotion para posteriormente recordar por qué históricamente se empezó a cifrar las comunicaciones (debido al MITM). Después seguió con las técnicas de hooking en la aplicaciones utilizando, por ejemplo, Frida. Continuó contando qué les pasó con una aplicación en genymotion que no se dejaba instalar y cómo también lo intentaron con AVD. Mostró la investigación de cómo instalar Google Play con root en AVD ya que no es posible de forma nativa. Tras conseguirlo vieron cómo el descifrado seguía sin funcionar. Siguió mostrando cómo consiguieron con muchos quebraderos de cabeza descifrar las funciones y el código que había generado Flutter. Después mostró una demo, acabando con las conclusiones.

La última ponencia de esta edición en la sala 25 la hizo David Meléndez (@TaiksonTexas), "Tú no tienes poder aquí: sáltate los sistemas antidron con SDR"

RootedCon 2023 - David Meléndez

Primero se presentó indicando cómo comenzó y cómo le ha estado yendo hasta ahora. Después fue enunciando los distintos usos de drones con un tono muy cómico. Continuó con la detección de drones, como por ejemplo, con visión (tanto por personas como por IA) o su detección vía radiofrecuencia. Siguió describiendo los drones que ha montado y que ya explicó en ediciones pasadas. Para cada uno de ellos fue describiendo las mejoras que les fue añadiendo. Y ahora tocaba una nueva implementación. Expuso cómo ha creado una nueva implementación de modulación y para la que le dedicó mucho tiempo para explicarlo, incluyendo la placa/chip que ha utilizado: MT7628. Después encendió el dron que trajo, y al cual le había atado un cordel largo no fuera a ser que se dirigiera a la pantalla del cine donde estábamos. Tuvo algunas dificultades para encenderlo, a las que le quitaba importancia haciendo chistes y tal situación estresaba mucho a Román. Además, el dron haciendo musiquita mientras estaba arrancando. Cuando hubo encendido y David se dispuso a volarlo, alzó el vuelo dos segundos para inmediatamente después caer a plomo al suelo, con un gran alivio para Román.

Aquí acabó la edición de RootedCon 2023, despidiéndose todo el equipo y voluntarios en el escenario, y a los que espero poder ver el año que viene:

RootedCon 2023 - Equipo y voluntarios de RootedCon 2023

RootedCon 2023: Crónica del segundo día

Antes de entrar a la sala me encontré de nuevo, como ayer, con un antiguo compañero de la empresa donde estoy, Víctor. Ayer no tuve oportunidad de ponerlo aquí. ¡Y de hoy no pasa!

Antes de iniciar la charla Román ha mostrado un montaje del logo del año pasado y algunas BSOs 

RootedCon 2023 - Román Ramirez con el logo de RootecCon 2022

La primera charla, "Ataques bluetooth: de la teoría a la práctica... Hay un trecho " en esta segunda jornada la he visto en la sala 25. La han dado Jesús María Gómez y Antonio Vázquez, pertenecientes al equipo de @Tarlogic.

RootedCON 2023 - Antonio Vázquez y Chema Gómez

Han explicado cómo funciona bluetooth de una forma muy resumida y simple para poder contar su charla: los dos tipos de bluetooth (LE, BR/EDR), host y controler, master y slave... Entre medias han puesto un vídeo "broma". Así, han explicado dos tipos de ataques que no son sencillos de ejecutar: BIAS (suplantación de equipos) y KNOB (un MITM). Uno de los problemas está en el cifrado y el conseguir forzar que la clave de cifrado se reduzca al mínimo posible y además que entre ambos dispositivos se acepte ese tamaño. Después nos han presentado el dispositivo que han implementado, BlueTrust, que consigue hacer un mayor acercamiento a esos ataques y una demo.

La siguiente charla la ha presentado Andrés Soriano (@osintares) y Javier Rodríguez (@Javiover). "HUMINT (HUMan INTelligence) against the hacker".

RootedCON 2023 - Javier Rodríguez y Andrés Soriano

Se trata de obtener información a través de personas, pero no acaba siendo realmente ingienería social. Para conseguir la información o que haga ciertas cosas se pueden hacer varias entrevistas o hacerle ver algunas cosas que le induzcan a pensar cosas que no son ciertas. Por ejemplo, que se crea que va a hacer unos trabajos para las FCSE pero realmente no es así. Muy parecido a las entrevistas de RRHH y headhunters. Han puesto un ejemplo ficticio de una persona que ha pasado del periodo de entrevista, a hacer trabajos, a ver que puede haber algo ilegal a los problemas que eso le acarrea (por ejemplo: paranoia).

Después hicimos un pequeño descanso porque nos pasamos de tiempo. 

De vuelta a la sala 25, Agustín Muñoz-Grades y Álvaro López: "Retos de seguridad en entornos multi cloud"

RootedCON 2023 - Agustín Muñoz-Grandes y Álvaro López

Han hecho una introducción con las diferentes consideraciones de seguridad en esos entornos y las estadísticas que hay con respecto a este tema: incidentes, problemas, costes... También han incidido en los tipos de nubes y ventajas y desventajas de las mismas. Ha mostrado una demo de cómo lo gestionan en Accenture y qué herramientas han montado para llevar a cabo el control y vigilancia de la infraestructura que ellos están usando.

En la siguiente charla, Alejandro Ramos y Félix Brezo han contado su charla "DoubleDragon: la doble extorsión en el post-incidente"

RootedCON 2023 - Alejandro Ramos y Félix Brezo

La expresión "double" es por el cifrado de la información y su exfiltración. Incluso mencionan un tercero: la denegación de servicio. Y han puesto ejemplos bastante mediáticos. Han clasificado el tipo de filtrado: estructurado como las bases de datos o en bruto; ficheros y carpetas tal cual. Se han centrado en estos últimos: qué se han llevado, a qué ya quién afecta, qué es lo más relevante, etc. Y han estructurado distintas fases: identificar los indicios, artefactos como ejecutables sospechosos o extensiones de ramsonware conocidas, etc... Evidencias de datos transferidos... Han mostrado la demo de una herramienta opensource que es capaz de analizar los datos que hay analizar para identificar de una forma más sencilla qué en la estructura que contienen de una forma automática.

Después nos fuimos a comer, entre otros David (@esferared). Y antes de ir a la siguiente ponencia me encontré con Lorenzo (@lawwait) y tuve oportunidad de hablar unos minutos con él.

En la siguiente charla Chema Alonso (@chemaalonso) ha expuesto "Deepfake: are you talking to me?"

RootedCON 2023 - Chema Alonso

Ha recordado ponencias pasadas relacionadas con el deepfake. También ha hablado de cómo se pueden recuperar audios de los altavoces inteligentes. A partir de ahí ha derivado en las distintas pruebas que han hecho con distintos sistemas de IA que han ido apareciendo que permiten clonar la voz y cómo se pueden saltar sistemas de 2FA que usan la voz. Juntando esos audios con otros sistemas de deepfakes de vídeo se puede acabar engañando al espectador. Nos ha enseñado una herramienta que está en desarrollo que intenta detectar si se está ante algún tipo de deepfake o no.

La siguiente ponencia la han dado Antonio Sanz (@antoniosanzalc) y Javier García (@jagaher) titulada "Detecta o muere!"

RootedCON 2023 - Javier Garcia  y Antonio Sanz

Nos han hablado de detección de incidentes, cómo se debería de montar el sistema evaluando y demensionando qué tráfico y cantidad de datos harán falta para poder hacer un análisis. Muy importante usar protocolos como zeek y como mínimo syslog. Es muy importante normalizar los resultados de logs de cada sistema para facilitar el análisis porque nativamente cada uno los genera como quiere. Y muy importante poner en formato UTC las horas y fechas. Asumiendo que se perderán cosas y que habrá falsos positivos que harán perder tiempo, identificar y detectar al atacante. Hay que actuar de acuerdo a lo que se encuentra y reforzar según lo que se va aprendiendo. Para cada una de las secciones que ha tenido la charla han puesto ejemplos de situaciones que han tenido. 

Después del descanso fui a la sala 18, donde Sandra Bardón expuso su ponencia "We are all mad here": cómo crear una infra potente de red teaming.

RootedCON 2023 - Sandra Bardón

Ha empezado contando cómo se debería planificar la infraestructura de un red team. Además de tener que usar varios servidores para cada miembro del equipo por si uno se detecta poder levantar otro rápidamente, también recomienda recompilar el software que se use eliminando/cambiando el user-agent. Lo importante es evitar dejar huella o dejar la menor posible. 

La siguiente y última charla de la sala 18, donde me quedé, la ha dado Antonio José Sánchez (@T0n1sm) y estaba relacionada con clonado de tarjetas RFID.

RootedCON 2023 - Antonio Sánchez

No ha tenido mucho tiempo para exponer. Ha contado los dos tipos de tarjetas que hay según las frecuencias con las que trabajan (13,56 MHz y 125 KHz) y las diferencias entre ambas: si almacenan información, distancias en las que operan, etc. Nos ha mostrado algunos aparatos que son capaces de hacer el clonado y muy por encima algunos sectores y formas de acceder a las claves que almacenan y que son necesarias para hacer los ataques.

Al finalizar han hecho unos sorteos que tenían planeados, momento en el que cerré porque no tenía posibilidad de participar.

RootedCon 2023: Crónica del primer día

El primer día de la RootedCon 2023 ha estado genial.

Hemos empezado con la keynote en la que nos han mostrando un vídeo como introducción. Arantxa ha sido la que nos la ha presentado.

RootedCon 2023 - Arantxa presenta la keynote

Después nos ha explicado Arantxa cómo ha pasado a ser la presidenta de la Asociación que hace en evento, por qué se ha decido este año el logo de Lego y cómo se hicieron las conchas Codan como el "alimento" oficial. Además, ha presentado los premios Raúl Jover 2023 entregándoselos a Chema Alonso el cual ha decidido donar la cantidad en metálico a la Fundación Gomaespuma.

Después empezó la primera charla por parte de Pablo Estévan. 

RootedCon 2023 - Pablo Estevan

Puso la perspectiva de las tecnologías de hace 20 años comparando con lo de ahora: consolas, coches, sistemas operativos... Con la diferencia de que los SIEMs son prácticamente iguales. A excepción del producto de Palo Alto que nos ha presentado; identifica las amenazas automáticamente con la IA que han desarrollado y es capaz de paralizar ese ataque automáticamente. Nos ha mostrado varias demos.

Ya con un buen descanso, David Marrugan  (@radiohacking) y Chema Mezcua (@chemamezcua) nos han presentado "Telecom hacking". 

RootedCon 2023 - David Marrugán y Chema Mezcua

Después de explicar el objetivo de la charla han contado el escenario inicial de Ucrania desde el 2014. Cómo crearon un roaming Nacional de emergencia o cómo se las buscaron para impedir el de los equipos rusos en el país invadido. También se ha explicado el funcionamiento de las comunicaciones de radio, su control y su uso. Entre otras frecuencias mencionadas están las de honda corta. Pero también se han mencionado la posible captura de las comunicaciones por fibra marítima. De ahí ya han explicado cómo funcionan los protocolos de red de los routers: el BGP. Y cómo Rusia se ha aprovechado para, posiblemente, spoofear comunicaciones. 

Tras esta charla, Miguel Ángel de Castro y Jonathan Monroy nos han expuesto el estudio que hicieron a un malware que apareció en unos pinchos USB que se analizaron antes de entregarlos a los accionistas destinatarios. 

RootedCon 2023 - Miguel Angel De Castro y Jonatan Monroy

La primera parte fue un análisis del propio malware con su pequeño reversing. La segunda parte es la que buscaba responder a varias preguntas e identificar si fue un ataque dirigido o accidental, llegando a la conclusión de que fue el segundo. Entre otras se hizo un estudio de la situación geopolítica de China y sus acuerdos internacionales, estado interno, compromiso de cadena de suministros, etc. Con todos los análisis fueron capaces de responder a sus preguntas iniciales

Ya después de la comida, Santiago Anaya y Jorge Testa presentaron "!Por mis profilings!"

RootedCon 2023 - Jorge Testa y Santiago Amaya

Hablan de hacer un perfil del posible atacante del objetivo que se quiere proteger (por ejemplo, un cliente), como método de anticipación. Es el medio que permite identificar qué será lo más probable que será atacado. Han explicado qué te un adversario digital y han analizado cuáles han sido las tendencias de los ataques de los últimos meses. Entre otras, que se siguen usando vulnerabilidades que se darían por parcheadas como algunas de 2010. Han diferenciado tres elementos: actores, herramientas y vulnerabilidades (CVEs). El perfilado, explicado con una serie de pasos, se hace día a día emulando distintos ataques.

La siguiente ponencia la ha hecho Ángela Barriga, y estaba relacionada con los deepfakes.

RootedCon 2023 - Ángela Barriga

Explicó que son y puso varios ejemplos, incluyendo una foto muy antigua. También contó que en estos momentos esta técnica se usa mas como entretenimiento que para manipular a las personas que las consumen. No obstante, puede provocar un problema de identidad digital para las personas que aparecen en el contenido donde se utiliza. También nos ha explicado distintas formas de generar los deepfakes y cómo detectarlos. Ha mencionado dos herramientas que las genera, Faceswap y DeepFaceLab, desglosando el funcionamiento de la segunda. No se ha olvidado de explicar los posibles errores que aparecen en los resultados que se obtienen. 

Después de un descanso me trasladé a la sala 19, donde Yassir Kazar expuso "Don't fear the hacker"

RootedCon 2023 - Yassir Kazar

Después de presentarse ha explicado por qué los hackers son necesarios para la sociedad. También ha mostrado un informe de la ENISA (European Union Agency for Cybersecyrity). Ha mostrado un timeline sobre el uso de la palabra "hacker" en la historia. El fuerte de la charla ha sido la presentación de dos proyectos sin ánimo de lucro. El primero, Hack4Values, en el que se buscan hackers con mucha experiencia trabajando pro-bono. El segundo, Good Faith Cybersecurity Researchers Coalition, en el que si buscando vulnerabilidades en alguna empresa que no te lo ha pedido, se tiene que dar absolutamente toda la información sin pedir nada a cambio (porque si no es extorsión), y sobre todo, respetar los estándares. 

La siguiente charla y última charla de la jornada, también en la sala 19, fue por parte de Lorenzo Martínez (@lawwait). 

RootedCon 2023 - Lorenzo Martínez

Primero ha expuesto los antecedentes del caso, que empezó en 2013. El FBI informó a la Policía Nacional del acceso a una página web de pedofilia desde una dirección IP del hacker llamado "H". Casi 9 años después es cuando se inicia el proceso judicial, el de instrucción. Al pedirle 'H' el peritaje, Lorenzó evaluó si podía aceptar el trabajo de hacer el informe contrapericial emitido por la policía. Nos ha contado qué mostraba esa pericial, con qué ficheros se estaba sustentando la acusación y los errores o fallos de los que cojeaba. También nos ha contado Lorenzo las dificultades que tuvo para poder analizar las evidencias, desde los problemas que daban las que se encontraban en los DVDs que le entregaron para hacer el análisis hasta el disco duro original que contenía las evidencias y con el que pudo hacer otro informe. Con sus resultados finales pudo defenderlos ante el juez en un careo con los peritos de la policía.

Y hasta aquí la primera jornada de la RootedCon 2023. Después de varios años sin venir, ha estado genial.

Hace un tiempo que me instalé una Debian en mi portátil. Pero como este trasto HP Pavilion x360 es un poco especialito no me dejaba configurar la tarjeta de red inalámbrica. Y la verdad me ha costado que a pesar de que sí que aparecía al buscar con comandos como 

# dmesg

O

# lspci -vnn | grep -i 14e4

Al menos estos los tuve que lanzar unas cuantas veces.

También están los distintos drivers e historias que tiene Debian en su repositorio. Eso sí, hay que acordarse antes de poner en el fichero /etc/apt/sources.list el parámetro non-free a la ristra de los que ya tiene la url del repositorio.

deb http://url contrib ... non-free 

Y con 

# apt-cache search broadcom

Instalar los paquetes adecuados. Ahora mismo no los tengo a mano pero eran algunos como broadcom-sta-dkms, broadcom-sta-source, firmware-43-installer o similares. Al final el que te dirá qué módulos te pueden funcionar para tu tarjeta es el comando lspci en la sección Kernel driver in use (aunque realmente no es del todo cierto).

El driver que en mi caso me ocupaba era wl. Pero buscando tanto en los logs como en dmesg o incluso ejecutando 

# modprobe -vv wl

No había manera de que funcionara. Es más, en este último caso me devolvía un error. Por cierto, para el que no lo sepa, las "v" son para que devuelva más información. Un posible error que me salía (he tenido que buscar el ejemplo ya que  no lo documenté):

modprobe: ERROR: could not insert 'wl': Required key not availablemodprobe: ERROR:../libkmod/libkmod-module.c:977 command_do() Error running install command for wl
modprobe: ERROR: could not insert 'wl': Operation not permitted

No recuerdo si era con modprobe, pero sí buscando en resultados del dmesg o journal una línea muy interesante:

Kernel is locked down from Kernel configuration; see man kernel_lockdown.7

Esto viene a querer decir que si se tiene activado el arranque seguro y el driver no está firmado no se podrá instalar. ¿Solución? Los hay que tiran por la calle de en medio: "deshabilita el arranque seguro". Pero hay otra solución. Crear un certificado de firma, instalarlo en la máquina y después firmar el driver. 

¿Cómo creo que certificado de firma?

Me encontré un tutorial bastante interesante en la pregunta de un foro en ITecTec. Y la verdad es que funcionó mucho mejor de lo que esperaba. Pero antes de nada conecta la máquina con un cable de red, actualiza todo el sistema y asegúrate de que tienes instalado linux-headers. Al menos en algún punto me suena que los instalé. Repasando algunas rutas estoy viendo que es muy posible que instalara build-essential y linux-headers-generic. Ya contaré esto último más adelante. Antes de que empieces con lo siguiente: más adelante te tocará preparar un script porque el driver dejará de funcionar cada vez que se actualice el kernel.

Vete a una carpeta. En mi caso hice con el usuario root directamente.

1. Situate en una carpeta fácil y créate una en la que vas a crear los certificados. Por seguir ele ejemplo: module-signing. 
1. # mkdir module-signing
2. Entra dentro de la carpeta:
1. # cd module-signing
3. Ahora crearemos nuestro certificado de firma:
1. # openssl req -new -x509 -newkey rsa:2048 -keyout mok.priv -outform DER -out mok.der -nodes -days 36500 -subj "/CN=Nombre/"
4. Le reasignamos los permisos para que sólo tenga lectura por parte del propietario:
1. # chmod 600 mok.priv
5. Con la herramienta mokutil nos pedirán asignar una contraseña que (parece ser) apenas se usará un par de veces y con esto se instalará el certificado en algún punto de la UEFI:
1. # mokutil --import /rutaCompletaCertificados/mok.der

¿Cómo instalo certificado de firma en la UEFI?

1. Una vez hayas introducido la contraseña apaga la máquina. ¿No te sale el grub por defecto? Tendrás que vigilarlo y hacer lo que siempre hagas para que te aparezca. De todas formas, en este paso debería de aparecerte en la pantalla un menú que nunca has visto. Había un pequeño paso adicional que no indican en el ejemplo y no me acuerdo cuál. Pero una selección por descarte. ¡Ah! Los teclados externos podrían no funcionar.
1. Presionar cualquier tecla cuando te lo pidan si quieres acceder al MOK.
2. Selecciona "Enroll MOK"
3. Selecciona "Continuar" o "Continue"
4. Me suena que en mi caso salió por aquí ese otro paso.
5. Seleccionar "Yes" o "Sí".
6. Introducir la contraseña del certificado.
7. Aceptar para continuar el arranque. Recuerda: si no te suele salir el grub, es posible que te arranque el sistema por defecto y tengas que arrancar tu Linux como siempre lo hagas.

¿Cómo firmo el módulo?

1. Ahora puedes firmar el módulo en cuestrión:
1. /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /rutaCompletaCertificados/mok.priv /rutaCompletaCertificados/mok.der /rutaCompletaMódulo

Con estos pasos ahora si ejecutas modprobe tal y como hicimos al principio del artículo dejará de darte problemas.

Otros cambios realizados

La verdad es que entre medias hice otros cambios que se proponían y que a pesar de que no hacían lo que esperaba creo que también funcionaron bien para otras historias. 

En los parámetros del kernel en el grub puse dos parámetros adicionales:

• pci=biosirq
• acpi_osi= (tal cual. Así es como lo ponían en la página donde lo encontré)

La verdad, no he sido capaz de encontrar qué hacen pero sin estos alguna cosa no acaba de funcionar.

Una ruta interesante en la que se explican los distintos módulos de Broadcom está en Ubuntu. 

Sorpresa

En todo este proceso para instalar los drivers de la tarjeta inalámbrica Broadcom 43142 no sé cómo el se consiguió instalar el grub en el almacén de sistemas operativos accesibles por la UEFI. El problema está en que a pesar de que los ficheros necesarios para poder arrancar el sistema sí que se guardaban en /boot/efi/ el siguiente paso era que la UEFI lo identificara automáticamente y no había manera. Por lo tanto tocaba forzar a darle al F9 en el arranque, navegar por la ruta mencionada y seleccionar el fichero shimx64.efi. El comando que intentaba usar para crear en la entrada que necesitaba la UEFI era algo parecido a

# efibootmgr -c -d /dev/sda -p 3 -L "etiqueta" -l \EFI\"label"\grubx64.efi

Pero como digo, me decía algo así como "el directorio no existe". 

Pues bueno, para resumir, con todo el lío que he hecho para que se inicie la tarjeta de red inalámbrica, la entrada se ha puesto ella solita. Por lo que ahora en el menú de la UEFI puedo indicarle qué sistema quiero que arranque. En mi caso será el grub, que a su vez me permitirá lanzar Windows cuando quiera.

Cómo configurar FreePBX para Masmovil

Después de conseguir el acceso al router Sercomm FG824CD y obtener los datos de acceso al servidor SIP no quedaba otra que configurar mi FreePBX para tirar de este servidor. Así podría quitar (o no) el ATA LinkSys SPA3102.

A pesar de que ya lo he hecho para otros servicios, incluyendo el ATA, el conseguir hacer el "register" me costó mucho tiempo. Accediendo a la consola de asterisk tenía activado el debug:

# asterisk -r
sip set debug [on | trunkName ]

Según el instante lo puse tanto probando con on como con el nombre del trunk entrante (inbound trunk) .
Uno de los manuales principales que me ha guiado ha sido el de ADSLZone. No obstante, como ya decía, no acaba de funcionar del todo.

*** Register ***

Con respecto al register existen distintos formatos:

register => user[:secret[:authuser]]@host[:port][/extension]
register => fromuser@fromdomain:secret@host
register => fromuser@fromdomain:secret:authuser@host:port/extension

Lo siguiente es tener claro cuáles de los todos los valores que fuimos obteniendo se corresponden con esos valores. Porque, y aquí está donde me hice el lío (y la verdad, posiblemente me lo siga haciendo. Pero sabré por dónde van los tiros).

• DigestUserName: e34[teléfono]@evisemad.yoigo.com.
• fromuser@fromdomain: +34[teléfono]@ims.masmovil.com. Como podéis ver, esto es el DigestUserName.
• fromuser: +34[teléfono].
• fromdomain: ims.masmovil.com.

Este es el ejemplo genérico que ponen en el manual:

"DigestUserName":"AuthPassword":"DigestUserName"@[proxy]/[TEL]

Por lo que quedaría algo así:

+34[teléfono]@ims.masmovil.com:[p@$$W0rd]:e34[teléfono]@evimsemad.yoigo.com:5060/+34[teléfono]~3600

Si supierais la de combinaciones que hice pensando que el resultado que me devolvía era un error... Aunque catalogué cada formato no lo hice con los mensajes. Eran los mismos:

[2021-05-30 11:27:39] NOTICE[445]: chan_sip.c:15828 sip_reregister: -- Re-registration for +34[teléfono]@evimsemad.yoigo.com

[2021-05-30 11:27:39] NOTICE[30765]: app_queue.c:9096 reload_queue_rules: queuerules.conf has not changed since it was last loaded. Not taking any action.

[2021-05-30 11:27:39] NOTICE[445]: chan_sip.c:24840 handle_response_register: Outbound Registration: Expiry for evimsemad.yoigo.com is 2390 sec (Scheduling reregistration in 2375 s)

Estas líneas no significaban que el register estuviese mal. Y yo emperrado en que sí.

Lo dicho: tirad del formato que os pongo y os hará que el register funcione.

*** Outbound trunk ***

Esta configuración es la que está relacionada con las llamadas salientes. Aquí la muestra de un error que cometí:

1. fromuser=e34[teléfono]@ims.masmovil.com
2. fromuser=+34[teléfono]

Con la primera opción intenté hacer una llamada que no funcionó. El debug me devolvió el siguiente mensaje de error:

[2021-05-30 11:41:35] WARNING[445][C-0000001c]: chan_sip.c:24304 handle_response_invite: Received response: "Forbidden" from '<sip:e34[teléfono]%40ims.masmovil.com@ims.masmovil.com>;tag=XXXXXXXXX'

Por lo que hice alguna prueba más cambiando ese parámetro en concreto. Así es como en mi caso tengo la siguiente configuración. ¿Qué se podría hacer mejor? Seguro que sí. Pero de momento cumple su función:

type=peer
timeout=3600
sendrpid=yes
secret=[password]
registertimeout=3600
qualify=no
port=5060
outboundproxyport=5060
outboundproxy=evimsemad.yoigo.com
nat=force_rport,comedia
insecure=port,invite
host=ims.masmovil.com
fromuser=+34[teléfono]
fromdomain=ims.masmovil.com
dtmfmode=rfc2833
disallow=all
directmedia=no
defaultuser=+34[teléfono]@ims.masmovil.com
context=from-pstn
authname=+34[teléfono]@ims.masmovil.com
auth=+34[teléfono]@ims.masmovil.com
allow=alaw,gsm


*** Inbound trunk ***

En este caso empecé con los parámetros que se muestran en el manual pero después revisando el debug conseguí no tener que configurar un nuevo trunk.

Hice una prueba muy aproximada de lo que tenían en el manual:

username=+34[teléfono]
type=peer
trustrpid=yes
timeout=3600
sendrpid=yes
secret=[password]
registertimeout=3600
qualify=no
port=5060
outboundproxyport=5060
outboundproxy=evimsemad.yoigo.com
nat=force_rport,comedia
keepalive=30
insecure=port,invite
host=ims.masmovil.com
;host=evimsemad.yoigo.com
fromuser=+34[teléfono]
fromdomain=evimsemad.yoigo.com
dtmfmode=rfc2833
disallow=all
directmedia=no
context=from-pstn
allow=alaw,gsm

Y me devolvio el siguiente error:

[2021-06-04 21:22:13] NOTICE[445][C-00000028]: chan_sip.c:26605 handle_request_invite: Failed to authenticate device <sip:[unMóvil]@[IPAsterisk]>;tag=XXXXXXXXXXXXXXXX

[2021-06-04 21:22:16] WARNING[3337][C-00000027]: app_dial.c:2507 dial_exec_full: Unable to create channel of type 'SIP' (cause 20 - Subscriber absent)

La verdad no recuerdo si encontré otros mensajes diferentes. Pero acabé haciendo otros cambios:

username=+34[teléfono]
authname=+34[teléfono]@ims.masmovil.com
auth=+34[teléfono]@ims.masmovil.com
callerid=+34[teléfono]
type=peer
trustrpid=yes
timeout=3600
sendrpid=yes
secret=[password]
registertimeout=3600
qualify=no
port=5060
nat=force_rport,comedia
keepalive=30
insecure=port,invite
host=evimsemad.yoigo.com
fromuser=+34[teléfono]
fromdomain=evimsemad.yoigo.com
dtmfmode=rfc2833
disallow=all
directmedia=no
context=from-pstn
allow=alaw,gsm

Y ya estaría. Como decía con esta configuración ya no hace falta crear otro trunk adicional tal y como indican en el manual.

Como comentario adicional: he visto este mensaje con la corrección que ahora os contaré. Pero sólo con un teléfono de esos de spam, algo raro porque con mi móvil conseguí que no saliera.

Sólo hay una cosa curiosa que sucede cuando llegan unas llamadas y que tendré que buscar qué parámetro tengo que añadir o qué valor tengo que darle (si es que ya lo tengo en mi configuración). Cuando llegan las llamadas el origen llega con un formato como el siguiente:

[miMóvil];phone-context=+34

También es otra rara: he visto que el teléfono que os decía aparecía sin este formato. 

*** Otros ***

Algunas de las correcciones o búsquedas que hice, además de activar el debug para ver en directo qué mostraba la consola de asterisk al entrar la llamada hice una comparáción desde Wireshark de un tcpdump desde la centralita a la hora de hacer el register con otro .pcap generado por el propio router.

También quisiera comentar que he tenido configurado uno de los teléfonos IP conectados al servicio de VoIP de la operadora y a mi asterisk a la vez. Evidentemente el sistema se liaba: empezaba con la centralita y a los dos segundos saltaba el teléfono y la centralita no acababa de mostrar que se había producido esa llamada. 

Router Sercomm FG824CD VI - Acceso SSH y más

 Antes de empezar con esta sexta entrega en la que se destripa el Sercomm FG824CD:

• Recuerda: cualquier cosa que hagas podría dejar inservible (o no) el dispositivo donde lo apliques. Todo lo que suceda será tu responsabilidad.
• A no ser que el contrato diga lo contrario piensa que el propietario del router es tu operadora. Por lo que ojo que si no tienes cuidado te podrían acabar cobrando incluso el router. Y solo es un ejemplo. O quedarte sin conexión y cobrarte un router un nuevo o... 
• Si no se tiene cuidado se podría estar abriendo el acceso el router al mundo. Mucho ojo cómo se deja y las credenciales que se gestionan en el mismo.
• El resumen es que las manipulaciones que vayas a hacer se tienen que hacer con sumo cuidado y no eliminar ningún fichero ni directorio. 

Siguiente: ¿Os acordáis del proxy que utilicé en la entrega V? Este proxy TR-069 está modificado tal cual lo dejé en la anterior ocasión. El código que hay que añadir está precisamente en ese post. Hay una excepción. Si nos fijamos el paquete trae un fichero llamado injectiondata.xml. En la anterior ocasión ya lo tenía modificado pero no me funcionó. Y hoy revisando algunos resultados me he encontrado con un mensaje de error relacionado con esta inyección. 

<ParameterName>InternetGatewayDevice.X_SC_Management.ShellEnable</ParameterName>

<FaultCode>9800</FaultCode>

<FaultString>Same Parameter Multiple Times</FaultString>

Lo que me ha forzado a revisar el fichero que permite hacer la inyección. Y en efecto así era. Por lo tanto le he cambiado el ParamName:

</ParameterValueStruct>

<ParameterValueStruct>

    <Name>InternetGatewayDevice.X_SC_Management.ShellEnable</Name>

    <Value xsi:type="xsd:boolean">1</Value>

</ParameterValueStruct>

<ParameterValueStruct>

    <Name>InternetGatewayDevice.X_SC_Management.AccessControl.SSHStatus</Name>

    <Value xsi:type="xsd:string">Enabled</Value>

</ParameterValueStruct>

<ParameterValueStruct>

    <Name>InternetGatewayDevice.X_SC_Management.AccessControl.SSHMode</Name>

    <Value xsi:type="xsd:string">LAN</Value>

</ParameterValueStruct>

<ParameterValueStruct>

    <Name>InternetGatewayDevice.X_MASMOVIL_COM.Users.User.2.Permission</Name>

    <Value xsi:type="xsd:string">web,cli,ftp,smb</Value>

</ParameterValueStruct>

<ParameterValueStruct>

    <Name>InternetGatewayDevice.X_MASMOVIL_COM.Users.User.2.Group</Name>

    <Value xsi:type="xsd:string">admin</Value>

</ParameterValueStruct>

<ParameterValueStruct>

Aunque son casi autoexplicativos aquí estamos haciendo lo siguiente:

• Habilitamos la shell. No he probado a ponerlo a disabled. Pero entiendo que es dar acceso a tener una shell en caso de ser necesario.
• El SSHStatus nos permite habilitar el servicio para el ssh.
• El SSHMode: este es importante. Al recuperar los resultados del TR069 he visto que ServerNameMode puede tener: wan, LAN, ALL y none.
• Permisos: por defecto el admin tiene web,cli y 1234 tiene web,ftp,smb.
• El grupo de User.2 se le asigna a admin. Que da la casualidad que es el mismo nombre que el principal admin.

No añadas ni quites ramas si quieres que funcione tal cual. En el caso que quieras inyectar más o menos parámetros tendrás que hacer cambios en el fichero app.py. Busca la cadena cwmp:ParameterValueStruct[7] y sustituye el 7 por el valor que corresponda: 2 + númeroDeRamasAInyectar.

Una vez tengas configurado este fichero sólo queda ejecutar el proxy y configurar el cliente TR069 tal y como expliqué en el anterior post. En cuanto se vea que se han aplicado por completo los cambios mirando los datos que devuelve la consola donde estamos ejecutando el proxy ya lo podemos parar. A partir de aquí podremos buscar la contraseña del administrador por si nos la han cambiado ya que nos hará falta. No obstante el usuario 1234 también sirve.

En mi caso lo primero que he hecho ha sido lanzar un nmap contra mi router:

nmap -sS -sV -O -vvvv -T4 10.0.0.1

Obteniendo como resultado los típicos servicios del DNS, HTTP(S) y UPnP:

Sercom FG824CD - nmap: SSH, dns, http(s) y UPnP

Además de conseguir elevar privilegios para el usuario 1234 la idea era tener acceso por ssh. Y así ha sido. Para iniciar sesión toca poner el usuario y la contraseña pero después recarga la consola y vuelve a pedirla. 

Sercomm FG824CD - Accediendo por ssh

Lo que ya nos permite identificar el menú de ayuda. Entre otros la shell inicial donde nos muestra el menú de ayuda para saber cómo interactuar con el router. Aunque ya he trasteado un poco el que podría ser el más importante de todos que evidentemente es sh dándome la posibilidad de interactuar directamente con el sistema tampoco me ha parecido mal después mirar el resto de opciones con detenimiento antes de volver al sh:

Sercomm FG824CD - Menú en el ssh

Para cada uno de los menús por donde he estado yendo he ejecutado quit para regresar al menú anterior. De momento lo más interesante que me he encontrado ha sido en el menú net donde he podido ejecutar ifconfig e iptables -L. De hecho, el de iptables ha soltado tal cantidad de datos que he acabado cancelando.

Con respecto a ps me he encontrado con que algunos servicios se están ejecutando con permisos del usuario superadmin que además me lo he encontrado en algunos ficheros cuando estaba cotilleando en con la shell. Y será objeto de más análisis. De los procesos que me muestra están el servidor http mini_http y dnsmasq, 

El comando show devuelve un menú para recuperar más información del sistema. No obstante es como si mezclase la ayuda con la descripción:

Sercomm FG824CD - ssh - comando show 

Ahora sí que sí he estado revisando el árbol de directorios:

Sercom FG824CD - ssh - ls /

Una vez he tenido la posibilidad de navegar por el árbol de directorios me he encontrado con que hay algunas rutas que tienen enlaces simbólicos a /tmp/ como por ejemplo la carpeta de /etc/samba o /mnt/shares (). Aunque verificándolo también tenemos a algunos en /var/ como por ejemplo /etc/resolv.conf o /etc/passwd.

Una sorpresa que me he llevado ha sido que al buscar con el comando mount qué estaba montado para hacer un dd (que también viene por defecto en el router) es que son varias memorias flash (mtdblock) las que están montadas. No obstante no me ha acabado de gustar cómo lo mostraba y se me ha ocurrido mirar el resultado con df:

Sercomm FG824CD - ssh y df

Además de hacer distintas imágenes de esos dispositivos guardándolos en el pincho USB que se encuentra en /dev/sda1 alguien podría decir que con sólo un cp -R serviría. Pero nos podríamos encontrar con que habrá ficheros que perdamos porque haya permisos que nos lo impidan aunque seamos administradores. O que al estar en uso dé un error y no podamos continuar. O que nos pasemos de listos e intentemos hacer una copia recursiva con resultados insospechados. No obstante si se quiere probar... 

Al intentar recuperar /dev/root la primera en la frente: no existe o no lo muestra como tal. He encontrado que con el comando lsblk me podía ayudar y así ha sido:

Sercomm FG824CD - Rutas de montaje con lsblk

Sólo hay una ruta que no me está dando y es la de tmpfs. Revisando una vez más /etc/fstab parece que le indica que se monte en /dev/shm en vez de /tmp. Aunque después sí que se ve en es última ruta. Y es que según indican en fstab precisamente esa carpeta se borrará cuando se reinicie el router.

De momento he hecho el dd para cada una de las memorias flash que he identificado exceptuando el de tmpfs que da la casualidad que es el que más espacio tiene:

Sercomm FG824CD - Volcado dd de sus memorias

Sabiendo que la carpeta donde se montan los pinchos USB es un enlace simbólico que se dirige a /tmp:

Sercomm FG824CD - Comparación /mnt/shares con /tmp/shares

se me ha ocurrido probar a desmontar el pincho y montarlo en la carpeta /mnt/nfs que ya existía pero no tenía ningún dispositivo montado. Esto me ha evitado tener que crear una nueva dentro del sistema de ficheros del propio router manteniendo la regla de no añadir ni eliminar cosas del aparato:

Sercomm FG824 - ssh: Montar y desmontar pincho usb en otra carpeta

A pesar de que en la captura esté usando el comando mount hay que usar la siguiente instrucción dado que en caso contrario daría problemas a la hora de que se copien los ficheros y las carpetas:

# ntfs-3g -o rw,uid=0,gid=0,umask=000,iocharset=utf8,use_ino,direct_io,big_writes /dev/sda1 /tmp/shares/sda/A

# cp -aR /tmp /mnt/nfs/routerFS/carpetaTmp

Con esto ya tendría la copia de casi todo el contenido del router a excepción del proc y alguno que otro más. De momento estas son las cosas que he ido viendo ya sea desde la propia consola o analizando los ficheros que copiado. 

VoIP

La configuración del VoIP se encuentra en la ruta /var/voice/voip.conf. Además de los datos de autenticación, servidores, tiempos de espera, etc tiene una sección o ámbito donde muestra qué dispositivo se está conectando. Otro dato curioso es que indica con qué tarjeta tiene que conectarse al servicio. En mi caso muestra nas0 que se correspondería con la tarjeta HSI que nos muestra la interfaz web. Por lo que si hubiera escogido la LAN que creé (recuerdo: realmente debería de ser algo así como WANaux o similar: pero no confundir con la que se pone en la inyección del TR069) debería de salir nas1.

Hay un fichero llamado voip_ver en /etc/ pero la verdad sólo muestra eso, una versión y ya. 

Cliente DNS

Una de las cosas que más me ha llamado la atención es que el fichero enlace simbólico /etc/resolv.conf sólo tiene una entrada

nameserver 127.0.0.1

En este caso quería modificarlo para poner un servidor DNS de verdad. Recuerdo: mucho ojo con lo que se toca. No obstante es un fichero de sólo lectura por lo que no ha sido posible. 

Aún así en /var/resolv.conf, la ruta original de ese enlace símbolico,  he probado a machacar sus datos 

echo nameserver ipDNSInterno > /var/resolv.conf

Sin muchos resultados.

Samba

Como hemos visto el problema con SMB es que sólo monta los dispositivos USB en una carpeta que además hace prácticamente de chroot: /mnt/shares/sda/A/. No obstante en /etc/samba.conf/ tenemos el fichero de configuración smb.conf que a su vez nos llevaría a otro en /var/samba/smb.conf si no llegase a ser porque no existe. Además es muy curioso encontrarse con que este primer fichero pone el nombre de la competencia; Vodafone:

Sercomm FG824CD - Configuración samba / SMB

En mi caso he creado el fichero que tendría que estar en /var/samba/. Pero no existe. Después de haber intentado crear uno con la siguiente configuración:

[raiz]

comment = Raiz

path = /

browsable = yes

guest ok = no

read only = yes

Y de ejecutar el servicio

#smbd

#nmbd

No he obtenido resultados. Por lo que he decidido hacer pruebas creando varios logs como el siguiente 

# ps -A > /mnt/nfs/salidaPS.txt

Y desde la interfaz web activar el servicio de compartir por Samba. Así quería verificar qué qué procesos se añadían. Pero no he visto ninguno nuevo. Eso sí, me ha machacado mi /var/samba/smb.conf con una configuración muy similar a la que se encuentra en /etc/samba.conf/. Lo único que también tengo que añadir una línea más a la sección [global]:

min protocol = SMB2

protocol = SMB3

Porque en caso contrario Windows no permite acceder al servicio. Y si yo fuera vosotros haría una copia de seguridad del fichero de configuración por cada cambio porque está claro que se borrará cada vez que se manipule desde la interfaz web. Más ayuda sobre la configuración del protocolo mínimo de samba en este enlace. Lo único que me sigo encontrando con que estas opciones no acaban de surtir efecto. Será cuestión de seguir haciendo pruebas. 

SSH

El fichero de configuración está por defecto en /etc/ssh/sshd_config. Por lo que he podido ver no tiene mucho misterio: acceso permitido para root o contraseñas vacías, las HostKeys guardadas en /data/2/

Poco más puedo contar al respecto.

FTP

Por lo que he podido ver el dispositivo trae vsftpd. He intentado localizar los ficheros de configuración sin éxito. Al menos hasta que no lo he habilitado con la interfaz web. Y una vez más, se han creado ficheros que antes no existían. Entre otras rutas interesantes se han creado las carpetas y ficheros en /tmp/ftps y /tmp/ftp. 

Mirando el contenido de los ficheros del ftps todos están vacíos. Con respecto al de ftp si queremos recuperar más información también nos tocará habilitar el usuario desde la web para poder ver más fichero y datos. 

Del fichero vsftpd.conf  podemos recuperar cosas interesantes como por ejemplo:

• secure_chroot_dir=/tmp/ftp/ftp_empty
• anonymous_enable=NO (a pesar de que InternetGatewayDevice.Services.StorageService.1.FTPServer.AnonymousUser.Enable está a true)
• syslog_enable=NO

Además en el fichero /tmp/ftp/vsftpd_user/1234 se muestra 

local_root=/var/ftp/1234

Que si se visita tendremos la siguiente ruta:

/var/ftp/1234/A/

Ese /A/ es precisamente lo que nos muestra al acceder con un cliente FTP.

Además he encontrado el fichero /usr/www-ap/data/settings_ftp.json el cual está vacío. 

Servidor DNS

Me sorprende que al hacerle un nmap al router me devuelva que tiene un servidor DNS pero en la interfaz gráfica no "haya" una forma clara de gestionarlo. 

Por lo que estoy viendo en /tmp/dnsmasq.servers.d/ hay una serie de ficheros .conf que muestran un DNS interno que ya puse hace un tiempo desde la interfaz web pero que me parecía que no estaba funcionando. 

Como hay ficheros que no se pueden modificar por sus permisos (y algunos no son de lo común como la S del stickybit) no he sido capaz de avanzar en este ámbito sin toquetear más allá de lo que quería. 

Ficheros de configuración

Mientras he estado navegando por el árbol de directorios me he encontrado con varios ficheros que parecen que pueden estar relacionados con las configuraciones que posiblemente se carguen al seleccionar las opciones de "restaurar de fábrica" o "cargar configuración almacenada en el router". 

• /etc/default.xml
• /usr/www-ap/settings_page/configurationBackup.cfg el cual es un enlace a /tmp/configuration.cfg y que en esa ruta no existe.
• /tmp/config/config: Hay partes de su contenido que están en claro junto a otras que parecen cifradas: es un fichero xml. En él se pueden ver cosas como admin, encrypted (¿a false a pesar de que parece que sí que lo está?), direcciones IP...

Hasta ahora no he podido averiguar si hay alguna forma de descifrar el contenido ni cómo lo genera. 

HTTP(S)

Este es uno de los aspectos más importantes del sistema ya que es el que permite administrar servicios y configuraciones que de otra forma y sin más conocimiento no podríamos modificar. La ruta /user/www-ap/ es donde está localziada toda esta chicha. 

Uno de los datos que he podido comprobar es que los ficheros .json que he abierto están vacíos a excepción de la cadena "[]" (sin las comillas). Recuerdo que esos ficheros son los que después se utilizan para rellenar algunos datos de la interfaz web cuando navegamos por ella. 

Sercomm FG824CD - Direcotrio www - Carpeta de la administración web

En la carpeta activation_page parece que hay una serie de pagínas .html que están destinadas a la primera configuración. Lo único que realmente cuando nos lo entregan no nos lo ofrece. Si visitamos una de esas página se puede apreciar que están destinadas a incluirse en una página superior por eso de los estilos:

Sercomm FG824CD - Contenido de activation_page

Estas páginas no están en orden. Y tampoco voy a ponerme a hacer pruebas. Recuerdo que es el router que me da la conexión y eso iría m ás allá de configurar el aparato que hay que devolver a la operadora.

Si quisiéramos ver el contenido de los ficheros .log y .csv que están en raíz no podríamos porque una vez más nos avisa de que no existen: son otros enlaces simbólicos que también dirigen al fichero esperado en /tmp/.

También he tenido la curiosidad de qué me encontraba en los ficheros de configuraciones que no se muestran en la interfaz web. Por ejemplo en settings_iptv.php o settings_adsl_settings.php o settings_umts.php... También me he llevado la sorpresa de que algunos (y sólo algunos pocos) ficheros .json en efecto sí que tienen contenido. 

Buscando ficheros interesantes he visto que fromCompRestore.php hace referencia a la ruta "../upload/settings_configuration_restore.zip". El problema está que los únicos ficheros que me aparecen al buscar ficheros .zip es que sólo me aparecen los que tengo en el pincho USB y no tienen nada que ver con las copias que hice del router.

Tengo que seguir estudiando la aplicación web. Pero antes de acabar me quedaría comentar que el fichero /usr/www-app/upload.cgi se usa al menos para subir los ficheros de respaldo. Por lo que me quedaría por dedicarle un buen tiempo para ver si soy capaz de estudiar este fichero y a la vez ver cómo ejecuta la recarga de la copia de seguridad. Del mismo modo estudiaré el contrapuesto, download.cgi. Aunque a ojos vista me parece que tiene menos datos.