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.
