Petit complément rigolo concernant la possibilité de retrouver le mot de passe originel par bruteforce à partir de l'option 90 : une fois le préfixe (1 caractère), le suffixe (16 caractères) et le hash MD5 extraits de l'option 90, le bruteforce sur une machine moderne est une formalité.
Exemple avec :

• le préfixe A
• le suffixe SALTSALTSALTSALT
• le hash MD5 67160e9d535f08670f3b739e93d455c5

$ echo 67160e9d535f08670f3b739e93d455c5 > /tmp/hashfile
$ time hashcat --optimized-kernel-enable --hash-type=0 --attack-mode=3 --custom-charset1='?l?d' /tmp/hashfile 'A?1?1?1?1?1?1?1SALTSALTSALTSALT'

hashcat (v6.2.6) starting

OpenCL API (OpenCL 3.0 PoCL 5.0+debian  Linux, None+Asserts, RELOC, SPIR, LLVM 17.0.6, SLEEF, DISTRO, POCL_DEBUG) - Platform #1 [The pocl project]
==================================================================================================================================================
* Device #1: cpu-skylake-avx512-AMD Ryzen 7 7840HS w/ Radeon 780M Graphics, 28985/58034 MB (8192 MB allocatable), 16MCU

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 55

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Optimizers applied:
* Optimized-Kernel
* Zero-Byte
* Precompute-Init
* Meet-In-The-Middle
* Early-Skip
* Not-Salted
* Not-Iterated
* Single-Hash
* Single-Salt
* Brute-Force
* Raw-Hash

Watchdog: Temperature abort trigger set to 90c

Host memory required for this attack: 4 MB

67160e9d535f08670f3b739e93d455c5:Apx4fuegSALTSALTSALTSALT

Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 0 (MD5)
Hash.Target......: 67160e9d535f08670f3b739e93d455c5
Time.Started.....: Sat Jun  8 15:28:51 2024 (21 secs)
Time.Estimated...: Sat Jun  8 15:29:12 2024 (0 secs)
Kernel.Feature...: Optimized Kernel
Guess.Mask.......: A?1?1?1?1?1?1?1SALTSALTSALTSALT [24]
Guess.Charset....: -1 ?l?d, -2 Undefined, -3 Undefined, -4 Undefined
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:  2117.3 MH/s (1.49ms) @ Accel:1024 Loops:256 Thr:1 Vec:16
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 43804786688/78364164096 (55.90%)
Rejected.........: 0/43804786688 (0.00%)
Restore.Point....: 33783808/60466176 (55.87%)
Restore.Sub.#1...: Salt:0 Amplifier:1024-1280 Iteration:0-256
Candidate.Engine.: Device Generator
Candidates.#1....: Ag7tjuegSALTSALTSALTSALT -> A2zspcobSALTSALTSALTSALT
Hardware.Mon.#1..: Temp:100c Util: 89%

Started: Sat Jun  8 15:28:50 2024
Stopped: Sat Jun  8 15:29:13 2024

real    0m22.989s
user    4m45.080s
sys     0m3.339s
En 23 secondes, hashcat a déterminé que le hash MD5 correspondait à Apx4fuegSALTSALTSALTSALT
Et pour cause : à raison de 2 GH/s, les (26+10)⁷ = 78 364 164 096 combinaisons possibles ne devraient pas tenir plus de 40 secondes.

- tout les comptes system en /bin/null (impossible de se log, y compris en ssh)

Je pense que tu voulais dire /usr/sbin/nologin ou /bin/false.

- utilisation d'un password ultra complex / ultra long qui n'est utilisé qu'en cas de problème avec la clef ssh

Je dirais plutôt : qu'en cas de problème avec la conf réseau qui rend sshd injoignable (j'y ai eu droit récemment).

Je te rejoins sur tous les autres points.

@Mastah @xavierg :

J'ai lu un livre sur ce type de sujet.

La sécurité c'est durcir au possible la tâche d'un attaquant potentiel. Ne pas abandonner le contrôle de son système en cas de compromission.

Tu parles d'une machine chez toi. Unplug le rj45, problème réglé
Tu fais un poil dans l'excès de zèle

En sécurité, par contre, il y a toujours une analyse de où se trouve la donnée et comment on la récupère. [...]

