Piratage de millions de modems et enquête sur la compromission de mon modem

• Sam Curry a découvert qu’une requête HTTP envoyée depuis son réseau domestique était rejouée 10 secondes plus tard depuis une IP DigitalOcean ; après remplacement de sa passerelle Cox Panoramic Wifi, le phénomène a disparu, ce qui a fait suspecter une compromission de l’ancien modem
• L’IP du trafic rejoué, 159.65.76.209, était liée à des domaines associés à Adidas, à des domaines de phishing d’ISG Latam et à des domaines semblant servir de C&C générés de façon algorithmique, mais le vecteur réel de compromission n’a pas pu être confirmé
• En analysant le portail Cox Business en 2024, il a découvert derrière /api/cbma/ une API basée sur Spring et sa documentation Swagger ; parmi environ 700 API, certaines présentaient un contournement d’autorisation alternant entre erreurs d’authentification et réponses 200 OK
• Ce contournement permettait de rechercher des clients, de consulter les PII des comptes, de récupérer les adresses MAC des équipements, de consulter les IP des modems, de lire et modifier des comptes Cox Business, ainsi que d’effectuer des changements de configuration d’équipement comme modifier le SSID WiFi ; dans le PoC, son propre SSID a été changé en Curry
• Après le signalement, Cox a retiré les API exposées en moins de 6 heures et l’exploitation n’était plus reproductible le lendemain ; l’entreprise a indiqué que ce service API avait démarré en 2023, qu’il était distinct de la compromission du modem en 2021 et qu’aucun abus antérieur n’avait été constaté

---

Trafic anormal repéré depuis le modem domestique

• Pour tester une faille XXE aveugle sur son réseau domestique, il a lancé un simple serveur HTTP Python sur une instance AWS afin de vérifier la réception de requêtes externes
• Juste après l’enregistrement normal d’une requête envoyée avec curl depuis son ordinateur personnel, une IP inconnue 159.65.76.209 a redemandé le même chemin 10 secondes plus tard
• Quand il a demandé un autre chemin depuis Safari sur iPhone, la même IP a rejoué la même requête, donnant l’impression que ce n’était pas un ordinateur précis mais l’ensemble du trafic du réseau domestique qui était observé
• Le même phénomène s’est reproduit sur une nouvelle instance AWS avec Nginx, puis sur une instance GCP, ce qui a écarté l’hypothèse d’une compromission d’AWS
• Après avoir rendu l’ancienne passerelle Cox Panoramic Wifi en boutique et l’avoir remplacée par un nouvel équipement, le trafic rejoué a disparu et les journaux n’ont plus montré de « autre IP »

Enquête sur 159.65.76.209

• Cette IP a été identifiée comme appartenant à DigitalOcean et non à une adresse ISP de Cox
• Dans l’historique VirusTotal, parmi les 5 domaines récemment liés à cette IP, 3 semblaient être des sites de phishing et 2 des serveurs mail
  • regional.adidas.com.py
  • isglatam.online
  • isglatam.tk
  • mx12.limit742921.tokyo
  • mx12.jingoism44769.xyz
• isglatam.online et isglatam.tk avaient un temps servi de sites de phishing visant isglatam.com, une entreprise sud-américaine de cybersécurité
• D’après les enregistrements URLscan, les deux domaines liés à ISG Latam hébergeaient un site de phishing BeEF classique, comme le montrent les résultats urlscan.io
• La même IP était donc liée à Adidas, à ISG Latam et au rejeu de trafic de modem, même s’il n’était pas possible d’exclure totalement une réattribution de l’IP entre plusieurs propriétaires

Une analyse reprise trois ans plus tard

• Début 2024, des amis travaillant dans la sécurité ont attiré l’attention sur le format de limit742921.tokyo et jingoism44769.xyz
• Une recherche d’IP inversée à partir de l’IP du sous-domaine mx1 de limit742921.tokyo a fait apparaître plus de 1 000 domaines du même type
• Tous les noms de domaine suivaient la forme [mot][6 chiffres].[TLD]
  • Ex. : acquire543225.biz
  • Ex. : battery935904.biz
  • Ex. : grocery634272.biz
• En raison des enregistrements en masse et de leur structure algorithmique, cela ressemblait à un algorithme de génération de domaines utilisé par un opérateur de malware pour masquer l’adresse de ses serveurs C&C
• Le dernier domaine observé avait été enregistré le 17 mars 2023 ; à ce moment-là l’hôte ne se résolvait déjà plus et aucun domaine similaire nouvellement associé à la même IP n’a été trouvé

Hypothèse autour des fonctions de gestion ISP et de TR-069

