Je vais décirer le process pour les box ADSL de Bouygues Telecom qui se connectaient sur un réseau PPPoE (la collecte Orange dans le passé).

Les box ont un login / mot de passe générique dans le firmware qui leur permet d'entrer dans un "walled garden".

Ce "walled garden" permet a la box de contacter l'ACS (Auto Configuration Server). L'ACS va mettre à jour et provisionner la box qui redémarre avec son login et son mot de passe personnel et se connecte au réseau Internet.

Pour avoir déjà été coincé dans le "walled garden" avec une box non provisionnée dans l'ACS, on n'a accès à strictement rien avec l'IP privée envoyée.

Bref, un dispositif "unprovisioned" sécurisé est tout à fait possible.

[/list]L'étape 3 est importante car le modem est quand même connecté, et les identifiants doivent être rentré dans un browser a l'url suivante http://selfactivation.skylogicnet.com:8080/, et la si je devais foutre la m**** je creuserai la pour voir à quoi exactement on peut accéder quand le modem est connecté à ce réseau (il récupère une adresse en 10.0.0.0/8 à ce moment la de mémoire).

Je confirme ce fait.
Mais bon, on fait beaucoup d'hypothèses, ici , sur la méthode d'intrusion. Quelque soit la méthode utilisé et quelque soit la négligence de viasat sur la sécurité de son réseau, on reste sur un service grand public , avec du matériel du même accabit (même pour les version "pro").
La preuve d'autres services sur le même sat n'ont pas été touchés , cf les articles passés ici même. Même si dans le passé j'ai trouvé le service cher pour ce que c'était (les premiers abos que j'ai eu, chez Connexion Verte puis Europasat / BigBLU , c'était 90€ / mois pour 25Go de data avec la FAP qui s'activait après 250Mo (!) downloadé en moins de quelques minute), on reste sur du grand public. 

Attendons, j'espère un jour, le post-mortem.

C'esrt quoi la FAP ? Fair use ?
Si tu as 25 Go de data, le fair use, c'est après 25 GO, pas 250 Mo, non ?

FAP = Fair Use Policy.

Ce fut un grand débat à l'époque de la mise en place du ka-sat, car les règles n'ont _jamais_ été claires pour tout le monde.
Typiquement, les règles données aux abonnés en UK étaient plus précises que les règles de FAP françaises, sans pour autant spécifier les limites exactes. elles disaient disaient simplement, en gros, "en cas d'abus, on s'autorise à réduire le débit", sans rien préciser d'autre.
On est pas _du tout_ dans le monde du mobile.

Donc à l'époque, il y a eu des threads de forums complets de gens qui comparaient leur trafic pour essayer de comprendre ces fameuses règles, qui en plus changeaient de temps en temps sans qu'on en soit notifié en tant que clients (et oui, c'est la magie des sociétés européennes personne ne sais ce qui s'applique, et qui va aller au tribunal pour assigner.... qui ? Le FAI ? Viasat ? Eutelsat ? )

Donc en gros, par essais et erreurs, autour de 2013 il y avait 3 "classes" d'usagers :
1) Prioritaire :
    Dans l'enveloppe du forfait (donc moi 25Go, puis passé à 50 plus tard) , usage "familial" , cad web/mail : Plein de petites connections courtes, pas de trafic "continu".
       (D'ailleurs dans la doc il y avait marqué de désactiver les vidéo, ne pas télécharger, ne pas faire de mises à jour)

2) Hors-forfait :
    Dépassement du forfait. Débit limité à 250kbps (et plus tard 1Mbps) , mais les mêmes règles de type de trafic s'appliquent.

