Il me semble également qu'on parle ici de plans sur la comète, essentiellement parce que les infos données ici sont très succintes.
Réflechissons un peu : je vois plusieurs façons d'empêcher le "replay" tel qu'on le fait tous actuellement :

1. utiliser les champs Replay Detection de la RFC 3118 ; typiquement, la valeur actuelle stipule "monotonically increasing value", ce qui implique de fournir le timestamp  courant côté client pour que le serveur le compare après réception et rejette la requête si le timestamp est trop loin dans le passé. C'est assez léger à implèmenter côté serveur, et s'il n'y a que ça à faire pour continuer à envoyer bêtement le même trio user/salt/hash, on devrait s'en sortir, même si ça implique de patcher le client DHCP ou d'en trouver un qui implèmente correctement la RDM.

2. stocker côté serveur les données envoyées par les clients (par exemple les salts). C'est beaucoup plus lourd côté Orange, parce qu'il faut un système de stockage accessible à tous les nœuds DHCP, il faut se palucher la purge des données les plus anciennes, les sauvegardes, etc. Bref, ça commence à faire beaucoup de boulot de leur côté pour pas grand chose. Là encore, ça implique de patcher le client DHCP, avec du code plus compliqué (générer un nouveau salt, etc.) mais ça reste faisable.

3. méthode #1 + déterminer les salts acceptables à partir du login PPP et du timestamp courant avec un algorithme propriétaire... ok, là, ça n'implique pas de stockage côté Orange (un simple calcul permettant de définir si le salt fourni est made-in-Livebox ou non) et côté client, il faudrait se coltiner le reverse-engineering du firmware pour déterminer cet algorithme. C'est un peu le pire scénario catastrophe que je vois pour l'obtention d'un bail DHCPv4.

Pour ma part, je vais regarder comment ça se passe côté IPv6 chez Orange... si c'est plus simple d'avoir une connectivité IPv6 Orange, je peux parfaitement me passer de la connectivité IPv4 Orange...
Edit: bon, le DHCP IPv6 envoie les mêmes infos que le DHCP IPv4 a priori...

Ok, le français n'est que ma deuxième langue. Donc, excuses si ce n'est pas la phrase bien. Mais quelque chose à propos de la nouvelle option-90 md5hash me préoccupe. Orange connaît notre identifiant et mot de passe. Mais à moins que je ne me trompe si la Livebox applique MD5 à RANDCHAR + PASSWORD + RANDSTRING dans son ensemble, elle ne pourrait jamais valider le mot de passe sur le serveur. Comment pourraient-ils obtenir la même chaîne aléatoire? MAIS s'ils ont juste inséré le mot de passe de hachage MD5 entre RANDCHAR et RANDSTRING, ils peuvent alors extraire le hachage du mot de passe et le comparer au hachage du mot de passe créé sur le serveur. Donc je pense que c'est incorrect


commentaires

Ah non non ; si on reprend la description de "gucci gang", on a :

MD5(RANDCHAR + PASSWORD + RANDSTRING)

le password est connu d'Orange, ils n'ont qu'à faire un lookup du username fourni
le RANDCHAR est l'octet juste avant le hash MD5 transmis donc il est connu
le RANDSTRING (salt) est également transmis
Donc Orange a tout ce qu'il faut pour vérifier le mot de passe.
Ici, le MD5 n'est utilisé que comme une approche maladroite pour ne pas transmettre le mot de passe en clair. Sauf que, comme je l'ai signalé dans un autre post, ce mécanisme est très facile à bruteforcer et un attaquant bien équipé devrait pouvoir retrouver le mot de passe originel en 10 minutes.

Ah non non ; si on reprend la description de "gucci gang", on a :le password est connu d'Orange, ils n'ont qu'à faire un lookup du username fourni
le RANDCHAR est l'octet juste avant le hash MD5 transmis donc il est connu
le RANDSTRING (salt) est également transmis
Donc Orange a tout ce qu'il faut pour vérifier le mot de passe.
Ici, le MD5 n'est utilisé que comme une approche maladroite pour ne pas transmettre le mot de passe en clair. Sauf que, comme je l'ai signalé dans un autre post, ce mécanisme est très facile à bruteforcer et un attaquant bien équipé devrait pouvoir retrouver le mot de passe originel en 10 minutes.

Oui c'est l'info qu'on avait au début, et avec tout cela on a tout pour pouvoir "forger" soi-même les requetes et ainsi bypasser la box tranquillement.
Maintenant l'ami Hugues nous apporte d'autres informations...

Bon ça pue tout ça... Des infos que j'ai, on est en periode transitoire avant l'activation du système d'authentification un peu plus agressif, qui interdira le rejeu, et donc, par extension, interdira tout bypass de la box. Pour l'instant, le serveur DHCP ne vérifie pas ce qui est envoyé, mais dans le futur, je ne vois aucune possibilité de bypass ça... :/

(En tout cas, bien joué pour le reverse engineering du firmware ! Mais je crains que ça ne suffise pas)

anglais mais j'aime pratiquer le français

Tu te débrouilles bien 

Oui c'est l'info qu'on avait au début, et avec tout cela on a tout pour pouvoir "forger" soi-même les requetes et ainsi bypasser la box tranquillement.
Maintenant l'ami Hugues nous apporte d'autres informations...

oui ça aurait du sens