Accès Administration Livebox par mot de passe

joseph25b · 23/04/2018 00:11:46

Bonjour à tous

Une question relative à la sécurité renforcée de l'accès aux réglages d'administration de la Livebox 3 (Play) depuis la mise à jour du firmware Orange en 6.33.14.1

Je voulais savoir s'il était possible, via une commande curl par le Terminal, de donner le mot de passe demandé pour sortir de la page d'authentification et accéder à l'interface de réglages de la Livebox à l'url 192.168.1.1

Toutes mes tentatives de passer le mot de passe par une commande curl ont échoué (erreur 52 = pas de réponse de la page), mais peut-être ai-je fait une faute de syntaxe, car je ne suis pas familier de Curl.

D'un autre côté, examinant les propriétés du bouton «connexion», je vois que lui est attaché une procédure "click" à la ligne 12108 du fichier scripts.js lié à l'url 192.168.1.1.

Si c'est effectivement une commande javascript interceptant le "click" physique sur le bouton, qui déclenche l'accès au mode "administration", ça expliquerait qu'une requête curl (donc html) envoyée à ce bouton ne marchera pas.
Quelqu'un peut me dire si je me trompe ou pas, et s'il n'y a pas de contournement possible.

Merci.

Phénix · 23/04/2018 12:59:44

Bonjour.

Je ne suis pas encore passé sur ce firmware, je n'ai donc pas "travaillé" dessus (et je préfère attendre, j'ai autre chose sur l'établi ).

De mon point de vue, déjà essayer de mimer ce qui est fait sur une connexion réelle (capture avec Wireshark si nécessaire) ...
Normalement, tout ce qui est authentification se fait par des requêtes HTTP du type "POST" (s'il y a un & dans l'URL, c'est que c'est probablement fait en "GET" et ça expliquerait que ça ne fonctionne pas).
Le script.js envoie un évènement HTTP, mais ça se simule en rajoutant un paramètre dans l'URL.

Il n'y a pas de raison qu'on n'y arrive pas

joseph25b · 23/04/2018 14:09:12

Bonjour Pénix,

Je viens juste d'installer WireShark, alors de là à ce que je comprenne comment en tirer parti pour ce qui me préoccupe il va y avoir pas mal de tutos à lire et d'essais ratés, mais je ne désespère pas d'y arriver.

J'avais, depuis les outils de dev de Firefox, réussi à faire un "copy as Curl" pour le bouton «connexion», mais je n'ai rien compris au charabia que ça m'a sorti, ni surtout vu une piste de commandes ou paramètres à exploiter.
Je regarderai à nouveau pour faire une requête "Post" (-d)

Sur un tutoriel pour Curl, je tombe sur ce passage intéressant, qui semble tout à fait correspondre au problème que pose maintenant la 6.33.14.1

JavaScript and forms
A very common mitigation against automated "agents" or scripts using curl is to have the page with the HTML form use JavaScript to set values of some input fields, usually one of the hidden ones. Often, there's some JavaScript code that executes on page load or when the submit button is pressed which sets a magic value that the server then can verify before it considers the submission to be valid.
You can usually work around that by just reading the JavaScript code and redoing that logic in your script. Using the above mentioned tricks to check exactly what a browser sends is then also a good help.

Bon, d'un autre côté on n'est pas aux taquets car nos outils pour Mac fonctionnent très bien avec le FW 6.33.14.1, la seule différence avec avant étant que l'utilisateur doit maintenant indiquer (une seule fois au premier démarrage) le modèle de sa Livebox, alors qu'avant c'était le programme qui le détectait tout seul.

Quand j'aurai plus d'informations pertinentes je le ferai savoir.

Cordialement

Phénix · 23/04/2018 21:36:37

Bonsoir.

la seule différence avec avant étant que l'utilisateur doit maintenant indiquer (une seule fois au premier démarrage) le modèle de sa Livebox

Oui, c'est un moindre mal (je comprends que c'est une configuration qui est enregistrée et réutilisée après ...).
Avec tkPyDLB, j'ai tourné un moment comme ça, et notamment quand j'ai eu à automatiser la reconnaissance des LB4), c'est tout à fait tolérable, si ce n'est que ça impose à l'utilisateur qui n'y connait rien de reconnaître le modèle de sa box (c'est pourquoi, dans tkPyDLB, j'avais inséré une image de chaque modèle de LB ...).