3) High-bandwidth user:
    Lorsque en 1) ou 2) on lançais un téléchargement considéré comme "abusif" , comprendre "long" . C'est à dire que le débit du modem était soutenu à , par exemple, 22Mbps dans mon cas, ou 250kbps dans le cas 2) , pendant un temps qui a été très variable. Ça peux être une vidéo, mais aussi , et ça a été très compliqué à comprendre pour les gens, les mises à jours des appareils. Marche aussi en SCP, rsync, .... et bien sur en UDP aussi.
    Alors là, tu es "puni" de ce comportement abusif, et on te colle dans cette classe pendant 7 jours.
    Dans cette classe , non seulement ton débit est réduit à 250kbp mais en plus , tu passes *après* tout le monde , et tes paquets sont droppé en priorité. En pratique, en plus des 700ms de ping normaux, tu te rajoutais en moyenne  300ms et des pertes allant jusqu'à 30%. Bref, complètement inutilisable.
    Et TANT que ton modem était allumé, le "trafic de fond" faisait que tu n'en sortait jamais sauf.... à éteindre le modem pendant 7 jours (on est bien d'accord, *même* quand tu n'avais pas consommé ton forfait).

Toute ces règles étaient relâchés durant la "nuit" , mais cette nuit allait de 1h à 5h en France. Cette "relâche" se traduisais par le fait que dans cette période de temps, tu ne pouvais pas passer en classe 3, quelque soit ton type de traffic. Du coup , le débit s'effondrait (mais au moins tu pouvais lancer les maj).
Attention à ne PAS dépasser la limite des 5h du mat, sinon -> classe 3. Beaucoup de gens plaçaient un minuteur qui coupait l'alim du modem à 4h55....


Ces règles sont entrés en vigueur vers 2013, j'ai lâché l'affaire en 2015.
En 2019 j'ai repris un abonnement chez Europasat , car ils m'avaient promis que le FAP n'existait plus.
C'était faux , même si les limites avaient effectivement bougées à la hausse. Et c'était encore cher , 80€/mois je crois.
J'ai tenu 3 mois et j'ai résilié, en payant les pénalités , près de 400€.

J'ai pris nordnet en 2021 après une discussion avec un autre abonné et un essai chez lui.
Là, par contre, outre le prix qui était revenu raisonnable, les FAP avaient effectivement disparues. Je ne sais pas si c'est global ou si c'est spécifique à nordnet : Le débit baisse effectivement après la fin du forfait, mais pas avant , donc là c'est déjà acceptable , d'autant qu'on peut suivre sa conso sur le site.

J'ai jamais pris le temps de qualifier ça , mais il faut savoir que le modem fait office de "proxy tcp" , cad qu'il *réponds* aux SYN par des SYN,ACK à toute connexion TCP quelque soit le port ou la destination. C'est intéressant à regarder sur un wireshark , mais ça perturbe notamment certaines implémentation SSL et/ou des VPN. On y arrive mais c'est pas simple , wireguard a bien aidé sur le coup.

Je suis horrifié sur la Fair Use Policy : de telles politiques, si elles sont conforme au régalement Européen sur la neutralité (pas sur) doivent être données aux clients et si il y a un fair use sur le mois plus un second far use sur une durée plus courte, cela doit être marqué en gros lors de la souscription de l'abonnement.

Pour le "proxy tcp" ,qui réponds aux SYN à la place du serveur, je ne suis pas sur que cela soit bien autorisé. On est bien d'accord qu'il fait proxy pour tous les paquets et qu'il n'y pas de retransmission de paquet visible dans ce cas là, vu qu'entre la box et ton PC tu ne perd pas de paquet. L'idée était surement d'augmenter la Rwin (coucou les 64 Ko de Windows XP qui est une catastrophe avec une connexion sat sans proxy). Avec les systèmes modernes (tous les systèmes depuis 2005), qui montent facilement à 6 Mo de Rwin, cela ne semble plus nécessaire.

Bon alors j'ai bien lu vos commentaire sur le démontage des box, et j'en ai pas tenu compte 

J'ai démonté l'ancien modem, et j'ai utilisé les photos & documentation sur le blog donné ici : https://rjmendez.github.io/ .
J'ai trouvé les broches du port série et.... rien du tout.

Du coup , soyons fou, j'ai aussi démonté le nouveau envoyé par nordnet. Il a l'air neuf, et plus récent. Toute le PCB était encapsulé dans une cage en métal.
Sur le port série, là part contre la réponse a été immédiate:

