Localisation de la flotte : ce que SNMP détecte dans le segment sol satellite et que HTTP ne détecte pas

Par Adrian Cheek, chercheur principal en cybercriminalité

Interrogez un index de balayage à l'échelle d'Internet pour savoir combien de systèmes de contrôle de mission de satellites sont exposés et vous obtiendrez la réponse 1 776. À l'exception de 18 résultats, tous ces résultats s'avèrent être la même page Web statique, répliquée sur les nœuds périphériques du cloud dans toutes les régions du monde.

La requête fonctionnelle demande quels appareils affichent la chaîne de caractères du fournisseur dans leur description SNMP, tandis que la requête web demande quelles pages contiennent cette chaîne dans leur titre. Cette dernière renvoie 437 résultats. Chacun de ces résultats correspond à une adresse unique, sur un réseau de télécommunications national distinct, avec un numéro de série unique et une réponse sur le port attribué au protocole de gestion.

Même infrastructure, mêmes fournisseurs, même jour de collecte, et pourtant la différence est d'environ trois ordres de grandeur, et rien dans le premier chiffre ne semble anormal à première vue.

La mesure passive est devenue la méthode de référence pour estimer l'étendue de l'infrastructure satellitaire exposée sur Internet. La plupart des mesures sont effectuées via HTTP. Un analyste interroge un fournisseur, comptabilise les résultats et publie le nombre. Cet article démontre que cette méthode, appliquée sans validation, révèle principalement des informations erronées et présente les résultats obtenus avec une approche validée.

Interrogées via HTTP, les adresses des fournisseurs de satellites renvoient principalement à des sites marketing, des démonstrations hébergées dans le cloud et des ressources web répliquées, plutôt qu'à des équipements déployés. On en compte plusieurs milliers. Interrogée via SNMP, la même infrastructure présente un tout autre tableau : 437 terminaux VSAT Hughes sur les réseaux de télécommunications nationaux de 15 pays, un petit nombre de modems d'opérateurs et plusieurs serveurs de gestion de réseau exécutant des systèmes d'exploitation dont les mises à jour de sécurité ont cessé il y a cinq à huit ans. C'est ce dernier point qui devrait le plus inquiéter la communauté.

L'écart entre ces deux images est au cœur de cet article. Il s'agit d'une conséquence prévisible du mode d'hébergement des infrastructures modernes, et non d'un simple bruit d'échantillonnage. La leçon pratique à retenir pour quiconque consulte des rapports d'exposition est qu'un résultat de détection passive constitue une hypothèse, et non un décompte définitif. Les sections suivantes présentent quatre critères permettant de distinguer la flotte réelle du bruit. Les systèmes satellitaires servent d'exemple concret, car ils comprennent une population qui échoue à tous les critères et une autre qui les réussit tous.

Principales conclusions concernant le segment des réseaux terrestres et des utilisateurs de satellites

