Quand des noms d’hôtes internes fuitent vers le cloud

 (rachelbythebay.com)
1 points par GN⁺ 2026-02-06 | 1 commentaires | Partager sur WhatsApp
  • Découverte d’un cas où l’interface web d’un NAS domestique envoie un nom d’hôte réservé à l’usage interne vers un service externe
  • Le script de rapport d’erreurs sentry.io inclus dans l’interface web du NAS transmet ce nom d’hôte interne vers l’extérieur avec la pile d’appels
  • Un comportement étrange a été observé : sentry.io tente en retour une connexion TLS vers ce nom d’hôte, mais n’envoie jamais de véritable requête
  • Le fait d’avoir configuré à l’avance un DNS wildcard a permis de détecter la fuite, avec un risque grave d’exposition d’informations si des noms d’hôtes sensibles sont utilisés
  • Ce mécanisme présente un problème de sécurité potentiel : il pourrait être détourné pour provoquer un scan DNS de n’importe quel hôte

Installation du NAS et configuration du nom d’hôte interne

  • Achat d’un NAS, installation des disques et connexion au réseau domestique, avec une exploitation en mode HTTPS
  • Installation d’un certificat TLS wildcard pour un sous-espace d’un domaine sans signification particulière sur l’Internet public (ex. : *.nothing-special.whatever.example.com)
  • Ajout dans le fichier /etc/hosts d’une entrée locale uniquement comme 172.16.12.34 nas.nothing-special.whatever.example.com afin d’y accéder depuis le navigateur

Découverte d’un accès inattendu depuis l’extérieur

  • Quelques jours après l’installation du NAS, des requêtes provenant de l’extérieur (« outside world ») ont commencé à arriver pour ce même nom d’hôte
  • Ce nom d’hôte est un nom entièrement réservé à l’usage interne, présent uniquement dans le fichier /etc/hosts du portable
  • La fuite a pu être détectée parce qu’une entrée DNS wildcard pointant vers une machine contrôlée par l’auteur avait été configurée à l’avance pour tout *.nothing-special.whatever.example.com
  • À chaque chargement du NAS, un hôte GCP tentait de se connecter en présentant ce nom d’hôte interne comme SNI

Cause de la fuite : rapport d’erreurs sentry.io

  • L’interface web du NAS inclut une fonction de phone home, dont une partie consiste à envoyer des piles d’appels à sentry.io
  • Lors du callback du navigateur vers sentry.io, le nom d’hôte utilisé pour l’équipement de stockage interne est également transmis
  • Il a été confirmé que sentry.io initie en retour une connexion TLS vers ce nom d’hôte, sans jamais envoyer de véritable requête HTTP

Implications de sécurité et réponse

  • Si le nom d’hôte contient des informations sensibles (par ex. mycorp-and-othercorp-planned-merger-storage), il existe un risque de fuite d’informations grave
  • Ce mécanisme de rapport Sentry pourrait être utilisé pour déclencher un scan DNS vers un hôte externe arbitraire (la méthode précise est laissée au lecteur)
  • Comme mesure de réponse, Little Snitch a été utilisé pour bloquer l’ensemble de ce domaine pour toutes les applications

À lire aussi