• Les agents du support Cox pouvaient mettre à jour le modem à distance, changer le mot de passe WiFi et voir les équipements connectés
• Cette administration à distance est liée au protocole TR-069, implémenté en 2004, qui permet à un ISP de gérer des équipements du réseau via le port 7547
• Comme TR-069 n’était pas lui-même exposé à l’extérieur et avait déjà été abordé dans des conférences DEF CON, l’attention s’est déplacée vers les outils de support et les API internes utilisés par les conseillers
• Si un attaquant cherchait à compromettre un modem, il pouvait viser l’infrastructure sous-jacente de ces outils de support, en particulier les API capables de modifier la configuration des équipements clients ou d’exécuter des commandes arbitraires
• L’enquête a donc évolué vers la vérification de la couche de confiance entre l’ISP et les équipements clients, plutôt que vers l’identification définitive du vecteur réel de compromission de 2021

Structure des API du portail Cox Business

• Dans le fichier JavaScript frontend main.36624ed36fb0ff5b.js du portail Cox Business, il a trouvé plus de 100 appels API basés sur /api/cbma/
• Le chemin /api/cbma/ se comportait différemment des autres chemins /api/, donnant l’impression d’une API proxyfiée vers un backend distinct du frontend
  • /api/anything_else/example renvoyait une redirection
  • /api/cbma/example renvoyait 500 Internal Server Error
• Les requêtes d’inscription incluaient des en-têtes comme clientid, Apikey, Cb_session, Authorization, et le format des réponses ressemblait à celui d’un backend Spring
• En changeant la méthode HTTP, il a obtenu des réponses d’erreur Spring, confirmant que le backend API reposait sur Spring
• Aucun chemin actuator n’a été trouvé, mais un chemin Swagger UI a bien été découvert

Chargement contourné de la documentation Swagger et 700 API

• Swagger UI se chargeait, mais les ressources statiques entraient dans une boucle de redirection, ce qui faisait apparaître la documentation comme vide
• Les requêtes vers les ressources statiques comme .js, .css ou .png semblaient être routées vers l’hôte principal au lieu de passer par le proxy API
• En ajoutant à la fin de l’URL un / encodé sous la forme %2f, il a pu charger les ressources JavaScript statiques via le proxy API
• En utilisant le match-and-replace de Burp pour ajouter %2f aux requêtes de ressources statiques, la documentation Swagger s’est affichée normalement
• Au total, il a identifié environ 700 appels API, dont les zones les plus liées aux fonctions d’équipement et de compte étaient accountequipment, datainternetgateway et account

Contournement d’authentification et accès aux données clients

• En répétant les requêtes sur tous les endpoints GET, certaines renvoyaient des erreurs d’authentification, d’autres des 200 OK, et pour une même requête le résultat pouvait changer d’un essai à l’autre
• L’endpoint profilesearch a d’abord renvoyé des résultats vides, puis la même requête a alterné entre erreur d’authentification et réponse réussie
• En répétant une requête avec le terme cox, il a obtenu des résultats ressemblant à des profils de clients Cox Business ainsi que des profileGuid
• Lors d’une recherche sur fbi, la réponse a inclus les adresses physiques de plusieurs bureaux locaux du FBI clients de Cox Business
• Le même problème d’autorisation affectait d’autres API et, en rejouant plusieurs fois les requêtes, il devenait possible d’accéder à des fonctions d’administration sans authentification

Consultation des adresses MAC et des informations de compte

• En récupérant l’adresse MAC de son propre modem depuis son compte Cox et en l’injectant dans une API avec le paramètre macAddress, il a obtenu l’adresse IPv4 de cet équipement
• Ce résultat a confirmé que l’API du site Cox Business pouvait effectivement communiquer avec les équipements réels
• Une API de liste d’équipements utilisant un ID de compte renvoyait des informations sur les équipements liés au compte
  • catégorie d’équipement
  • nom du modèle
  • adresse MAC
  • informations de port
  • numéro de série
• Une API de recherche d’utilisateur par e-mail renvoyait des informations de compte business telles que nom, numéro de téléphone, statut, type d’utilisateur, indication de propriétaire du profil et e-mail alternatif
• Une requête POST similaire de mise à jour de compte fonctionnait aussi, confirmant des capacités de lecture et d’écriture sur les comptes business

encryptedValue et modification de la configuration des équipements

• Les requêtes de modification de configuration des équipements nécessitaient un paramètre encryptedValue
• Les fonctions encryptWithSaltandPadding et decryptWithSaltandPadding présentes dans le JavaScript servaient à chiffrer et déchiffrer ces valeurs avec AES
• Le PIN à 4 chiffres défini lors de l’inscription du compte était lui aussi chiffré avec la même fonction, ce qui permettait de récupérer le contexte d’exécution de cette fonction dans le débogueur du navigateur
• En déchiffrant l’encryptedValue inclus dans la réponse d’un équipement sur le compte d’une connaissance utilisant Cox Business, il a trouvé les éléments suivants
  • numéro de compte Cox
  • nom de l’équipement
  • ID de l’équipement
  • valeur inconnue
  • adresse MAC
  • libellé