• Un résultat de découverte passive est une hypothèse, pas un décompte. Sur plus de 11 requêtes HTTP, plus de 5 000 enregistrements ont permis d'identifier neuf appareils authentiques. Un produit de contrôle de mission satellite a renvoyé 1 776 résultats par titre de page, dont 18 seulement présentaient un corps de réponse identique, hébergé sur un stockage d'objets cloud. Le nombre d'appareils était donc largement surestimé, et chaque appareil était mal classé.
• SNMP identifie les équipements déployés, tandis que HTTP identifie les ressources web. Une ancre de bannière confirmée a renvoyé 437 terminaux VSAT multimédias Hughes, chacun associé à une adresse distincte, répartis sur 13 réseaux, 28 organisations et 15 pays d'Afrique de l'Ouest, du Moyen-Orient, d'Asie du Sud et d'Amérique latine. Aucun cloud hyperscale n'apparaît dans cet ensemble.
• L'exposition observée se concentre chez les utilisateurs plutôt que chez les opérateurs, une asymétrie qui persiste sur deux ordres de grandeur. Les modems de liaison radio des opérateurs génèrent des taux d'exposition inférieurs à dix à l'échelle mondiale, car ils sont situés dans des points de transit derrière des réseaux de gestion.
• Cinq serveurs de gestion de réseau satellite sont détectables passivement sur des systèmes d'exploitation en fin de vie. Deux d'entre eux utilisent une version Linux d'entreprise dont le support a cessé en mars 2017 ; les trois autres utilisent la version majeure suivante, non prise en charge depuis novembre 2020. Lors de l'attaque la plus importante connue contre un système satellite, l'attaquant a dû exploiter une faille de sécurité liée à un dispositif VPN mal configuré pour atteindre cette même couche d'architecture, à partir de laquelle il a pu émettre des commandes de gestion à l'échelle du parc. Ces serveurs sont accessibles via Internet.
• Il est impossible de construire des requêtes à partir de la documentation fournisseur. Chacun des cinq fournisseurs place ses informations d'identification dans un champ SNMP différent, et aucune convention n'est prévisible à partir d'une fiche technique. Les ancres construites à partir de la documentation ont échoué à plusieurs reprises, et certaines ont échoué silencieusement, ne renvoyant aucun résultat, de manière indiscernable d'une absence réelle. Chaque ancre fonctionnelle provenait d'une bannière confirmée sur une instance connue ; c'est pourquoi la provenance d'une ancre est plus importante que la précision de la requête construite à partir de celle-ci.

Découverte ne signifie pas dénombrement

L'erreur fondamentale dans la plupart des analyses d'exposition passive consiste à considérer une bannière renvoyée comme un dispositif. Une bannière indique seulement qu'un élément à une adresse donnée a répondu à une requête par un texte correspondant à la demande. La question de savoir si ce texte représente un équipement déployé est distincte et doit être posée séparément.

Le travail comporte donc deux étapes : la découverte génère des candidats, et la validation détermine lesquels sont réels. Si la seconde étape est omise, le décompte inclut tous les artefacts produits par la couche d'hébergement d'Internet, y compris les ressources répliquées, les démonstrations dans le cloud, les instances de laboratoire et les honeypots. Le nombre obtenu peut être erroné d'un facteur cent, sans que cela paraisse anormal au premier abord.

Quatre questions pour distinguer le signal du bruit

Il s'agit de contrôles de qualité des preuves. Ils ne sont pas spécifiques aux systèmes satellitaires. Chacun d'eux vise à déterminer si un résultat est crédible, et chacun s'applique à toute mesure passive, y compris le contrôle industriel, les dispositifs médicaux et les équipements d'entreprise. C'est pourquoi ce cadre d'analyse perdure au-delà de l'étude de cas.

• Réplication: Le même contenu est-il répété sur plusieurs adresses ? Comptez les corps de réponse distincts. Si un corps de réponse domine les résultats, cela indique un seul élément servi depuis plusieurs emplacements, et non plusieurs déploiements.
• Variance d'identité : Le champ censé être unique est-il réellement unique ? Une chaîne de caractères représentant un produit codée en dur sera identique pour l’ensemble du parc, ce qui est normal. En revanche, un numéro de série par appareil ne le sera pas. Si le champ d’identification ne varie pas en fonction du nombre d’appareils, ce dernier est faussé.
• Contexte du réseau : L'hébergement est-il pertinent ? Les équipements déployés sur le terrain sont hébergés sur les réseaux des opérateurs et des entreprises. Un modem satellite répondant depuis une région cloud hyperscale sert de démonstration, de laboratoire ou de leurre. Il ne s'agit pas d'un modem utilisé sur le terrain.
• Plausibilité du service : Le contexte de service est-il pertinent ? Chaque équipement répond sur ses propres ports de service. Une interface fournisseur répondant sur un port habituellement dédié à un service non lié est une machine virtuelle personnalisée.