1 commentaires

 
GN⁺ 2026-02-06
Commentaires Hacker News

  • Les gens semblent mal comprendre le problème. Ce n’est pas une question de logs CT, mais de certificat wildcard
    Sentry collectait des traces côté client, en extrayait le nom d’hôte ayant envoyé la requête, puis tentait de l’interroger à nouveau avant d’être bloqué

    • C’était peut-être une tentative de récupérer le favicon à afficher dans l’interface des traces
    • Mais avec une telle architecture, Sentry peut se retrouver avec une faille de sécurité lui permettant d’envoyer des requêtes vers des IP arbitraires. En particulier, il pourrait accéder de façon répétée à des IP qui signalent automatiquement le trafic malveillant
    • Si les gens sont confus, c’est parce que le billet de blog est rédigé de manière trop confuse et ambiguë

  • Un nom d’hôte n’est fondamentalement pas une information privée
    Il est exposé à l’extérieur par divers canaux, comme les requêtes DNS ou les certificats TLS
    Si l’on veut dissimuler un service privé, mieux vaut mettre le secret dans le chemin d’URL plutôt que dans le nom d’hôte
    Par exemple, fileservice.example.com/my-hidden-service-007-abc123/ n’est transmis qu’en HTTPS, ce qui réduit fortement l’exposition

    • Bien sûr, même dans ce cas, le chemin peut être envoyé à un service externe comme Sentry, donc mieux vaut utiliser des URL opaques et prendre l’habitude de ne pas mettre de secrets dans les URL
    • Quelqu’un a aussi demandé si « utiliser uniquement HTTP réduirait ce type d’exposition »

  • Je me demandais si « clown GCP Host » était un terme technique. En fait, l’auteur utilisait cette expression pour tourner le cloud en dérision
    Le cœur du problème est que l’interface web du NAS envoyait des logs à Sentry avec des noms d’hôte internes inclus
    Dans un cas comme celui-ci, je remplacerais probablement le système par un OS open source de confiance, ou je bloquerais les appels vers Sentry avec un filtrage DNS comme PiHole

    • « clown » est une façon de se moquer du cloud des Big Tech ; certains disent qu’on parlait déjà de « clown computing » sur IRC à l’époque
      Quelqu’un a expliqué qu’il utilisait un DNS local et un proxy TLS pour bloquer totalement le trafic sortant
    • Une autre personne a ajouté que « clown » est un vieux terme satirique visant les grands fournisseurs de cloud et leurs utilisateurs
    • Quelqu’un a plaisanté en disant qu’il utilisait parfois le mot « weenie » à la place de « clown »
    • Il y a aussi eu une blague du genre : « le cirque est parti, mais les clowns sont restés »

  • C’est pour ce genre de cas que je considère uBlock Origin comme le minimum en matière de sécurité web
    Le fait que la plupart des pages web chargent une avalanche de scripts tiers qui font fuiter des données est un problème beaucoup trop grave
    Ce n’est pas une solution de fond, mais c’est le mieux que nous puissions faire immédiatement

    • Moi aussi, j’ai installé AdGuard Home sur le routeur, et 15 à 20 % du trafic est bloqué. Ça montre à quel point le pistage et la publicité sont omniprésents

  • Pour éviter ce genre de problème, il vaut mieux placer un reverse proxy Nginx en frontal et injecter des en-têtes CSP
    Cela n’empêchera pas le NAS d’envoyer lui-même des requêtes vers l’extérieur, mais cela peut empêcher le navigateur de les envoyer à sa place
    Par exemple, des requêtes d’avatar Steam (https://avatars.steamstatic.com/HASH_medium.jpg) peuvent aussi être bloquées par une politique CSP
    On peut n’ouvrir que certaines destinations si nécessaire. On peut aussi ajouter Referrer-Policy: no-referrer pour éviter que le nom d’hôte n’apparaisse dans des logs externes

    • Quelqu’un a relevé l’expression redondante « ATM machine »
    • Une autre personne a répondu sur le ton de la blague : « NPM est assez simple »

  • J’ai acheté un NAS Synology et je l’ai regretté plusieurs fois
    En dehors des logiciels de la communauté, il n’y a presque rien qu’on puisse vraiment faire avec
    Mettre en place SSL avec Let's Encrypt est compliqué, et comme les chemins ne sont pas standards, il est difficile de trouver où se situe la configuration
    Entre l’ancienne version de rsync, le manque d’outils de base et d’autres frustrations, j’aurais mieux fait de choisir un NAS sous Linux ou BSD

    • D’autres disent être satisfaits tant que Synology est utilisé uniquement comme serveur de fichiers, car c’est très stable. Mais à cause de la politique fermée de l’entreprise, certains prévoient de passer à un UniFi NAS
    • Quelqu’un a aussi réagi en disant qu’il était contradictoire de vouloir un serveur tout en reprochant à un NAS de ne pas être un serveur
    • Une personne a partagé un guide pour installer Debian récent sur un NAS Synology sur le forum Doozan
    • Un autre conseil était de « le laisser simplement comme serveur de fichiers/iSCSI, car c’est extrêmement stable, et de ne pas y toucher »
    • À l’inverse, quelqu’un a raconté avoir acheté un modèle RS217 pour 100 $, et que c’était son meilleur achat. Il utilise Synology Office à la place de Google Docs et a été impressionné par la qualité de l’interface

  • J’ai récemment configuré Sentry, et ce système a une fonction qui tente de configurer automatiquement la supervision de disponibilité
    Lorsqu’il reconnaît un hôte, il lui envoie périodiquement des ping, puis, après quelques jours de réponses stables, affiche une notification du type : « Voulez-vous configurer une supervision de disponibilité pour cet hôte ? »

    • Quelqu’un a simplement commenté : « opportunité d’expansion »

  • Personnellement, je bloque tout le domaine lié à Sentry
    Ce n’est pas une solution générale, mais dans mon environnement, c’est ce qu’il y a de mieux

  • On voit souvent des serveurs de résolution inverse essayer de résoudre même des adresses de réseau interne (ULA, RFC1918)
    En combinant ces données avec d’autres informations, on peut déduire l’état interne d’un réseau
    Quelqu’un a même dit qu’« en collectant sur le darknet, il lui était arrivé de capter de l’audio UDP »

    • En réponse, quelqu’un a demandé : « Et ce trafic SIP, c’était de quelle année ? »

  • J’ai déjà enquêté sur un phénomène similaire chez Heroku
    Lorsqu’on crée une nouvelle application, un sous-domaine aléatoire est attribué, mais même avant toute requête DNS, des requêtes de scanners de vulnérabilités arrivent déjà
    Après avoir contacté Heroku, on m’a expliqué que c’était parce que l’URL de la nouvelle application était publiée dans les logs de transparence des certificats (CT)

    • Quelqu’un a fait remarquer que cela revenait à accrocher un panneau “merci de m’attaquer” à chaque nouveau service, et qu’on aurait dû enregistrer uniquement un hash dans les logs CT au lieu du certificat réel
      Un lien vers le fonctionnement de Certificate Transparency a aussi été partagé
    • Une autre personne a indiqué qu’elle évitait ce problème en utilisant un domaine wildcard, avec une capture d’écran (lien vers l’image)