Mais je ne suis pas inquiet, on trouvera une solution

Gisapeca · 23/04/2018 21:57:04

Bonsoir,

A défaut de répondre directement à l'interrogation de joseph25b, j'ai, expérimentalement (et modestement), mis en œuvre une solution de contournement dans nos outils Mac, qui s'appuie sur le traitement de l'erreur obtenue si la méthode d'authentification ne correspond pas au modèle de LB utilisé.
Le traitement de cette erreur initialise automatiquement le type de LB.

joseph25b est déjà au courant.

Phénix · 23/04/2018 22:05:31

Salut Gisapeca.

Je suppose (à tort peut-être) que la méthode consiste à dire que, si la page ne répond pas bien à la (une des) méthode(s) usuelle(s), c'est qu'on a affaire à une LB3.
Je crains fort que les prochains firmware de LB4 se basent aussi sur cette nouvelle méthode, et on ne pourrait donc plus dire à coup sûr si l'on est face à une LB3 ou une LB4 (je néglige volontairement les LB2, mais ça pourrait être le cas aussi).
Dans un premier temps, ça convient, mais il faut s'attendre à faire évoluer

joseph25b · 23/04/2018 23:30:32

Bonsoir Phénix,

j'apporte une précision qu’aurait pu faire Gisapeca, puisque nous avons travaillé de concert sur le sujet avec l'auteur des outils de monitoring basé sur Cacti (sur Mac), qui lui a une LB 4 et teste pour nous nos utilitaires quand il ya une évolution majeure du code.

En l'état actuel des choses, les méthodes selon le modèle de LB sont les suivantes :

LB 2 toujours les anciennes méthodes (de type GET)
LB 3 peut indifféremment utiliser la méthode get des LB 2 (qui était aussi la sienne) et depuis je ne sais plus quelle évolution assez récente (la flemme de chercher) sait aussi utiliser les nouvelles méthodes (POST) qui étaient apparues en premier sur les LB 4 quelques semaines avant.
LB 4 uniquement méthodes POST (et sur le principe ça ne devrait pas changer)

À noter que sur les LB pro l'accès aux json est encore différent.

Quant aux LB 2, pas éligibles à la fibre, je ne crois pas que, sauf mise à jour de sécurité impérieuse, Soft@tHome va investir dans son évolution logicielle.

Donc depuis un moment la seule chose qui compte est de reconnaître préalablement si on est en présence d'une LB2, sinon l'autre méthode sera employée, sans qu'on ait besoin de savoir si LB 3 ou 4.