Une cinquième question sous-tend les quatre précédentes, et c'est celle qui reste le plus souvent sans réponse : d'où provient l'ancre ? Une requête construite à partir d'une fiche technique du fournisseur ne fait que conjecturer le contenu de la bannière. Une requête construite à partir d'un cas concret apporte une preuve. Dans le cadre de ce travail, les conjectures basées sur la documentation ont échoué à maintes reprises, et ce, de manière silencieuse, ne renvoyant aucun résultat, ce qui est indiscernable d'une absence réelle.

Ce que révèle SNMP

SNMP est un protocole de gestion. Lorsqu'il est accessible, il renvoie la description propre à chaque périphérique : une chaîne de description système, un nom système, un contact et une localisation. Pour les équipements réseau, ces champs sont plus fiables qu'une page HTTP, car ils sont définis par le micrologiciel du périphérique et non par le contenu web hébergé à la même adresse.

Orientations de la NSA Il est recommandé de désactiver SNMP v1 et v2 car ils divulguent ces informations. C'est cette fuite qui permet de mesurer un véritable parc de véhicules.

437 terminaux et la base du nombre

Une ancre confirmée, extraite de la chaîne de description système fournie par un terminal VSAT multimédia Hughes connu, renvoie 437 enregistrements. Chacun d'eux se trouve sur le port 161 et correspond à une adresse unique. Trois ancres indépendantes convergent vers ce même nombre de 437 enregistrements : la chaîne de description, un filtre de contact système et une correspondance exacte sur le même texte. Cette convergence vers un nombre précis est un premier bon signe, car elle indique que l'ancre est bien positionnée autour d'une population d'enregistrements existant réellement.

Les quatre contrôles s'appliquent alors comme suit :

• Réplication: Les 437 rapports présentent tous la même description : « Hughes Network Systems Multimedia VSAT ». Il s’agit d’un comportement normal pour une chaîne de produit codée en dur et il n’y a pas lieu de s’inquiéter.
• Variance d'identité : Le champ « nom du système » contient 437 valeurs distinctes réparties sur 437 enregistrements, soit un identifiant de série ou de site par appareil. Le champ censé varier varie effectivement. Il s'agit là de la preuve la plus convaincante qu'il s'agit d'unités physiques individuelles.
• Contexte du réseau : Les adresses correspondent à des opérateurs de télécommunications nationaux et régionaux d'Afrique de l'Ouest, du Moyen-Orient, d'Asie du Sud et d'Amérique latine : 13 réseaux, 28 organisations et 15 pays. Aucun cloud hyperscale n'apparaît dans cet ensemble.
• Plausibilité du service : Tous les appareils répondent sur le port 161, le port de service SNMP, et beaucoup répondent également sur les ports d'administration web. Ceci est cohérent avec les terminaux distants déployés.

La population réussit tous les tests, et ce, dans le bon sens. Elle est uniforme là où l'uniformité est attendue et variée là où la variété est requise. Cette cohérence directionnelle distingue une flotte réelle d'un artefact répliqué. Environ la moitié de la flotte, soit 222 sur 437, répond via SNMP v2 malgré les recommandations explicites de le désactiver, ce qui constitue en soi une vulnérabilité. Un autre détail, discret mais révélateur, est que chaque terminal affiche la chaîne de localisation par défaut inchangée. Les recommandations déconseillent les noms descriptifs des périphériques afin d'empêcher leur identification, or ici, la valeur par défaut du fournisseur est devenue l'identifiant.

La découverte qui compte pour cette communauté

L'approche SNMP, appliquée à tous les opérateurs, ne donne quasiment aucun résultat. On observe un nombre très faible de modems de réseau à ressources partagées à l'échelle mondiale. Ces chiffres doivent être considérés comme une estimation minimale, avec une marge d'erreur inconnue, car les données d'ancrage des opérateurs sont moins fiables que celles de Hughes. L'explication architecturale est simple : les modems des opérateurs sont situés dans des téléports, derrière des réseaux de gestion, à l'écart de l'Internet public.