• En réinjectant des valeurs arbitraires pour le numéro de compte et l’ID de l’équipement, tout en conservant seulement une adresse MAC valide, puis en rechiffrant la chaîne, la requête réussissait quand même, montrant que le serveur ne vérifiait pas la cohérence entre l’adresse MAC et le compte

Possibilité de modifier la configuration de modems arbitraires

• Il a envoyé une requête POST visant l’adresse MAC de son propre équipement pour modifier le SSID WiFi
• La réponse renvoyait 200 OK et Success, puis le réseau est brièvement passé hors ligne
• Environ 5 minutes plus tard, le réseau a redémarré et le SSID avait été modifié en Curry
• Ce PoC montrait que l’API de mise à jour de configuration d’équipement fonctionnait réellement et qu’un attaquant pouvait écraser la configuration d’un équipement via l’API
• Le niveau de privilège équivalait à celui du support technique ISP et pouvait affecter des centaines de milliers, voire des millions d’équipements Cox accessibles via l’API

Portée de l’impact et scénario d’attaque possible

• La combinaison de vulnérabilités créait un chemin permettant à un attaquant externe sans prérequis de modifier la configuration de millions de modems, d’accéder aux PII des clients business et d’obtenir un niveau de privilège équivalent à celui de l’équipe support de l’ISP
• Cox est le plus grand fournisseur privé de haut débit aux États-Unis, le troisième câblo-opérateur, le septième opérateur téléphonique, avec des millions de clients et la place d’ISP le plus populaire dans 10 États
• Le scénario d’attaque possible était le suivant
  • rechercher des cibles Cox Business à partir d’un nom, numéro de téléphone, e-mail ou numéro de compte
  • utiliser l’UUID renvoyé pour consulter les PII du compte, les adresses MAC des équipements, les e-mails, numéros de téléphone et adresses
  • utiliser l’adresse MAC de l’équipement pour consulter le mot de passe WiFi et les équipements connectés
  • exécuter des commandes arbitraires, mettre à jour des propriétés de l’équipement et prendre le contrôle du compte de la victime
• Les API exposées étaient au nombre de plus de 700 et beaucoup fournissaient des fonctions d’administration, comme la consultation des équipements connectés à un modem
• Chacune de ces API souffrait du même problème d’autorisation permettant d’exécuter des commandes non autorisées par simple répétition des requêtes

Signalement, correctif et questions en suspens

• Les vulnérabilités ont été signalées via le programme de responsible disclosure de Cox
• Cox a désactivé les appels API exposés en moins de 6 heures et, dès le lendemain, la vulnérabilité n’était plus reproductible
• D’après l’enquête de Cox, ce vecteur n’avait jamais été exploité par le passé, et le service vulnérable n’avait démarré qu’en 2023, ce qui excluait son utilisation dans la compromission du modem de 2021
• Cox a indiqué n’avoir aucun lien avec l’IP DigitalOcean, si bien que l’ancien modem resterait compromis par un autre moyen que celui décrit dans cet article
• Comme le modem d’origine avait été restitué, il n’a pas été possible d’effectuer un dump du firmware ni une analyse forensique, et la raison exacte du rejeu délibéré du trafic reste inconnue

Chronologie de publication

• 2024-03-04 : signalement des vulnérabilités au programme de divulgation responsable de Cox
• 2024-03-05 : application d’un hotfix, les endpoints business non essentiels cessant de fonctionner en renvoyant 403
• 2024-03-06 : envoi d’un e-mail à Cox indiquant que la vulnérabilité n’était plus reproductible
• 2024-03-07 : réponse de Cox annonçant le lancement d’un examen de sécurité approfondi
• 2024-04-10 : information transmise à Cox selon laquelle la publication aurait lieu 90 jours après le signalement
• 2024-04-29 : partage avec Cox d’un lien vers une première version du billet de blog

[GN⁺]

Avis sur Hacker News

• albinowax_ l’avait posté en premier, et comme ça me gênait qu’il ne reçoive pas de karma, j’ai déplacé le commentaire vers https://news.ycombinator.com/item?id=40560010
  J’espère que xrayarx le prendra bien. Nous prévoyons de mettre correctement en place un partage de karma pour ce genre de cas, mais d’ici là nous nous appuyons parfois sur ce type de méthode manuelle un peu rudimentaire
  • D’après le système, je l’ai posté il y a 13 heures, et lui il y a 10 heures. Je ne comprends donc pas bien l’idée qu’il l’ait posté en premier