Depuis le passage à 6.33.14.1 pour la LB 3 on ne pouvait plus le faire sans être préalablement identifié, mais Gisapeca vient de mettre au point un "trick" (qui a l'air fiable) basé sur les codes d'erreur retournés par Curl en présence d'une méthode inadaptée.
Du coup ça rend caduque ma question initiale, mais je vais quand même essayer de creuser le sujet… à temps perdu.

@+

Phénix · 24/04/2018 06:24:58

Bonjour.

OK, ça fait donc baisser la pression ...

Bonne journée

Phénix · 24/04/2018 17:57:06

Bonsoir.

Eh bien je suis passé sur le firmware 6.33.14.1 cette nuit sans m'en rendre compte
Et tkPyDLB fonctionne toujours avec cette version (reconnaissance automatique de mon modèle de LB) ...

@joseph25b : Si tu comprends le Python, peut-être peux-tu essayer de t'inspirer des sources ...

Phénix · 24/04/2018 21:21:42

En complément :

Si la page d'accueil impose l'authentification, d'autres sont accessibles sans passer par l'authentification, comme :
- http://192.168.1.1/notConnectedDevices.html
- http://192.168.1.1/freeApplications.html
Elles nous aide à identifier la version :

    config = {
        BUILD_CUSTOMER: 'ft',
        BUILD_PROJECT: 'lbv3fr',
        BUILD_HARDWARE: 'sagem_lbv3',
        SESSION_DURATION: '600'
    };

De même, le "moteur" Javascript est téléchargeable sans authentification également :
- http://192.168.1.1/scripts.js
Ce dernier est certes un peu volumineux, mais il contient deux fois '"HardwareVersion":"SG_LB3_1.2.0"', ce qui peut aussi aider à l'identification.

Ces informations sont vraies sur cette version, rien ne dit que ça le sera sur la prochaine ...

joseph25b · 25/04/2018 22:50:00

Bonsoir Phénix

J'étais pourtant abonné à cette discussion mais je n'ai pas reçu le signalement de ta réponse que je découvre à l'instant Ça m'éneeeeerve !
(J'ai mis un filtre qui laisse passer les email du forum OSG sur gmail, je vais aller voir si les avis de cette discussion sont bloqués ?)

Non, je ne connais pas Python, mais avec toutes les pistes de recueil d'infos sans avoir besoin de s'authentifier,on devrait pouvoir trouver notre bonheur

J'y regarde et te dis ce que j'en tire.
Merci pour les infos et URL.
Cordialement,

joseph25b · 25/04/2018 23:30:50

Re-moi

Phénix a écrit :

Eh bien je suis passé sur le firmware 6.33.14.1 cette nuit sans m'en rendre compte
Et tkPyDLB fonctionne toujours avec cette version (reconnaissance automatique de mon modèle de LB) ...

Bon, même si je ne pratique pas Python, je crois avoir compris pourquoi tkPyDLB a continué à marcher avec la 6.3314.1:
Tu introduits un try dans ta requête
r = requests.get(url, timeout=2)
Qui dans le cas présent doit donner une exception --> version inconnue
que le programme gère ensuite comme une LB2 par défaut (ce me semble)
Or la LB3 supportant les deux méthodes LB2 ou LB4, donc ça passe.
Dis-moi si je me trompe ?

Pour notre programme Mac, je vais plutôt m'orienter vers l'une des url que tu as donné pour y trouver l'info confirmée.

joseph25b · 26/04/2018 00:07:23

Là je cale sur un autre problème :
quel que soit l'url pointant sur une page de la Livebox que j'essaie de rentrer avec Curl, je n'obtiens que du texte illisible car il n'y a pas les entêtes et balises html que l'on devrait trouver :
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr" dir="ltr">

du coup j'ai un retour inexploitable du genre (dans le Terminal)

curl "http://192.168.1.1/homeAuthentication.html"
?x|ZhomeAuthentication.html?ks?6??+?S?=??"Ǔʒn\۹?Ʃ3?|?]???HHbJVR??[<??(??^??d??.?G??h?_?\?????䜢??ߟ?#????Ǿ2:A???;G??F?$?g????N??g&e????r?-?St??(?E?~??D?
e?
??fNY2?!????
???H
*??(fӁC?+????0??

Une idée de ce qui provoque ça ?
Bien sûr, avant la 6.33.14.1, j'avais le retour en html pour l'url 192.168.1.1

Phénix · 26/04/2018 06:11:20

Bonjour.

que le programme gère ensuite comme une LB2 par défaut (ce me semble)

Ben, non ... Sinon, la LB serait reconnues comme LB2, et elle est bien reconnue comme LB3
Et j'ai sniffé avec Wireshark, il n'y a qu'une tentative, avec la méthode LB3/LB4 ...

du coup j'ai un retour inexploitable du genre (dans le Terminal)

Compression (gzip) peut-être ?

joseph25b · 26/04/2018 08:37:35

Bonjour Phénix,

Ben, non ... Sinon, la LB serait reconnues comme LB2, et elle est bien reconnue comme LB3

De toute façon si ce n'est pas LB3/4, c'est LB2 et réciproquement, c'est la méthode que propose Gisapeca. Ensuite même si on donne une valeur fausse pour une LB3, comme elle sait utiliser les deux méthodes (LB 2 ou LB4), la suite du programme avec le parsing des json retrouvera que c'est une LB3.

D'ailleurs, les infos de type de LB en question, on les a directement dans la page http://192.168.1.1/homeAuthentication.html, on les voit dans les outils de dev de FF, par exemple, mais curl ne les retourne pas en clair.

Quant à savoir si le charabia que me retourne Curl est du gzip, il faut que j'y regarde, l'idée ne m'avait pas effleuré.

Bonne journée

joseph25b · 26/04/2018 13:42:45

@ Phénix, bonjour,

Compression (gzip) peut-être ?

Bien vu!

avec cette ligne de commande

curl 'http://192.168.1.1/homeAuthentication.html' | gunzip -f

je retrouve enfin en clair ce passage

config = {
BUILD_CUSTOMER: 'ft',
BUILD_PROJECT: 'lbv3fr',
BUILD_HARDWARE: 'sagem_lbv3',
SESSION_DURATION: '600'
};

Et donc le type de livebox, est affichée sans ambiguïté ni besoin de faire une gestion d'exception lors de la création de la clé de session.

Il n'y a pas de problème sans solution, ou alors ce n'est pas un problème, selon la sage devise Shaddok

Cordialement

Phénix · 26/04/2018 18:25:02

Bonsoir.

De toute façon si ce n'est pas LB3/4, c'est LB2 et réciproquement, c'est la méthode que propose Gisapeca. Ensuite même si on donne une valeur fausse pour une LB3, comme elle sait utiliser les deux méthodes (LB 2 ou LB4), la suite du programme avec le parsing des json retrouvera que c'est une LB3.

J'ai revérifié dans revérifié le code, et l'algorithme est le suivant :
- GET de la page d'accueil (ça doit fonctionner aussi s'il y a une redirection, la preuve dans ton dernier message)
- Recherche de "BUILD_PROJECT:" dans la page obtenue et extraction de la valeur associée
- Si valeur = lbv2fr => LB2
- Sinon si valeur = lbv3fr => LB3
- Sinon si valeur = lbv4fr => LB4 (mais jusqu'à présent, je n'ai pas vu de page où on avait cette valeur)
- Sinon, par catch de l'erreur sur "BUILD_PROJECT:", recherche de "sah=" et extraction de la valeur
- Si valeur extraite de sah= renseigné, LB4, sinon modèle inconnu
En faisant ainsi, je n'ai eu, jusqu'à présent, aucun problème de reconnaissance de modèle ...
Ca peut changer

Et même avec le dernier firmware, l'authentification ne change pas, même si la page d'authentification a changé.

Pour le "gunzip", tu dois pouvoir mettre un header "Accept-Encoding" pour dire que tu n'acceptes pas la compression.
Je suppose que ton cURL envoie le header "Accept-Encoding: *", ce qui veut dire qu'il accepte tout, y compris le gzip.
Tu peux essayer soit de supprimer ce header, soit de le forcer à "Accept-Encoding: identity", ça t'éviterait de décompresser derrière ...

Plus de renseignements sur le header "Accept-Encoding"

joseph25b · 26/04/2018 19:24:28

Bonsoir,

En effet, à part la page d'accueil en accès protégé, tout le reste est inchangé, donc les méthodes qui marchaient avant sont encore valables.
Pur la LB 4 dans nos outils on se sert effectivement de "sah", car il n'y a pas l'équivalent de BUILD_PROJECT pour la déterminer.

Comme tu dis, profitons-en pendant que ça roule avec nos scripts rodés. Si ça doit changer, on avisera…

Je suppose que ton cURL envoie le header "Accept-Encoding: *"

Je vais aller y voir. Il est vrai que Curl est foisonnant de paramètres et possibilités et que je ne m'en sers que de façon élémentaire.
Si on peut éviter la décompression, ce sera ça de gagné, mais on a déjà au moins une manière d'accéder à cette page.

Merci pour le tuyau et bonne soirée.

joseph25b · 26/04/2018 19:49:25

Suite…

Je suppose que ton cURL envoie le header "Accept-Encoding: *", ce qui veut dire qu'il accepte tout, y compris le gzip.

Pour le Curl sur Mac, pas trouvé de "accept-encoding" mais l'option qui fera le boulot est

--compressed
(HTTP) Request a compressed response using one of the algorithms curl supports, and save the uncompressed document. If this option is used and the server sends an unsupported encoding, curl will report an error.

Du coup la commande devient "curl --compressed http://192.168.1.1/homeAuthentication.html"
et plus besoin de pipeline gunzip.

Bonne soirée

Phénix · 26/04/2018 21:10:03

Extrait de la doc de cURL sous Linux (et c'est sans doute identique sur MAC) :

In general, all boolean options are enabled with --option and yet again disabled with --no-option

En clair, si tu envoies "curl --no-compressed http://192.168.1.1/homeAuthentication.html", il ne devrait plus y avoir de compression, mais c'est juste pour le "fun"

joseph25b · 26/04/2018 23:04:09

En clair, si tu envoies "curl --no-compressed http://192.168.1.1/homeAuthentication.html", il ne devrait plus y avoir de compression, mais c'est juste pour le "fun"

Voilà, le fun, c'est le mot juste
parce que avec "curl --compressed http://192.168.1.1/homeAuthentication.html"
j'ai la page qui s'affiche en clair, tandis que

"curl --no-compressed http://192.168.1.1/homeAuthentication.html"
la renvoie compressée.

Ce n'est pas parce que macOS est un avatar de freeBSD qu'il n'a pas ses coquetteries, hein, croire qu'il va s'aligner avec du Linux de derrière les consoles, c'est ruiner son fond de commerce !

Dernière modification par joseph25b (26/04/2018 23:04:51)

Phénix · 26/04/2018 23:08:29

Pas certain que je me soie bien exprimé

Si tu fais :
"curl --compressed http://192.168.1.1/homeAuthentication.html", tu dois le "piper" dans un gunzip, donc écrire
"curl --compressed http://192.168.1.1/homeAuthentication.html | gunzip".

Si tu fais :
"curl --no-compressed http://192.168.1.1/homeAuthentication.html", tu n'as pas à mettre de gunzip "derrière" ...

Je te proposais cette solution pour ne pas avoir à décompresser après récupération de la page, mais ça devient du pinaillage

joseph25b · 27/04/2018 00:03:01

Ne serait-ce pas toi qui a pour motto
On a déjà vu des choses qui ne sont jamais arrivées ...

Alors je redis que si j'appelle la page par
"curl --compressed http://192.168.1.1/homeAuthentication.html", nul besoin de piper avec gunzip, car la page m'arrive en clair.

à l'inverse de
"curl --no-compressed http://192.168.1.1/homeAuthentication.html" que je dois décompresser pour récupérer les données !

Mais j'ai pris la solution qui me dispense de décompresser, je te rassure

Phénix · 27/04/2018 06:17:17

Bonjour.

Ne serait-ce pas toi qui a pour motto

Si

Mais quand on relit bien le man, le comportement est normal :

--compressed
(HTTP) Request a compressed response using one of the algorithms libcurl supports, and return the uncompressed document.

Comme quoi il faut lire ce qui est écrit et non ce qu'on veut lire (et ça vaut pour moi !)

Bonne journée ...

Orange Sans Guigne

Annonce

#1 23/04/2018 00:11:46

Accès Administration Livebox par mot de passe

#2 23/04/2018 12:59:44

Re : Accès Administration Livebox par mot de passe

#3 23/04/2018 14:09:12

Re : Accès Administration Livebox par mot de passe

#4 23/04/2018 21:36:37

Re : Accès Administration Livebox par mot de passe

#5 23/04/2018 21:57:04

Re : Accès Administration Livebox par mot de passe

#6 23/04/2018 22:05:31

Re : Accès Administration Livebox par mot de passe

#7 23/04/2018 23:30:32

Re : Accès Administration Livebox par mot de passe

#8 24/04/2018 06:24:58

Re : Accès Administration Livebox par mot de passe

#9 24/04/2018 17:57:06

Re : Accès Administration Livebox par mot de passe

#10 24/04/2018 21:21:42

Re : Accès Administration Livebox par mot de passe

#11 25/04/2018 22:50:00

Re : Accès Administration Livebox par mot de passe

#12 25/04/2018 23:30:50

Re : Accès Administration Livebox par mot de passe

#13 26/04/2018 00:07:23

Re : Accès Administration Livebox par mot de passe

#14 26/04/2018 06:11:20

Re : Accès Administration Livebox par mot de passe

#15 26/04/2018 08:37:35

Re : Accès Administration Livebox par mot de passe

#16 26/04/2018 13:42:45

Re : Accès Administration Livebox par mot de passe

#17 26/04/2018 18:25:02

Re : Accès Administration Livebox par mot de passe

#18 26/04/2018 19:24:28

Re : Accès Administration Livebox par mot de passe

#19 26/04/2018 19:49:25

Re : Accès Administration Livebox par mot de passe

#20 26/04/2018 21:10:03

Re : Accès Administration Livebox par mot de passe

#21 26/04/2018 23:04:09

Re : Accès Administration Livebox par mot de passe

#22 26/04/2018 23:08:29

Re : Accès Administration Livebox par mot de passe

#23 27/04/2018 00:03:01

Re : Accès Administration Livebox par mot de passe

#24 27/04/2018 06:17:17

Re : Accès Administration Livebox par mot de passe

Pied de page des forums