L'exposition se concentre sur le segment des utilisateurs consommateurs et entreprises. Cela inverse les priorités habituelles du secteur et confirme, indépendamment de tout autre argument, un point que littérature académique a déjà démontré que le segment des utilisateurs est la partie la moins étudiée de la situation sur le terrain.

Le segment terrestre du réseau n'est pas optimisé, car les modems n'ont jamais été la cible principale. Cinq serveurs de gestion de réseau sont détectables passivement. Ces serveurs constituent le plan de contrôle, c'est-à-dire les systèmes qui pilotent les terminaux distants sur l'ensemble du réseau satellitaire. Leurs systèmes d'exploitation, tels qu'ils apparaissent dans leurs descriptions, se décomposent comme suit.

• Deux de ces systèmes utilisent une version de Linux d'entreprise dont le noyau a été compilé en 2013. Cette version a atteint sa fin de vie en mars 2017, soit environ huit ans sans mises à jour de sécurité.
• Trois systèmes utilisent la version majeure suivante, avec des noyaux datés de 2016 à 2019. Cette version a atteint sa fin de vie en novembre 2020, soit environ cinq ans sans mises à jour de sécurité.

La couche de gestion correspond au même composant architectural que l'analyse publique identifie comme le point d'entrée présumé des menaces les plus importantes. attaque connue sur un système satellitaire. Le fait de le trouver exposé, sur des systèmes d'exploitation abandonnés depuis cinq ans, constitue l'élément le plus exploitable de cette étude.

Il convient de relativiser cette constatation. Il s'agit de cinq machines, et non d'une population. L'argument défendable est qu'un petit nombre de serveurs d'administration sont détectables passivement sur des systèmes d'exploitation en fin de vie. Cinq machines suffisent pour interpeller les opérateurs concernés et pour justifier un examen par tous les autres. Il ne s'agit pas d'un recensement.

Cinq fournisseurs, cinq congrès

Chaque fournisseur place ses informations d'identification dans un champ différent, et aucune ne peut être prédite à partir de la documentation produit. C'est l'aspect de la détection SNMP le plus sujet aux erreurs.

La règle de réutilisation s'ensuit directement. Les requêtes de découverte de satellites ne peuvent pas être construites à partir de la documentation du fournisseur. Elles doivent être ancrées sur une bannière confirmée provenant d'une instance connue. Dans le cadre de ce travail, toutes les ancres construites à partir d'une fiche technique ont échoué, et plusieurs ont échoué silencieusement, ce qui est dangereux, car l'absence de résultats est identique à une absence réelle.

Un autre piège courant est la collision de sous-chaînes. Un préfixe de modèle, tel qu'un code produit avec tiret, correspond aux conventions d'appellation d'entreprises sur des équipements sans lien apparent. Par conséquent, une requête construite sur ce préfixe renvoie des routeurs et des hôtes Linux dont le nom contient simplement cette chaîne. La précision n'est jamais le problème. L'ancre correspond exactement à ce qui lui a été demandé, c'est pourquoi sa provenance est primordiale.

Que renvoie HTTP à la place

Le contraste est révélateur. En effectuant une requête HTTP avec les mêmes noms de fournisseurs, le nombre de résultats augmente tandis que le signal disparaît. Un produit de contrôle de mission satellitaire a renvoyé 1 776 résultats par titre de page. Seuls 18 d'entre eux ne partageaient pas le même corps de réponse, hébergé sur un stockage d'objets cloud : une unique ressource web statique répliquée sur des nœuds périphériques hyperscale dans chaque région. Un analyste se fiant au titre ne s'en apercevrait pas. Le nombre est gonflé de près de mille fois, et chaque élément est mal classé. La solution évidente, qui consiste à utiliser une chaîne de caractères spécifique à l'application au lieu du titre générique, ne renvoie qu'un sous-ensemble strict de la même ressource répliquée et s'avère inefficace.