UT_BOOT v1.2.4 (Build time: Nov 24 2010 - 10:25:58) (Based on U-Boot 1.1.1)
CN3010_LF_P1 board revision major:1, minor:0, serial #: unknown
OCTEON CN5020-SCP pass 1.1, Core clock: 300 MHz, DDR clock: 300 MHz (600 Mhz data rate)
DRAM:  256 MB
Clearing DRAM...... done
Flash: 32 MB
BIST check passed.
Net:   octeth0, octeth1, octeth2
Hit any key to stop autoboot:  0
Starting RAM Test...
Pattern AAAAAAAA  Writing...  Reading...  Pass
Pattern 55555555  Writing...  Reading...  Pass
RAM Test = Pass
Booting Software Image 0
argv[2]: coremask=3
argv[3]: console=NULL
argv[4]: mem=268435456
Software CRC Check = Pass
Uncompressing 0xd2671e@0xaa00014 to 0x1068ad8@0xc600000
ELF file is 64 bit
Attempting to allocate memory for ELF segment: addr: 0xffffffff81100000 (adjusted to: 0x0000000001100000), size 0x10a76d8
Allocated memory for ELF segment: addr: 0xffffffff81100000, size 0x10a76d8
Processing PHDR 0
  Loading 1064288 bytes at ffffffff81100000
  Clearing 43450 bytes at ffffffff82164288
## Loading Linux kernel with entry point: 0xffffffff815cc000 ...
Bootloader: Done loading app on coremask: 0x3

Ma conclusion c'est que l'attaque a dû écraser la flash y compris le bootloader , impossible de reflasher sans sonde JTAG.

Ce processeur contient 2 "bloc" JTAG , selon une doc que j'ai pu trouver : Un bloc "EJTAG" et un bloc JTAG normal.
Reste à savoir comment (et si) les broches sont câblés sur le connecteur latéral.

Je n'ai pas l'outillage pour démonter , remonter & reflasher une telle flash de 256Mbits en TSOP56 - mon matériel se limite aux flash séries et à un TL866A.
J'essaierais de trouver les broches jtag grâce au schéma , mais je sais qu'il existe des fuses donc si ça se trouve le JTAG n'est plus actif.

D'autre part j'ai vu que sur le connecteur d'autres brochent partaient en direction de la grosse puce centrale marqué "viasat" et d'un FPGA.
Si ça se trouve la procédure de reflash est largement plus complexe , et on ne pourra rien faire d'intéressant.

Je viens de démonter le mien. Visiblement c'est presque deux machines en une.
D'un côté tu a effectivement le FPGA Altera Cyclone III avec 4Mb de SRAM ; de l'autre un MIPS64 de type OCTEON Plus CN5020 avec 2 x 64Mb de DDR2 et 256Mb de NOR.

Et la grosse puce au centre marqué viasat :-)

Je voit rien d'autre en stockage "mort" ou vif ; si tout était sur la NOR elle a peut-être tout bêtement été effacer ? Faudrait faire un swap pour voir si ça reboot mais ça implique de risquer un modem fonctionnel.

Je viens de lire la datasheet de la puce.
Il y a une commande "chip erase" qui .... porte bien son nom :-/
Et aussi la possibilité de verrouiller des secteurs qui deviennent ensuite inaltérable hormis en appliquant une tension spécifique sur une des broches. Ces secteurs sont par contre verrouillés à la demande, par programmation => Si les secteurs de boot avaient profité de cette possibilité, on aurait pas eu cette situation, car le u-boot serait resté fonctionnel...
(J'ai vu qu'il y avait un bouton, aussi, donc ptet des choses à faire avec)

Fatal oversight...

Visiblement le système aurait du être protéger par son U-Boot (https://connect.ed-diamond.com/GNU-Linux-Magazine/glmf-221/u-boot-a-la-decouverte-du-demarrage-verifie)

Attention, u-boot n'a pas forcément de système de secureboot, c'est même assez récent. En 2011 ça existant sans doute pas...

Sinon un autre gars avait fait mumuse par ici : https://twitter.com/DamianKBast/status/1343736681262964737

Dans uboot si tu places la variable "timeout" à 0, il n'attends pas de touche et continue directement. C'est sans doute ce qui est fait ici, et c'est ce qu'a modifié dans la flash le gars du blog pour interrompre le boot.
C'est classique comme façon de faire.