Fantômes virtuels

Un nouveau type d'actif, les entités Web, est désormais disponible pour tous les clients de Censys . Une "Entité Web" dans Censys permet aux utilisateurs de traiter leurs actifs basés sur le web comme un seul bien de haut niveau, regroupant les hôtes et les services dans le cadre de l'écosystème de services web d'une organisation.

Outre l'introduction de cette nouvelle classification des données, nous avons mis au point de nouvelles méthodes pour repérer les actifs potentiels de Shadow IT au sein d'une organisation. Shadow IT fait référence à la technologie, aux systèmes et aux applications que les employés utilisent à l'insu ou sans l'approbation des services informatiques compétents. Ces systèmes sont déployés sans autorisation appropriée, soit par erreur, soit au nom de la productivité. Shadow IT peut revêtir diverses formes :

• L'utilisation de services de stockage en nuage personnels tels que Dropbox
• Les équipes qui utilisent des outils de gestion de projet sans supervision informatique
• Appareils mobiles personnels ou ordinateurs portables non approuvés
• Utilisation d'adresses électroniques personnelles pour des interactions liées au travail
• Utilisation non autorisée des services d'hébergement en nuage et des services d'hébergement web

Le déploiement d'un serveur sans la supervision d'une organisation informatique aura probablement pour conséquence que le serveur n'aura pas accès aux avantages de l'automatisation informatique standard, tels que les capacités de surveillance et de télémétrie, les mises à jour régulières du système et l'hygiène de configuration appropriée. Ce manque de soutien peut rendre le système vulnérable aux risques de sécurité et à l'inefficacité.

Dans ce billet, nous expliquerons une méthode technique simple que nous utilisons pour repérer les serveurs web qui, par définition, ne devraient pas exister. L'absence de contexte historique au niveau de l'hôte et de la couche DNS rend ces actifs totalement imperceptibles par la plupart des outils. Cependant, nous pouvons mieux comprendre les expositions potentielles de données en ajoutant un contexte historique à la surface d'attaque d'une organisation.

Mais avant d'entrer dans le vif du sujet, nous devons avoir une compréhension de base des différents points de vue que Censys a sur l'internet.

Les points de vue des Censys

Censys a deux visions uniques mais similaires de l'internet : l'une anonyme et l'autre nominative.

(Un hôte anonyme sur Censys)

La vue "Internet sans nom" englobe les hôtes et les services qui répondent directement à partir d'une adresse IP et qui réagissent de la même manière, que vous les demandiez par le biais d'un nom d'hôte ou d'une adresse IP. De nombreux services internet ne permettent pas au client de spécifier le nom d'hôte dans la requête. Par exemple, rien dans le protocole SSH ne peut informer le serveur distant que vous êtes intéressé par un nom d'hôte particulier, de sorte que la réponse sera la même, que vous vous connectiez directement au serveur via une adresse IP ou un nom.

(Un hôte nommé dans Censys)

D'autre part, la vue "internet nommé" correspond aux hôtes et aux services que Censys peut voir indépendamment de l'IP physique et qui sont référencés par un nom. Pour que les services répondent différemment à un nom d'hôte spécifique, un échange entre le client et le serveur doit spécifier le nom après l'établissement de la connexion. Ce processus signifie qu'il doit y avoir une méthode dans le protocole sous-jacent qui initie un tel échange.

"...la vue de l'internet nommé est celle des hôtes et des services que Censys peut voir indépendamment de l'IP physique ...."

Heureusement, deux des protocoles les plus courants sur l'internet prennent en charge un tel mécanisme, bien que pour des raisons légèrement différentes :

• Le protocole HTTP (à partir de la version 1.1) spécifie qu'un en-tête "Host" doit être inclus dans chaque requête du client, informant le serveur du nom d'hôte spécifique et de la ressource demandée. Sans cet en-tête, chaque nom de domaine aurait besoin de sa propre adresse IP.
• TLS SNI (Server Name Indication) est une extension du protocole Transport Layer Security (TLS) qui permet à un client d'"indiquer" le nom d'hôte du serveur auquel il tente de se connecter avant d'établir une connexion sécurisée. Sans SNI, le serveur ne pourrait pas déterminer le nom d'hôte correct et le certificat sous-jacent associé et renverrait le certificat par défaut configuré par le serveur - ce qui signifierait que chaque certificat SSL devrait avoir sa propre adresse IP dédiée pour fonctionner en toute sécurité.