Les résultats HTTP d'un fournisseur de modems satellites ont révélé la même chose, à plus petite échelle : un outil marketing hébergé dans le cloud, ainsi qu'une poignée d'interfaces de véritables appareils fonctionnant sur des machines virtuelles cloud et répondant sur des ports habituellement réservés à des services sans rapport. Sur 11 requêtes HTTP, plus de 5 000 enregistrements ont permis d'identifier environ neuf appareils réels.

Un contrôle dissimulé dans les données HTTP

Ces quelques interfaces de périphériques authentiques constituent le cadre de fonctionnement conforme à sa conception. Le protocole HTTP a correctement identifié cinq interfaces de périphériques embarqués, soit cinq des neuf périphériques authentiques environ renvoyés par les onze requêtes HTTP ; les autres sont des périphériques de types différents, détectés par les requêtes restantes. Ces cinq interfaces sont distinctes des cinq serveurs de gestion de réseau décrits précédemment, détectés via SNMP et comptabilisés dans le parc de périphériques. Les interfaces issues du protocole HTTP sont exclues du déploiement car leur environnement d'hébergement et leur contexte de service indiquent des instances de démonstration ou de laboratoire plutôt que des équipements opérationnels sur le terrain. La découverte a réussi et la validation a correctement échoué. C'est le raisonnement en deux étapes illustré par les données. La détection d'une bannière a généré une hypothèse, et les vérifications l'ont confirmée.

La leçon à tirer n'est pas que HTTP soit un mauvais protocole. Dans cet ensemble de données, la découverte basée sur HTTP a principalement mis en évidence des applications web et l'infrastructure associée, tandis que la découverte basée sur SNMP a principalement mis en évidence des équipements déployés. Cela s'explique par les contrôles de validation, qui permettent de distinguer la réalité opérationnelle de tout ce qui y ressemble.

Les deux images côte à côte

Les lignes correspondent aux étapes. La découverte renvoie les deux colonnes ; la validation permet de les séparer.

Même infrastructure, mêmes fournisseurs et même jour de collecte. La différence réside uniquement dans la formulation de la question et la validation de la réponse.

Leçons à retenir pour les équipes de sécurité dans l'industrie spatiale

Il y a deux conclusions à tirer, et elles vont dans des directions différentes.

Le premier point concerne votre propre infrastructure. L'utilisation du protocole SNMP sur Internet a révélé, lors de cette étude, un parc important d'équipements, dont une grande partie fonctionnait sous la version 2, contrairement aux recommandations. Pour les opérateurs concernés, cela a également mis en évidence des serveurs de gestion fonctionnant sur des systèmes d'exploitation abandonnés depuis des années. Tout professionnel exploitant une infrastructure VSAT ou terrestre devrait répondre en interne à deux questions, avant même qu'un tiers ne le fasse : quels équipements de notre infrastructure répondent au protocole SNMP depuis Internet ? Et quels systèmes d'exploitation utilisent nos serveurs de gestion ?

Le second point concerne les rapports que vous consultez. Lorsqu'un fournisseur ou un chercheur fournit un décompte des systèmes satellitaires exposés, il est utile de demander comment ce décompte a été validé. Le même contenu a-t-il été répliqué sur toutes ces adresses ? Le champ d'identité a-t-il varié ? L'hébergement était-il cohérent ? Le contexte du service était-il pertinent ?

Un nombre qui n'a pas résisté à ces questions est une hypothèse déguisée en constatation, et cette étude existe parce que la différence entre les deux peut être de plusieurs milliers de fois, et parce que 1 776 et neuf sont tous deux des réponses à la même question.

Pourquoi cela se généralise

La mesure passive est largement utilisée pour estimer l'exposition aux rayonnements dans les technologies opérationnelles, la santé, le contrôle industriel et les communications par satellite. Cette étude montre que cette méthode peut présenter des lacunes que les praticiens ne vérifient pas systématiquement et propose un cadre pour les détecter.

