Piratage de millions de modems et enquête sur la personne qui a piraté mon modem

• Il y a 2 ans, en testant une vulnérabilité chez lui, l’auteur a vécu quelque chose d’étrange
• Il avait lancé un serveur HTTP sur une machine AWS pour récupérer un fichier depuis un serveur vulnérable
• Tout semblait correctement configuré, mais au moment de revenir au test de vulnérabilité, un log inattendu est apparu
• Quelqu’un a intercepté puis rejoué la même requête HTTP 10 secondes plus tard entre le réseau domestique et la machine AWS
• Ce trafic était censé être inaccessible et ne devait pas passer par un intermédiaire
• Sa première pensée a été que son ordinateur avait été compromis et qu’un pirate surveillait activement son trafic
• Il a vérifié si le même phénomène se produisait aussi sur un iPhone, et une adresse IP inconnue interceptait puis rejouait les requêtes HTTP du PC comme de l’iPhone
• Il semblait donc probable que l’ISP, le modem ou AWS ait été compromis
• Pour écarter l’idée absurde qu’AWS ait été piraté, il a démarré une machine sur GCP et a observé le même comportement
• La seule possibilité restante était donc que le modem ait été piraté, mais qui était l’attaquant ? En recherchant le propriétaire de l’adresse IP, il a découvert qu’elle appartenait à DigitalOcean
• Cette IP avait été utilisée ces dernières années pour plusieurs sites de phishing et serveurs mail
• Comme l’appareil compromis continuait de fonctionner, il l’a débranché puis rangé dans une boîte
• Il est allé dans une boutique Cox pour rendre le modem piraté et en obtenir un nouveau
• Après l’installation du nouveau modem, le comportement anormal a cessé, sans pour autant révéler le mode exact de compromission
• Trois ans plus tard, pendant des vacances avec des amis experts en sécurité, il a reparlé de l’incident, ce qui a déclenché leur enquête
• En examinant les domaines enregistrés par cette adresse IP, ils ont trouvé de nombreux domaines générés algorithmiquement, ce qui suggérait un serveur C&C
• L’attaquant menait plusieurs activités malveillantes depuis la même IP sans avoir été suspendu pendant 3 ans, ce qui rendait son intention difficile à comprendre
• Comme le nouveau modem était du même modèle, ils ont aussi envisagé que l’attaquant ait pu le compromettre à nouveau
• Ils se sont concentrés sur le protocole TR-069, qui permet à l’ISP de gérer les appareils. En attaquant l’infrastructure des outils de support, il serait possible de prendre le contrôle des modems
• En analysant le JavaScript du portail professionnel Cox, ils ont découvert plus de 700 routes API. Parmi elles, les API offrant le plus d’accès aux équipements et aux comptes clients étaient accountequipment, datainternetgateway et account
• Ils ont découvert une vulnérabilité permettant de contourner l’authentification. En répétant des requêtes HTTP, il était possible d’exécuter des commandes sans autorisation
• Ils ont confirmé qu’il était possible de communiquer directement avec n’importe quel équipement à partir de son adresse MAC. Cox fournit des services à des millions de clients
• Ils ont démontré qu’il était possible d’écraser la configuration des équipements, d’accéder aux routeurs et d’exécuter des commandes sur les appareils, avec des privilèges comparables à ceux du support technique de l’ISP
• Il s’agissait donc d’une vulnérabilité permettant, sans prérequis, de modifier la configuration de millions de modems, d’accéder aux PII des clients et d’obtenir un niveau de privilège équivalent à celui de l’équipe de support de l’ISP
• Le scénario d’incident était le suivant
  1. Recherche de clients professionnels Cox via l’API
  2. Récupération, via l’UUID, de la PII du client comme l’adresse MAC de l’équipement, l’e-mail, le numéro de téléphone et l’adresse
  3. Consultation, via l’adresse MAC, du mot de passe Wi‑Fi et des appareils connectés
  4. Exécution de commandes arbitraires, modification des propriétés de l’équipement et prise de contrôle du compte
• La vulnérabilité a été signalée à Cox, qui a bloqué l’API en 6 heures et commencé à corriger le problème d’authentification
• Parmi les plus de 700 API exposées, un grand nombre fournissaient des fonctions d’administration et présentaient toutes le même problème d’autorisation
• Ce cas montre la fragilité de la couche de confiance entre l’ISP et les équipements clients
• L’auteur continue de se demander comment son modem a exactement été piraté. Il ne comprend pas non plus pourquoi l’attaquant rejouait le trafic
• Toutes les théories ou opinions à ce sujet sont bienvenues

L’avis de GN⁺

• Vulnérabilité de sécurité : cet article montre à quel point une faille de sécurité chez un ISP peut avoir des conséquences graves. En particulier, la possibilité de modifier à distance la configuration des appareils peut être détournée.
• Sécurité des API : l’article souligne l’importance de la sécurité des API. Des vulnérabilités comme le contournement de l’authentification peuvent entraîner de sérieux problèmes de sécurité.
• Protection des données utilisateur : il met en garde contre le risque d’exposition facile des informations personnelles des clients et de la configuration de leurs appareils. Les ISP doivent mettre en place des mesures de sécurité plus robustes pour protéger ces données.
• Compréhension technique : en expliquant les détails techniques de façon accessible même à un ingénieur logiciel débutant, l’article aide à comprendre comment détecter et corriger des vulnérabilités de sécurité.
• Pistes de solution : pour résoudre ce type de problème, il est important d’utiliser des équipements réseau et des protocoles de sécurité plus sûrs. On peut aussi envisager d’autres ISP ou d’autres solutions de sécurité.

[GN⁺]

Commentaire Hacker News

• Il est impressionnant que Cox ait réagi de manière responsable, sans nier le problème ni s’en prendre au messager. J’aimerais lire un article de suivi expliquant quelle était précisément la faille.
• Il est gênant que des FAI imposent l’usage de leur propre modem ou routeur. Mon routeur AT&T pourrait être piraté, mais heureusement HTTPS offre une certaine protection.
• C’était un excellent article et une excellente enquête. L’interface d’administration locale du routeur Nokia ne semble pas être correctement authentifiée. Il n’était pas possible de modifier certains paramètres, mais il a été possible de détourner la page pour les changer.
• Beaucoup de routeurs exigent des mises à jour manuelles du firmware. Les routeurs GL.iNet ont récemment eu une vulnérabilité RCE. Il est recommandé de mettre à jour le firmware et de prendre des mesures comme la désactivation de l’accès SSH.
• Je me demande toujours comment l’attaquant a intercepté le trafic HTTP. Cox devrait pouvoir vérifier la version du firmware et corriger le problème via une mise à jour automatique.
• Cox affirme que cette vulnérabilité n’a jamais été exploitée par le passé, mais c’est difficile à croire. Leur réseau semble peu rigoureux.
• Il est choquant qu’une vulnérabilité aussi importante ait été découverte dans une grande entreprise technologique. L’article est excellent, mais cette faille est impardonnable.
• Je me demande si la personne qui a signalé la vulnérabilité a reçu une récompense. Elle a rendu un grand service, mais il semble qu’elle n’ait rien reçu. C’est très insultant.
• Si Cox affirme qu’il n’y a pas eu d’exploitation passée, c’est probablement parce qu’ils manquaient de journaux ou de données d’audit.
• Le contenu de l’article est excellent, mais un attaquant déterminé pourrait se faire passer pour un technicien Cox afin d’obtenir un accès. Les FAI devraient mettre en place un paramétrage désactivant l’accès à distance par défaut.