En résumé, le serveur web utilise SNI pour répondre avec un certificat spécifique au nom d'hôte, et l'en-tête HTTP Host assigne la requête à une entité dorsale distincte, comme un répertoire du système de fichiers. L'ensemble de ce processus est généralement appelé "hébergement virtuel".

De nombreux serveurs web modernes tels que Nginx disposent d'options de configuration avancées qui permettent non seulement de servir différents répertoires en fonction des en-têtes clients entrants, mais aussi d'acheminer ces requêtes de manière transparente vers des auditeurs et des applications distincts, ce qui peut modifier considérablement la vue d'un seul hôte.

Étant donné que la plupart des serveurs web répondent différemment en fonction de la demande du client, si Censys ne parcourait le monde qu'en utilisant l'adresse IP des hôtes, nous n'aurions qu'une image minimale de l'internet et nos données seraient totalement incomplètes. C'est pourquoi nous avons introduit il y a quelques années le balayage basé sur les noms, qui fait exactement ce qui est décrit ci-dessus pour les protocoles basés sur HTTP et TLS.

Ces analyses basées sur les noms peuvent répondre à des questions spécifiques. Par exemple, avec nos données, nous pouvons facilement obtenir un rapport sur le nombre d'adresses IP par nom : "mardi dernier, il y avait 325 484 066 noms d'hôte avec une seule adresse IP, et de l'autre côté de l'échelle, il y avait UN nom d'hôte qui correspondait à 10 733 adresses IP".

Et lorsque l'on combine ces données de balayage nominatives avec le contexte historique, les choses deviennent encore plus intéressantes.

---

 

Hôtes morts et fantômes virtuels

Lors de l'analyse d'une surface d'attaque, on commet souvent l'erreur de se concentrer uniquement sur les aspects observables du moment présent, tels que l'état actuel des DNS. Le fait de négliger les artefacts du passé peut conduire à une sous-estimation significative de l'état caché actuel d'une surface d'attaque.

"...c'est souvent une erreur de se concentrer uniquement sur les aspects observables du moment présent...."

Dans le protocole HTTP, l'en-tête Host et la valeur SNI TLS sont des chaînes arbitraires. Rien dans les spécifications du protocole n'indique que ces valeurs doivent avoir une fonction ou même être légitimes. Un client peut demander google.com à partir d'une adresse IP twitter.com, et rien ne l'empêche de le faire. Bien sûr, vous pourriez recevoir une erreur du serveur indiquant que l'hôte n'a pas pu trouver de données pour le nom d'hôte demandé, mais rien n'a empêché cet échange.

Dans le même ordre d'idées, si un administrateur supprime un enregistrement DNS qui pointe vers une adresse IP mais conserve la configuration du serveur web qui a associé ce nom à une ressource locale, une personne ayant connaissance du nom d'hôte appartenant à cette IP pourra toujours accéder aux données comme si l'enregistrement DNS existait toujours.

Par ailleurs, si un administrateur achète un nouveau serveur pour sa plateforme de billetterie et modifie l'entrée DNS pour qu'elle pointe vers l'adresse IP du nouveau serveur, sans jamais supprimer la configuration de l'ancien serveur web, et qu'il corrige ensuite une vulnérabilité critique dans le logiciel du nouveau serveur, mais pas dans celui de l'ancien, un pirate pourrait utiliser les informations historiques pour exploiter le logiciel de l'ancien hôte.

En résumé, lorsque l'enregistrement DNS d'un nom d'hôte est modifié pour pointer vers une nouvelle adresse IP ou supprimé du DNS, mais que l'ancienne adresse IP est toujours opérationnelle avec une configuration d'hôte virtuel valide pour le même nom d'hôte, un pirate ayant une connaissance historique de l'hôte peut toujours accéder aux anciennes données sur l'ancien serveur.

En l'absence d'un terme établi pour décrire cette méthode d'analyse des hôtes, nous avons officieusement surnommé ces hôtes "fantômes virtuels".fantômes virtuels","un jeu de mots sur le terme "hôte virtuel".

Chasseurs de fantômes virtuels

Ce concept de "fantôme virtuel" peut sembler similaire aux DNS suspendus ou aux prises de contrôle de sous-domaines à première vue, mais il est très différent dans son exécution. Tout d'abord, les attaquants ne jouent pas un rôle actif dans cette affaire, si ce n'est qu'ils ciblent l'hôte dont ils ont connaissance au préalable. Deuxièmement, il ne s'agit pas d'un problème de DNS mais d'un problème plus proche du DNS - le problème n'existe qu'avec une mauvaise hygiène de configuration des serveurs.