Les mécanismes de contamination spécifiques dépendent de l'architecture. La réplication de stockage d'objets requiert un type particulier d'application web et n'apparaît pas lorsque les appareils exposent des bannières de protocole fixes ; les modes de défaillance ne sont donc pas transférés intégralement. Ce qui est transféré, c'est l'obligation de se demander, pour tout écosystème, quelle contamination spécifique à l'architecture pourrait gonfler ce nombre, si le résultat résiste aux vérifications et d'où provient l'ancre.

L'obligation de définition du périmètre est transférée avec elle, et, d'après les éléments présentés, elle est la plus importante des deux. Le choix du protocole détermine la couche architecturale qu'une requête peut atteindre. Pour les mêmes fournisseurs et le même jour de collecte, HTTP a atteint les applications web et SNMP les équipements déployés. Une étude doit confirmer que le protocole utilisé permet d'observer la population qu'elle prétend mesurer, car une requête adressée à la mauvaise couche peut néanmoins renvoyer un résultat fiable.

L'idée pérenne survit aux vérifications elles-mêmes. La découverte génère des hypothèses, mais ne crée pas de populations. La pratique de la mesure passive considère souvent la présence d'une bannière trouvée comme une preuve suffisante de l'existence d'un système déployé. Or, ce n'est pas le cas. La validation est l'étape où les populations se constituent, et elle est facilement négligée.

Posture de divulgation responsable

La collecte des données pour cette étude a été entièrement passive. Aucun hôte n'a été contacté directement, aucune tentative d'authentification n'a été effectuée et aucune interface n'a été consultée. Les résultats décrivent une surface d'exposition. Il ne s'agit pas d'une liste de cibles, et la rédaction est délibérément conçue de manière à ce qu'elle ne puisse pas en devenir une.

• Aucun numéro de série, identifiant de site ou nom de système n'apparaît, pour aucun périphérique.
• Aucun opérateur n'est nommé, à aucun niveau de l'ensemble de données.
• Pour les serveurs d'administration, seule l'ancienneté du système d'exploitation est indiquée. Aucune information concernant les pays ni aucune ventilation par pays n'est fournie. Cinq serveurs de plan de contrôle, identifiés par leur rôle et situés dans des juridictions identifiables, constituent précisément ce qui ne doit pas être divulgué.
• Pour les modems d'opérateurs, aucune attribution par pays n'est fournie, et aucune pondération analytique n'est accordée à leur concentration géographique, que les faibles effectifs ne permettent pas de soutenir.
• Pour la flotte par segment d'utilisateur, seule la distribution régionale et par classe de réseau est fournie, les organisations individuelles ne sont pas mentionnées.

L'ensemble des données est plus pertinent que n'importe quel enregistrement individuel, car la contribution de ce travail réside dans la classification et la validation, étape qui transforme des informations éparses en une image cohérente. Le fait qu'un enregistrement soit déjà visible ne constitue pas une défense suffisante pour l'ensemble des données, et la position adoptée ci-dessus en témoigne.

Limites

• Chaque figure représente une observation ponctuelle. Un index passif reflète la couverture de l'exploration, et non la réalité du terrain ; il est donc dynamique. Les appareils répertoriés dans des travaux antérieurs avaient déjà disparu lors de cette collecte. L'absence d'une bannière ne signifie pas l'absence d'un appareil.
• Le nombre d'opérateurs par fournisseur est suffisamment faible pour qu'un seul appareil non indexé modifie le ratio. L'asymétrie entre les segments d'utilisateurs et les opérateurs se maintient sur deux ordres de grandeur. Les chiffres précis concernant les opérateurs, quant à eux, ne le sont pas.
• Certains ancrages, notamment pour les populations de porteurs plus petites, sont moins robustes que l'ancrage de Hughes et doivent être considérés comme des bornes inférieures dont le rappel est inconnu. Compte tenu du résultat concernant les cinq conventions, un zéro silencieux ne peut être interprété comme une absence.
• La collection était issue d'une source unique et en langue anglaise. D'autres index et une couverture linguistique plus large n'ont pas été consultés.