Entièrement d'accord. Ici, j'ai fait tourner hashcat pour bien démontrer à basilix qu'il était possible de récupérer l'utilisateur et le mot de passe Orange à partir de l'option 90.
La récupération de l'option 90 elle-même peut se faire :
- théoriquement en sniffant le réseau, mais en pratique je ne vois pas de positionnement qui rendrait cette option abordable sur les plans opérationnel et financier.
- en pratique par attaque sur le routeur. Par exemple, on pourrait imaginer que le routeur expose un service sur Internet (on est dans la section "Remplacer la LiveBox par un routeur" mais il faut bien voir que c'est aussi la section "Remplacer la LiveBox par toute autre forme d'ordinateur") et que ce service soit vulnérable à une RCE à un instant t. À partir de là, soit le fichier contenant l'option 90 est world-readable, soit un composant (kernel ou service exécuté en root) est vulnérable et tout le routeur tombe sous le contrôle de l'attaquant, rendant l'accès à l'option 90 trivial.

À ce stade-là, l'attaquant possède l'option 90, donc les credentials Orange du propriétaire du routeur et... et je ne sais pas. Je ne sais pas à quoi ça sert de voler ces identifiants. Je ne crois pas qu'on puisse les utiliser pour du social engineering, je ne pense pas qu'ils suffisent à usurper l'identité d'un autre client Orange... peut-être sur le moment, mais une enquête interne pointerait le décalage entre l'adresse connue de l'abonné et la ligne physique utilisée pour présenter ces credentials.

D'où ma recommandation de veiller aux permissions Unix des fichiers contenant les credentials et/ou l'option 90, parce que ça ne coûte quasiment rien et que ça devrait être un réflexe systématique en présence de secrets/credentials. Mais je ne pense pas que les credentials Orange méritent plus d'efforts que cela.

Je publie un vidage hexadécimal fictif de l'option 90 pour mieux illustrer les choses : j'ai ajouté des valeurs pour faire vrai.

Pour quoi faire ?

J'aurais voulu implémenter l'option d'authentification (90 ou 11) dans le serveur odhcpd de OpenWrt. L'algorithme de vérification côté serveur est similaire à l'algorithme de génération.
Le serveur peut recalculer le code de hachage via le mot de passe du client (login) et le comparer avec celui embarqué dans l'option du message.

En soi, ce n'est pas indispensable. Cela me servira potentiellement d'entraînement.

---

0000   5a 46 00 00 00 00 00 00 00 00 00 00 00 1a 09 00
0010   00 05 58 01 03 41 01 0d 66 74 69 2f 6c 6f 73 73
0020   70 75 6e 3c 12 6a 74 54 59 38 58 56 67 26 73 4b
0030   6a 5e 2c 65 7d 03 13 5c 6e 34 11 39 39 c0 58 e8
0040   88 83 8f d7 42 a6 36 bb

0000:         Code: Authentication: (90) 0x5a
0001:         Length: (70) 0x46
0002:         Protocol: configuration token: (0) 0x00
0003:         Algorithm: (0) 0x00
0004:         Replay Detection Method: Monotonically-increasing counter: (0) 0x00
0005,000C:    RDM Value: (0) 0x0000000000000000
000D,0047:    Authentication Information: 0x1a0900...

login: fti/losspun (id) [0018,0022]

char: \ (1 random byte) [0037]
password: dbagapp [database]
string: jtTY8XVg&sKj^,e} (16 random bytes) [0025,0034]

Hash code: 0x6e34113939c058e888838fd742a636bb [0038,0047]

md5sum(\dbagappjtTY8XVg&sKj^,e}) => 6e34113939c058e888838fd742a636bb

md5sum(char+passwd+str)

(hash_code == md5sum(...)) ? Good : Wrong ;

---

Pour la petite info, j'ai fait un petit programme pour ca aussi. Histoire de pouvoir l'intégrer dans un script dynamique de configuration dhcp.

De ce que j'ai testé, il se comporte de facon identique à celui de Keith Gersen.

De mon côté j'ai pas encore un setup fonctionnel et j'ai pas trop eu le temps de pousser plus loin mais *normalement* c'est clean niveau option 90/raw-11: https://github.com/OtaK/orange-option-90-generator

(la logique est ici)