Censys a voulu mesurer l'ampleur de cet effet de "fantôme virtuel" sur l'internet en échantillonnant deux instantanés de balayage Censys basés sur les noms, chacun à une semaine d'intervalle, et en analysant tous les hôtes basés sur l'IP qui servent encore du contenu pour un enregistrement DNS qui n'existe plus (c'est-à-dire que l'enregistrement DNS renvoie maintenant un NXDOMAIN).

Nous avons effectué ces tests en utilisant deux ensembles de données, un échantillon aléatoire et un autre avec une approche plus ciblée.

Notre premier test a porté sur 50 000 hôtes aléatoires qui avaient une entrée dans notre base de données d'analyse nommée le 2 février 2022, mais le 14 février, ils avaient disparu. Cette suppression peut avoir deux significations :

1. L'hôte est tombé en panne ou un administrateur a interrompu les services du réseau.
2. Censys n'a pas pu résoudre le nom DNS en adresse IP.

Les hôtes qui nous intéressent le plus sont ceux dont les noms DNS ne sont plus résolus par une adresse IP. Nous commençons donc par examiner chaque nom d'hôte de notre échantillon et validons que le serveur de noms faisant autorité pour ce nom d'hôte renvoie un NXDOMAIN. Ce processus a permis de réduire le nombre de cibles potentielles à 8 227 hôtes, ce qui signifie que 41 773 hôtes de notre échantillon de données possédaient encore des enregistrements DNS valides (mais n'étaient pas associés à des services).

Pour chaque enregistrement DNS vérifié qui renvoie maintenant un NXDOMAIN et qui a été trouvé dans notre échantillon, nous saisissons une copie historique des détails de l'hôte associé et prenons note des informations suivantes :

• L'adresse IP à laquelle l'enregistrement DNS a été résolu. 
• L'ancien Sha256Sum du corps de la réponse HTTP
• L'ancien titre HTML de la réponse HTTP
• L'ancienne somme Sha256 du certificat du serveur TLS

Nous nous connectons ensuite à l'IP de l'hôte qui servait à diffuser le contenu de cet enregistrement DNS expiré et émettons trois requêtes HTTP fonctionnellement distinctes :

1. Une requête GET vers l'ancienne adresse IP avec l'en-tête HTTP Host et le champ TLS SNI défini sur le nom DNS qui n'existe plus.
2. Requête GET vers l'ancienne IP avec une valeur aléatoire ajoutée au début du nom d'hôte. Par exemple, si le nom d'hôte ciblé est "search.censys.io", nous émettons une requête GET pour "Host : $random_string.search.censys.io", dont le résultat est ensuite utilisé pour tester les sites de parking de noms de domaine potentiels ou les gestionnaires HTTP par défaut.
3. GET sans l'en-tête Host ou le champ SNI dans la poignée de main TLS. Nous voulons nous assurer que notre réponse à la demande d'en-tête Host diffère de la simple frappe de l'IP nue.

Notre objectif, dans le cadre de cette étude spécifique, était d'analyser uniquement les "vrais" sites qui ne renvoient pas simplement les gestionnaires HTTP par défaut ou les pages web de parking de domaines génériques. Nous avons donc utilisé les deux requêtes non Host+SNI des étapes 2 et 3 pour les comparer à la requête effectuée à l'étape 1. Par exemple, si la réponse des requêtes 2 et 3 est similaire à celle de la requête 1, nous ne considérons pas qu'il s'agit d'un "vrai" site web.

Si le nom d'hôte et l'adresse IP passent le contrôle de validation ci-dessus (ce qui signifie que nous considérons qu'il s'agit d'un "vrai" site web), nous vérifions ensuite la réponse de la première requête, en recherchant les critères suivants :

• Le corps de la réponse a-t-il le même SHA256SUM que celui qui figurait dans nos données historiques ?
• Le titre HTML de la réponse correspond-il à ce qui figurait dans nos données historiques ?
• Le certificat du serveur correspond-il à ce qui figurait dans nos données historiques ?

Si les trois critères sont remplis, il est très probable que l'hôte serve encore du contenu pour un enregistrement DNS qui n'existe plus. Si seulement deux des trois critères sont remplis, il s'agit d'une probabilité moyenne à élevée, tandis que si un seul critère est trouvé, il s'agit d'une probabilité faible à moyenne que cet hôte serve du contenu pour des enregistrements DNS expirés.

Sur les 50 000 hôtes aléatoires que nous avons échantillonnés, 694 serveurs au total répondaient à au moins un de ces trois critères et servaient ce que nous considérons comme un "vrai" site web ; 112 de ces hôtes (16,1 %) répondaient aux trois critères, tandis que seuls 52 (7,5 %) ne répondaient qu'à l'un d'entre eux.

Le tableau ci-dessous présente la répartition des trois combinaisons de critères en fonction du nombre d'hôtes.

Le corps HTTP correspond aux anciennes données	Le titre HTML correspond aux anciennes données	Le certificat du serveur correspond aux anciennes données	Nombre d'hôtes	%
OUI	NON	OUI	1	0.1
OUI	OUI	NON	52	7.5
NON	NON	OUI	99	14.3
OUI	OUI	OUI	112	16.1
NON	OUI	NON	181	26.1
NON	OUI	OUI	249	35.9
		Total	694

Pour notre deuxième test, nous avons voulu effectuer la même analyse sur un ensemble de données non échantillonné mais ciblé. Nous avons donc établi une liste de tous les noms d'hôtes et de toutes les adresses IP du 2 février 2023 qui ne sont pas apparus le 14 février et qui contiennent le mot "admin" quelque part dans le sous-domaine du nom DNS..

L'objectif de ce test était de trouver des interfaces d'administration web que quelqu'un a pu mettre en ligne par erreur en leur donnant un nom DNS valide, mais qui ont depuis été supprimées du DNS , mais pas de la configuration de l'hôte virtuel du serveur web. Bien qu'ils ne soient pas directement accessibles, ces "fantômes virtuels" peuvent poser un problème lorsqu'un pirate a une connaissance préalable de l'ancien nom d'hôte et de l'ancienne adresse IP.

Entre le 2 et le 14 février, nous avons vu 21 502 combinaisons d'IP et de noms d'hôtes qui étaient des "fantômes virtuels" potentiels (noms d'hôtes vus le 2 et non vus le 14). Après avoir exécuté la validation NXDOMAIN, ce nombre est tombé à seulement 5 101 possibilités. Enfin, en soumettant ces 5 101 hôtes au même processus que celui utilisé pour les données échantillonnées, 223 hôtes ont été trouvés avec un ou plusieurs critères de "fantômes virtuels" remplis. Vous trouverez ci-dessous la cartographie complète :

Le corps HTTP correspond aux anciennes données	Le titre HTML correspond aux anciennes données	Le certificat du serveur correspond aux anciennes données	Nombre d'hôtes	%
NON	NON	OUI	16	7.2
NON	OUI	NON	18	8.1
OUI	OUI	NON	24	10.8
NON	OUI	OUI	73	32.7
OUI	OUI	OUI	92	41.3
		Total	223

Nous avons ensuite établi un serveur DNS local et intégré tous les noms DNS inexistants dans leurs zones correspondantes, en faisant correspondre les noms DNS oubliés à leurs adresses IP d'origine. Le serveur DNS nous a permis de parcourir ces "fantômes virtuels" à l'aide de n'importe quelle interface compatible HTTP, telle que Chromium, et d'examiner si le processus avait permis de faire des découvertes notables. Voici quelques exemples intéressants de sites web qui ne devraient pas être accessibles ou, comme nous les appelons, de "fantômes virtuels".

Nous avons observé un grand nombre de formulaires administratifs de connexion.

 

Quelques tableaux de bord d'administration, dont certains ne contiennent que des données de test.

 

De nombreuses listes d'annuaires contenant l'intégralité du code source d'un site web.

Extension de la surface d'attaque

Les données présentées indiquent que les "fantômes virtuels" ne sont pas rares. Les découvrir est une tâche simple si l'on a accès à des informations sur tous les hôtes, services et sites web qui ont jamais existé. Cela renforce l'idée que toutes les surfaces d'attaque ne sont pas visibles et que le contexte historique est essentiel pour obtenir une vue d'ensemble précise de l'empreinte numérique d'une organisation.

À la lumière de ces conclusions, nous sommes fiers de présenter notre nouvelle fonction "Entités Web" dans la plateforme Censys , qui permet de suivre et d'alerter automatiquement sur les actifs qualifiés de "fantômes virtuels". - Il s'agit d'hôtes qui ont été dissociés de leurs noms DNS mais qui hébergent toujours du contenu sur le serveur web. Nous encourageons vivement les organisations à intégrer cette fonction dans leurs protocoles de sécurité afin de se prémunir contre les menaces potentielles.

Faites le premier pas pour sécuriser vos actifs numériques en intégrant dès aujourd'hui notre fonction Entités Web dans votre stratégie de sécurité. Contactez-nous pour planifier une démonstration.